Mag je het netwerkprotocol van een online game uitpluizen?

rink-springer-romdumpEen tijd geleden ontdekte ontwikkelaar Rink Springer het spel Runes of Magic. En zoals dat gaat bij hackers: je raakt op het spel zelf uitgekeken, dus dan ga je kijken hoe het op de achtergrond werkt. In dit geval door het netwerkprotocol van het spel uit elkaar te trekken en te documenteren. Hetgeen uiteindelijk leidde tot een lezing op de CCC vorig jaar. Eh, maar mag dat eigenlijk wel?

Runes of Magic is een free-to-play online MMORPG (oneerbiedig gezegd een World of Warcraft-kloon). Je speelt het op je eigen PC, waarbij het spel allerlei gegevens opstuurt naar de server om je zo met anderen mee te laten spelen. En dat is nou typisch het soort “onder de motorkap”-gebeuren waarvan je graag zou willen weten hoe het werkt.

Met een simpele netwerktool (tcpdump en tcpflow) slaagde Springer erin om het gebruikte protocol te achterhalen. Hij ontwikkelde zelfs een tool (romdump) dat het hem makkelijker maakte om gegevens te decoderen en vervolgens te herkennen. Zo kon hij onder meer de algemene structuur achterhalen van pakketjes informatie over rondlopende spelpersonages.

Vervolgens ontwikkelde hij een transparante proxy tussen de client en de officiële servers, die al het netwerkverkeer kon opnemen voor realtime analyse. Erg handig bij zulk nieuwsgierig speurwerk: zo kun je makkelijk kijken wat de juiste vraag/antwoord-scenario’s zijn (client stuurt pakketje X, is hij tevreden als ie pakketje Y terugkrijgt, etc).

Erg interessant, alleen: mag dat wel? Want reverse engineeren van software, dat was een dingetje onder de Auteurswet immers. En dat klopt. Alleen heeft Springer niet de software uit elkaar getrokken maar de netwerkcommunicatie. En dat mag. Netwerkcommunicatie is openbare data die je mag observeren, en je observaties mag je vervolgens gebruiken zoals je wilt.

Oké, niet helemaal: een nepserver bouwen om mensen op te lichten mag niet, de informatie gebruiken om vals te gaan spelen of jezelf valselijk dure spullen te geven ook niet. En zo zijn er nog wel een paar dingen die problematisch kunnen zijn. Maar dat is een categorie verder dan enkel een protocol uit elkaar halen en constateren: met dit pakketje loggen ze je in, met dat pakket springt je personage over een berg en met dat pakket krijg je een zwaard.

Mag je zomaar al die gegevens publiceren? Daarmee kunnen andere mensen wellicht wel die verboden dingen doen. Dat is een terecht punt, en dat speelt altijd bij responsible disclosure. Publiceer dus alleen neutrale technische informatie en let erop dat die niet triviaal kan worden misbruikt door anderen. Geen kant-en-klare exploits dus. Maar een wetenschappelijke analyse van een netwerkprotocol mag wel.

Het kan anders komen liggen als de leverancier van de software gebruik maakt van beveiliging. Dergelijke beveiligingen omzeilen kan worden gezien als het omzeilen van een softwarebescherming in de zin van de Auteurswet (art. 32a), en dat is onrechtmatig en strafbaar. Het protocol moet dan beveiligd zijn met bv. een sleutel of certificaat. Enkel xor’en van de data (zoals bij dit protocol) is niet genoeg daarvoor.

Bekijk vooral de lezing van Rink!

Arnoud

Mag IFTTT eisen dat je je API aanpast voor hun schraapdienst?

Stel je voor dat je afvoer gaat eisen dat je je dieet aanpast, las ik op de Pinboard blog. Deze verrassende analogie was bedoeld om een recente eis van koppelsite IFTTT (If This Then That) te illustreren. IFTTT had van Pinboard gevraagd naar hun nieuwe platform te migreren zodat het koppelen van diensten nóg makkelijker zou worden (je hóórt de marketingmeelbal). Maar daar hoorden wel een partij zeer eenzijdigde voorwaarden bij. Kan zo’n dienst dat afdwingen bij willekeurige bedrijven, op straffe van verdwijnen uit het IFTTT-aanbod?

Met IFTTT kun je allerlei diensten aan elkaar knopen. Een e-mail krijgen als een RSS-feed een nieuw item heeft, een gefavoriteerde tweet in Evernote opbergen, de foto’s in je Facebookfeed naar Dropbox kopiëren als ze getagd zijn met #bewaren, en ga zo maar door. Er zijn nu bijna 300 kanalenEen erg handige dienst, waar ik zelf ook gebruik van maak.

IFTTT heeft in het begin hard moeten bouwen om dit voor elkaar te krijgen. Want een RSS-feed is relatief makkelijk uit te lezen op een standaardmanier, veel andere diensten zijn een stuk ingewikkelder. Een belangrijk deel van het werk van IFTTT is dan ook te zorgen dat al die koppelstukken blijven werken. Past een site haar API aan, dan moet IFTTT aan de bak zodat alle koppelingen met die API blijven werken.

Dar moet anders, dachten ze bij de koppelstukdienst, en ze besloten het om te draaien: IFTTT heeft een eigen API waarmee deelnemende sites gegevens kunnen aanleveren, zodat IFTTT die via haar kanalen kan koppelen. Een stuk eenvoudiger voor hen, maar zoals de Pinboard-mensen zeggen – dat is wel de omgekeerde wereld, dat jij je dienstverlening moet aanpassen omdat de leverancier van de koppelstukjes dat vraagt.

Juridisch kan ik er geen hard argument tegen bedenken. Dit is gewoon een zakelijke optie die je krijgt als je groot genoeg bent om voor eindgebruikers van significante waarde te zijn. Het doet Pinboard meer pijn dan IFTTT als de bookmarkingdienst niet op de koppeldienst staat, en die macht gebruikt IFTTT. Daar is op zich niets illegaals aan. Je kunt het onaardig vinden, en dat doen ze bij Pinboard ook:

However, cutting out sites that you have supported for years because they refuse to work for free is not very friendly to your oldest and most loyal users. And claiming that it’s the other party’s fault that you’re discontinuing service is a bit of a dick move.

De enige juridische constructie die ik kan bedenken, is het mededingingsrecht. Als een partij een economische machtspositie heeft, dan gaan er andere spelregels gelden. We noemen dit vaak een monopoliepositie, maar dat is te sterk geformuleerd. Het gaat erom dat je macht hebt op de markt, wat bijvoorbeeld blijkt uit het feit dat je de prijsleider bent. Shell is in die positie in de benzinemarkt bijvoorbeeld.

Wie een economische machtspositie bezit, mag die niet misbruiken. Zo werd Microsoft in 2004 gedwongen haar Windows API’s beschikbaar te stellen aan het opensourceproject Samba, omdat een blokkade van die dienst als misbruik werd gezien. Meer algemeen is het al snel misbruik als je concurrenten toegang tot je platform weigert. Je zou dus kunnen stellen dat IFTTT misbruik maakt, omdat haar eisen om toegang te krijgen (zelf al het werk doen én akkoord gaan met een zeer vergaande TOS waarin onder meer exclusiviteit wordt afgedwongen en het eigendom op de koppelsoftware naar IFTTT moet) zo ver gaan dat ze vrijwel neerkomen op weigeren.

De vraag is dan natuurlijk wel of IFTTT zó machtig is dat we het een economische machtspositie vinden. Kan zij zelfstandig bepalen hoe dingen in deze markt moeten werken? Komt ze weg met harde eisen als deze? Zit ‘iedereen’ hier omdat ze vinden dat ze gen keus hebben? Altijd een lastige bij internet. Want op zich kún je vaak naar een andere dienst. Het Google- of Facebookargument: welnee, wij zijn helemaal niet machtig want www.bing.com of www. eh, ja, een Facebook alternatief .com is zo getypt.

Hier ligt het iets anders denk ik: het gaat om macht doordat veel eindgebruikers het een prettige dienst vinden, en die macht wordt bij leveranciers ingezet. Die leveranciers kunnen niet zomaar weg want hun klanten de eindgebruikers worden dan boos. Dus die leveranciers hebben weinig keus. Maar is dat genoeg om he een machtspositie te noemen?

Arnoud

Twitter sluit Amerikaanse Politwoops

twitter-politieMicroblogdienst Twitter heeft de Amerikaanse site Politwoops afgesloten, las ik bij Sargasso. Op Politwoops zijn tweets van politici te lezen nadat de twitterende politicus deze had weggehaald. Het idee erachter was dat je zo kon zien welke flaters of andere opmerkelijke uitingen politici weg wilden poetsen (“het gaat niet om de typefouten”), maar Twitter beroept zich nu op de privacy van haar gebruikers en verklaart deze actie in strijd met de gebruiksvoorwaarden.

Op Politwoops kan je alle tweets zien die politici eerst plaatsten en even later weer verwijderden, aldus de site. Bij de meeste daarvan kun je je afvragen wat nu het nieuwsbelang is dat die tweet ooit is geplaatst, laat staan weggehaald. Maar het is zeker denkbaar dat politici achteraf een uiting ongelukkig vinden, en dan is de delete-knop natuurlijk een heel aantrekkelijke.

Arjan el Fassed meldt tegenover Sargasso:

Wat politici op een publiek kanaal zeggen moet voor iedereen te vinden zijn. Dit gaat niet om de typefouten die zij maken. Het gaat juist om het inzicht dat het geeft in de veranderde boodschap van politici. Dat gaat vaak aan ons voorbij.

En daar zit wat in: als een politicus in het openbaar wat zegt, dan doet hij dat in functie, en even los van typefouten en dikke vingers is wat hij zegt zeker relevant voor het publiek. Die lezen de tweets, en die hebben dus effect ook al worden ze nadien weggehaald. Misschien juist wel de tweets die zijn weggehaald.

Twitter zegt nu echter:

[marketingreutel over hoe prachtig het werk van Politwoops is] but preserving deleted Tweets violates our developer agreement. Honoring the expectation of user privacy for all accounts is a priority for us, whether the user is anonymous or a member of Congress.

Dat klinkt natuurlijk leuk, maar privacy lijkt me niet echt een issue wanneer iemand in functie in het openbaar een uiting doet. Dus dit voelt als een wat gezochte reden. Ik wil niet meteen een samenzwering vermoeden, maar je raakt hier toch wel een tikje door geïntrigeerd.

En het is erg zorgelijk te bedenken dat je als journalist geen openbare uitingen kunt bijhouden zonder afhankelijk te zijn van een private derde, die kennelijk zomaar kan besluiten dat dat niet meer mag.

Arnoud

Maakt linken van een GPL bibliotheek je software automatisch GPL?

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library gebruikt? Het programma wérkt niet zonder de library. Maar Europees auteursrechtelijk waag ik dat toch te betwijfelen.

De term ‘afgeleid werk’ is een tikje ongelukkig. De term komt uit het Amerikaans auteursrecht; in Europa kennen we alleen de ‘verveelvoudiging in gewijzigde vorm’, oftewel een kopie, al dan niet aangepast, van (een deel van) het werk. Dat klinkt inderdaad wat beperkter, en dat is het volgens mij ook.

In de SAS/WPL-uitspraak heeft het Hof van Justitie de grenzen getrokken van het software-auteursrecht. In die zaak beriep SAS zich op een auteursrecht voor haar programmeertaal en functionaliteit daarin, maar gedaagde WPL kreeg gelijk, zo’n auteursrecht bestaat niet.

Auteursrecht op software bestaat volgens de hoogste Europese rechter alleen op de broncode en de daarvan afgeleide uitvoerbare code. Men noemt dit de ‘uitdrukkingswijzen’ en daaronder wordt alleen datgeen verstaan dat tot “reproductie van het computerprogramma of tot het computerprogramma zelf kunnen leiden”. Je moet dus, kort gezegd, met wat er overgenomen of gebruikt is in het andere werk, het originele programma zelf althans gedeeltelijk kunnen terugvinden.

Bij het gebruik van een software library roep je in je eigen programma een functie aan, waarna de implementatie van de library wordt uitgevoerd om de betreffende functionaliteit te realiseren. In het SAS/WPL arrest ging het om functies uit een programmeertaal, maar ik zie het verschil niet met een API van een specifieke bibliotheek. In feite is de implementatie van een programmeertaal ook een library (of set libraries) die je middels een API aanroept. Wil je in C een tekst op het scherm, dan zeg je printf("Hello, world!");, waarna libc de implementatie daarvan uitvoert, en wil je bij GNU readline een regel invoer verkrijgen dan zeg je readline(my_prompt);, waarna readline de implementatie daarvan uitvoert. Dat is technisch volgens mij dus hetzelfde.

Meer algemeen, als het aanroepen van een functie van een bibliotheek zou meebrengen dat je het auteursrecht op die bibliotheek schendt, dan zou het auteursrecht dus in feite de functionaliteit beschermen die achter de functie zit. En dát is nadrukkelijk niet de bedoeling in het Europese auteursrecht.

Gelet op deze overwegingen moet worden geconstateerd dat, wat de elementen van een computerprogramma betreft (…), noch de functionaliteit van een computerprogramma, noch de programmeertaal en de indeling van gegevensbestanden die in het kader van een computerprogramma worden gebruikt teneinde de functies daarvan te benutten, een uitdrukkingswijze van dit programma vormen in de zin van [het auteursrecht].

Het opnemen van een functie-aanroep in je programma (zoals printf("Hello, world!"); of readline(my_prompt);) kan dus niet leiden tot een auteursrechtinbreuk op libc of GNU readline, omdat die functie-aanroep nog geen uitdrukkingswijze van het programma libc dan wel readline vormt. Pas als je code zou overnemen, ook in gedeelten, zou er inbreuk kunnen ontstaan.

Wat de GPL of de FSF zeggen over afgeleide werken, linken of Complete Corresponding Source doet er hierbij volstrekt niet toe: je komt pas aan terminologie uit een licentie toe als er sprake is van inbreuk. Pas dan zou de aanroeper van de software immers hoeven te zeggen “geen inbreuk, ik heb een licentie”.

Het argument uit Oracle/Google dat het maken van de API zélf creatief is, gaat hierbij niet op. In die zaak werd Google’s API-kloon van Java inbreukmakend geacht omdat Oracle creatieve arbeid had gestoken in het definiëren daarvan. Maar dat was natuurlijk ook het geval bij de SAS programmeertaal waarvoor WPL programma’s maakte. De functionaliteit, dus ook hoe de functies heten, wat ze doen en welke parameters en return values daarbij horen, is geen “uitdrukkingswijze” van het programma.

Een complete reproductie van de API zou mogelijk wél inbreuk kunnen zijn. In de SAS/WPL uitspraak stond ook de eigen handleiding van WPL ter discussie, waarin elke functie was opgenomen (maar volgens mij ook stukken tekst uit de documentatie van SAS). Dit is iets dat de rechter per geval moet onderzoeken: hoe veel is er overgenomen en hoe creatief is hetgeen overgenomen is? Mogelijk dat bij een handleiding het citaatrecht nog een verweer kan zijn, maar bij een volledige overname met als doel een interface-compatibele kloon te schrijven twijfel ik zeer of dat opgaat. Maar wellicht biedt dit dan een lichtpuntje:

In deze context moet worden gepreciseerd dat indien een derde een gedeelte van de bron- of doelcode betreffende een voor een computerprogramma gebruikte programmeertaal of indeling van gegevensbestanden zou aanschaffen en hij met behulp van deze code soortgelijke elementen in zijn eigen computerprogramma zou creëren, deze handeling mogelijkerwijs een gedeeltelijke reproductie in de zin van [het auteursrecht] zou opleveren.

Het lijkt dus echt nodig dat er ook broncodes worden overgenomen. En puur de definities van de functies voldoen niet snel aan die eis.

Wat vinden jullie? Is er een wezenlijk verschil tussen een API van een of andere bibliotheek aanroepen versus de functies uit een programmeertaal? Maakt het uit of er maar één implementatie van die API+bibliotheek is? Of zijn er andere redenen om een API-aanroep toch inbreuk op het auteursrecht te noemen?

Arnoud

Oracle’s Java API auteursrechtelijk beschermd in VS, Android maakt inbreuk

aapje-api.pngEen Amerikaans gerechtshof heeft vrijdag in hoger beroep bepaald dat Google met zijn Android-besturingssysteem het copyright van Oracle heeft geschonden, las ik bij Tweakers. Nadat eerder nog was bepaald dat er geen auteursrecht zat op de API’s van Oracle’s Java, beslist het Hof van Beroep nu anders: de aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn wel degelijk creatieve keuzes die de resulterende api een beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Het geschil speelt al sinds 2012. Google had in Android een aantal elementen overgenomen uit de Java API en Oracle startte daarop een rechtszaak wegens auteursrechtinbreuk. In eerste instantie won Google: een API en functiedeclaraties zijn vergelijkbaar met een inhoudsopgave, en bovendien kun je in software vaak dingen maar op één manier uitdrukken. Daarmee is er geen sprake meer van het overnemen van creatieve elementen.

In hoger beroep wordt anders beslist. Allereerst wordt vastgesteld dat het máken van een API best creatief werk kan zijn. Nadenken welke functies je gaat aanbieden, hoe je die noemt, welke argumenten ze moeten krijgen en wat voor soort resultaat er komt, vereist creatieve arbeid. En die arbeid wordt beschermd door het auteursrecht. Een ander mag dan niet zomaar de integrale resultaten van die arbeid overnemen.

Amerikaans auteursrecht verbiedt auteursrecht op methods of operation. Al in 1995 speelde dit: mocht Borland met spreadsheetprogramma Quattro de menustructuur van concurrent Lotus overnemen? Ja, zo oordeelde men destijds, want een menu is dé manier van het opereren/gebruiken van een stuk software. En in eerste instantie won ook Google het met dit argument, omdat het nabootsen van een menu hetzelfde werd geacht als het aanroepen van een API. Dat wijst het Hof af: het kopiëren van API declaraties is wat anders dan het kopiëren van labels uit een menu.

Bovendien is de Lotus-uitspraak uit een ander circuit en in de VS geldt zo’n uitspraak dan niet als bindende jurisprudentie. Het Hof valt terug op een eigen precedent dat wél bindend is: de manier waaróp je een method of operation vormgeeft, kan wel auteursrechtelijk beschermd zijn. Mits er maar meer dan één manier is om dat te doen. En dat is hier het geval: de Java-ontwikkelaars hadden de vrije keuze om hun API te maken zoals zij wilden.

In Europa ligt het compleet anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt.

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

Hiermee zou een API dus wél vrij bruikbaar zijn omdat het dan enkel gaat om de functionaliteit die in de API ligt. Het ging in de SAS-zaak om het gebruik van een programmeertaal waarop auteursrecht werd geclaimd. Het schrijven in die taal zou dan inbreuk opleveren, omdat een programma in die taal immers de beschermde functionaliteit aanroept. En dát wijst het Hof van Justitie af. Dit lijkt mij 1-op-1 door te trekken naar API’s van een programma. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

Google krijgt nog een kansje in de tweede ronde: de zaak is terugverwezen naar de rechtbank om Googles verweer op grond van fair use te beoordelen. Onder fair use mag je in het Amerikaans auteursrecht iemands werk gebruiken mits dat billijk (fair) is. Daarbij spelen zaken mee als hoe concurrerend je bent, hoe commercieel je bent en hoe transformatief of juist letterlijk je gebruik is. Dat is dus een moeilijker zaak om te bewijzen dan wanneer de Java API niet auteursrechtelijk beschermd zou zijn verklaard.

Dit kan nog wel eens heel hinderlijk worden want heel veel internet-API’s worden beheerd door Amerikaanse bedrijven. En als die nu allemaal auteursrechtelijke voorwaarden gaan koppelen aan gebruik daarvan, dan gaat me dat nog flink wat juridische hoofdpijn opleveren.

Arnoud

Mag je een productnaam noemen zonder toestemming van het bedrijf?

http-www-url-merk-adres-hand.pngEen opmerkelijke tweet zag ik gisteren voorbij komen: automatiseerder Centric meldt aan concullega Zaaksysteem.nl dat het gebruik van Centric’s productnamen niet toegestaan is zonder haar toestemming. Opmerkelijk, want het gaat hier om een opsomming van koppelingen naar onder meer Centric-producten en niet om de verkoop van concurrerende producten onder die namen. Mag dat nu ook al niet meer?

Update (09:21) Centric reageert in de comments:

We betreuren het dat er een onjuist beeld is ontstaan van ons verzoek aan Zaaksysteem.nl. Onze zorg betrof niet zozeer het vermelden van onze productnamen, maar de combinatie met de informatie die via het aanklikken van onze productnamen beschikbaar is gesteld. Wij hadden hier graag vooraf afstemming over gehad met zaaksysteem.nl , omdat het belangrijk is dat de vermelde koppelinformatie actueel en betrouwbaar is. Inmiddels hebben de heer Moen van Zaaksysteem.nl en Pierro Baas van Centric telefonisch contact gehad. Onze reactie op de berichtgeving vindt u op onze website: http://www.centric.eu/NL/Default/Branches/Lokale-overheid/Reactie-op-berichtgeving-over-vermeldingen-productnamen

Als de productnaam niet als merk is gedeponeerd, dan is deze vogelvrij. Je kunt nagaan bij het Beneluxmerkenregister of een naam als merk is gedeponeerd. Houd er rekening mee dat de spelling in het depot af kan wijken. En als het depot een plaatje (beeldmerk) blijkt te zijn, krijg je mogelijk eerst de discussie over beschrijvende termen in beeldmerken.

Welke merken Centric heeft, is me onduidelijk. Zo vind ik bijvoorbeeld een beeldmerk voor eHerkenning maar dat staat niet op naam van Centric. De merken die ik vind op deposantnaam Centric zie ik dan weer niet terug in de klachtmail. Maar goed.

Als iemand andermans merk gebruikt voor concurrerende producten of diensten, dan is dat een probleem. Daar is het merkenrecht voor gemaakt: geen concurrentie middels een beschermde merknaam. Ga je eigen naam verzinnen of zo.

Echter, niet elk gebruik door een concurrent is verboden. Met name uitgezonderd zijn verwijzingen naar merkproducten om de bestemming of het beoogde gebruik van je eigen product aan te geven. “Past op alle Bosch-stofzuigers” of “vereist Windows 8.1” bijvoorbeeld. En volgens mij is dat precies wat hier gebeurt: die Zaakherkenning-software heeft koppelingen (API’s) voor diverse Centric producten, en daarbij worden de namen van die producten genoemd. Dat mag.

Het zou problematisch worden als de verwijzing zo prominent wordt dat je in de war kunt raken over wiens dienst het is, of over de relatie tussen de twee bedrijven. Heel klein “compatibel met” en dan “Windows 8.1!” heel groot is merkenrechtelijk dus verkeerd. Maar dat zie ik niet bij deze site.

Afijn. Gevalletje merkenrechtelijk blaffen lijkt me. Het verbaast me wel dat dat nog vaker voor lijkt te komen dan auteursrechtelijk blaffen. Zijn mensen banger voor merken dan voor auteursrechten?

Arnoud

Wanneer is een API reverse engineeren computervredebreuk?

chip-paspoort.jpgEen lezer vroeg me:

Onlangs is de OV-Chipkaart app uitgekomen. Uit analyse blijkt dat de app per request een specifieke signature meestuurt, en zonder die signature komt er geen reactie vanuit de server van Trans Link Systems. De methode waarop de signature gemaakt wordt is te achterhalen met decompileren en daarna eenvoudig na te maken. Het is erg moeilijk te achterhalen door puur naar het verkeer te kijken. Mijn vraag is: als iemand API calls doet op basis van die kennis, is er dan sprake van computervredebreuk?

Als ik het goed begrijp, dan doet die app dus aanroepen op de server van TLS. Om te bewijzen dat de app echt de app is, wordt daarbij een signature/code gemaakt op basis van een sleutel die in de app aanwezig zit. Heb je de sleutel, dan kun je dus de code namaken en je eigen aanroepen als echt presenteren.

Van computervredebreuk is sprake als je binnendringt in andermans computer. Een ov-chipkaart is een computer, en die heb je te leen van TLS. Binnendringen daarin is dus mogelijk. Maar een app op je eigen telefoon, daar kun je niet in binnendringen. De app is geen ‘geautomatiseerd werk’, de telefoon wel maar die is van jezelf.

Binnendringen in de server van TLS is mogelijk en dat kan wel computervredebreuk zijn. Alleen, er moet dan sprake zijn van binnendringen zonder recht, wederrechtelijk dus. Je zegt dan, je mag inloggen met de app maar handmatig/eigen app inloggen mag niet. Ik twijfel of dat werkt. Als ik zeg “hier is de sleutel” en jij maakt een sleutel erbij, dan pleeg je geen huisvredebreuk als je met die extra sleutel binnengaat. Het gaat om de plek waar je mag zijn, niet het middel waarmee je daar komt. Een undocumented feature aanroepen door de API-URL te manipuleren (misschien doet &debug=1 iets leuks?) zou ik wel computervredebreuk noemen.

Auteursrechtelijk is het spannender. Je decompileert en achterhaalt de werking van de app. Als het doel dan is een kloon van de app te maken, dan botst dat met het auteursrecht op de app. Maar ‘kloon’ is een beperkt begrijp. En een nieuwe app die alleen dezelfde API calls doet, zou ik niet snel een ‘kloon’ noemen. De wet hanteert “computerprogramma, dat niet als een nieuw, oorspronkelijk werk kan worden aangemerkt” als criterium. Dus echt pure nabouw, dezelfde functionaliteit en layout.

Je kunt je ook afvragen of je wel de ‘werking’ van de app aan het achterhalen bent. Je wilt in feite alleen het algoritme voor het maken van de code achterhalen, en natuurlijk het element zelf dat daarvoor nodig is. Hoe de rest van de app werkt, is minder van belang.

Arnoud

Goedemiddag, wij komen even bij u twitteren dat u het leuk vindt hier

twitter-tweet-wasnt-meHm. Is dit nu juridisch interessant of niet? Mensen die zich bij de NY Comic Con aanmeldden, ontdekten dat ze ineens twitterden hoe leuk ze het vonden. Volgens de CC geen probleem: daar hadden ze toestemming voor gegeven bij het inschrijven. Want ja, er stond “this application may tweet on my behalf” bij het aanmelden via Twitter. Maar dat lazen mensen toch even iets anders.

Juridisch gezien is het duidelijk, heet het dan: in een Opinie over toestemming bepaalde de privacytoezichthouders dat als je nu maar specifiek iets vraagt, daarbij goed uitlegt wat je gaat doen en mensen uit vrije wil dan ja of nee laat klikken, dan is er vrije, specifieke en geïnformeerde toestemming. En wat is er nou mooier dan dat.

Het idee dat mensen toestemming kunnen geven en dat dan eigenlijk alles wel oké is, zit diep in het juridische systeem. Ik maak me hier met enige regelmaat kwaad over: mensen lezen niet wat ze wordt gevraagd, en gaan er vanuit dat het wel goed zal zitten. Waarbij ook meespeelt dat de toestemmingsvragen vaak net subtiel wat anders betekenen of op een gekke manier gepresenteerd worden (zie de recente boevenpubliceertoestemmingsbordjes).

Maar in dit geval luidt de toestemmingstekst letterlijk “This application may send Tweets on your behalf”, deze dienst gaat vanaf jouw account twitteren. Hoe expliciet wil je het hebben?

Nou ja, toch wel iets specifieker dus. Zoals ze bij Ars Technical al schreven, de gebruikelijke interpretatie van die zin is “wij faciliteren twitteren vanuit deze dienst, maar uiteraard krijg jij vooraf te lezen wát we uitsturen”. Of de dienst twittert volgens een door jou bepaald stramien. Zo worden al mijn nieuwe posts automatisch getwitterd via een WordPressplugin die ook met die zin toestemming vroeg. Maar het was duidelijk dat hij dan alleen bedoelde dat hij tweets stuurt van het soort “#author# blogt: #title# #url#”. En niet “#author# vindt WP Tweets Pro echt super #aanrader”.

En dan komen we toch weer terug bij mijn frustratie hierover: mensen lezen het niet en gaan er vanuit dat het wel goed zal zitten. Zoals ook hier. En op zeker moment wórdt die opvatting dan ook juridisch relevant: als iedereen een tekst opvat als linksom, dan mág je niet meer zeggen “maar rechtsom wordt niet uitgesloten”. Dat wordt ‘ie wél: omdat iedereen vindt dat het uitgesloten wordt, dat het er niet onder valt.

Wat vinden jullie? Hadden die Comic Con-ners beter moeten lezen? Of domme actie van de NYCC?

Arnoud

Mag ik een API reverse engineeren voor mijn eigen app?

zoeken-harde-schijf.jpgEen lezer vroeg me:

Steeds meer sites en platforms komen tegenwoordig met een eigen mobiele app, maar lang niet altijd zo handig als wel zou kunnen. Nu werken deze apps met op de achtergrond een API (application programming interface) die ik met mijn eigen app ook zou kunnen aanroepen. Maar mag ik hun app reverse engineeren om zo te achterhalen hoe die API van hen in elkaar steekt?

Reverse engineering, oftewel iets uit elkaar pluizen om te zien hoe het werkt, is in het algemeen toegestaan om principes en ideeën te achterhalen. De Auteurswet bevat een verbod op reverse engineering, maar dat gaat eigenlijk over decompileren: het reconstrueren van broncode uit een applicatie. Dat is aan meer regels gebonden. Je mag niet een applicatie decompileren om deze te klonen, maar wél om een compatibele app te maken.

Als je een app decompileert om zo de API te achterhalen, dan stap je in een grijs gebied. Enerzijds doe je dit om een eigen (met het platform) compatibele app te maken, maar anderzijds produceer je wel een soort van kloon van die “officiële” app, en dát mag dus niet. Gelukkig is het meestal genoeg om het dataverkeer te observeren en daaruit af te leiden hoe de API werkt. En dát mag altijd.

Een bijzonder geval ontstaat wanneer de API of het platform gericht is op het ontsluiten van een databank. Als zo’n databank beschermd is door een databankrecht, dan is jouw app mogelijk in strijd met dat recht, want hij biedt dan een middel voor de voorbehouden handeling van

het herhaald en systematisch opvragen of hergebruiken van in kwalitatief of in kwantitatief opzicht niet-substantiële delen van de inhoud van een databank, voorzover dit in strijd is met de normale exploitatie van die databank of ongerechtvaardigde schade toebrengt aan de rechtmatige belangen van de producent van de databank.

Ja, hele mond vol maar het is ook een draak van een wet. Even kijken: je app vraagt herhaald en systematisch data op, check. Per query is de inhoud niet substantieel (niet 90% van de databank), check. (En haal je wél substantieel de hele databank op dan ga je sowieso onderuit onder het databankenrecht.) Is het in strijd met de normale exploitatie of rechtmatige belangen van de producent? Ah, daar zit hem de kneep.

Ik zou zeggen dat wanneer de app hetzelfde soort functionaliteit biedt (maar dan handiger) als de officiële app, er niet snel strijd met normale exploitatie kan ontstaan. Als er een inkomstenstroom zit aan de officiële app (al zijn het maar advertenties) dan wordt het spannend want jouw app omzeilt die dan. En als je met jouw app iets gratis kunt opvragen dat normaal geld kost, dan zie ik ook wel een databankrechtelijk probleem.

Een app die iets heel nieuws doet op basis van een bestaande API, lijkt me in principe niet snel een probleem zolang er geen overlast komt door bv. onevenredig veel opvragingen. Stel je kunt op de Artis-site via een API de voedertijden opvragen, en jij maakt een app over apen (haha, hij zei apie en dat lijkt op API) die onder meer laat zien waar je in Amsterdam apen kunt bewonderen, inclusief de voedertijden van Artis, dan zie ik niet welk belang van Artis hier geschaad zou worden.

Dat zal rechthebbenden er echter niet van weerhouden met juridische dreigbrieven te komen. Of, iets praktischer, de opvragingen vanuit jouw app detecteren en blokkeren. En dat laatste mogen ze, ook als daar eigenlijk geen reden voor is. Het is hun server en willen ze jou niet faciliteren, dan houdt het op.

Arnoud

Google Shoot View mag niet van Google

google-shoot-view.pngDe game Google Shoot View, een first-person shooter binnen Street View is door Google offline gehaald wegens schending van auteursrecht, las ik bij Gameliner. Google Shoot View is een spelletje waarin spelers via Google Streetview op mensen en gebouwen konden schieten. Er ging niet echt iets stuk, het ging puur om het idee van rondlopen en schieten met een best groot geweer.

Dat van auteursrechten klopt niet helemaal: Google blijkt zich te beroepen op haar Terms of Service, die je verbieden gebruik te maken van de Maps API op een manier die leidt tot

(xvi) promote physical harm or injury against any group or individual

Tsja, wat moet je daar nou mee. Het “spel” is niet meer dan een overlay op Google Maps, waarbij je cursor zeg maar een schietgeweer is en je dus rondloopt met een schietkruis (video). Je kon de trekker overhalen, maar er ging dan niets stuk of wat dan ook. Om dat nou “aanzetten tot geweld” te noemen gaat mij wel érg ver. Als ze nou hadden gezegd dat “Shoot View” of de naam “Google” in de spelnaam merkinbreuk waren geweest, dan had ik dat nog wel kunnen begrijpen.

Maar het is wél Googles eigen server, en daar gelden hun regels. Als bedrijf kun je er weinig tegen doen als die regels je dingen verbieden, het is kiezen of delen (of onderhandelen). Wil men dus geen pistolen of geweren boven de Streetview content, dan houdt het meteen op.

Heel heel misschien zou je nog een puntje van “vrije meningsuiting” kunnen opwerpen, Google verhindert zo een bepaalde kunstvorm. Maar particuliere partijen hoeven eigenlijk nooit andermans mening te tolereren via hun eigendommen, behalve in zeer uitzonderlijke situaties waarin dat eigendom de enige manier is om een bepaald publiek te bereiken. Maar dan zou ik eerder denken aan het categorisch blokkeren van je zelfgemaakte video’s op Youtube dan op een overlay van een geweer op Google Maps.

Arnoud