Twitter sluit Amerikaanse Politwoops

| AE 7734 | Uitingsvrijheid | 9 reacties

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?

| AE 7290 | Intellectuele rechten | 40 reacties

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

| AE 6637 | Intellectuele rechten | 21 reacties

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?

| AE 6634 | Ondernemingsvrijheid | 11 reacties

Een 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… Lees verder

Wanneer is een API reverse engineeren computervredebreuk?

| AE 6374 | Security | 27 reacties

Een 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…. Lees verder

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

| AE 6031 | Innovatie | 25 reacties

Hm. 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… Lees verder

Mag ik een API reverse engineeren voor mijn eigen app?

| AE 5041 | Intellectuele rechten | 43 reacties

Een 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… Lees verder

Google Shoot View mag niet van Google

| AE 2824 | Intellectuele rechten | 3 reacties

De 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… Lees verder

Een curieus takedownverzoek op een foto van een aap

| AE 2628 | Intellectuele rechten, Iusmentis | 113 reacties

Zit er auteursrecht op de foto hiernaast? Je zou zeggen van wel: leuke camerahoek, kleurspel, precies goede moment gekozen om af te drukken. Alleen: de maker is in dit geval de afgebeelde aap die de camera had geleend (via) van fotograaf David Slater. Het beest bleek geïntrigeerd door de reflectie van hemzelf in de lens,… Lees verder

Alle postcodes op een rijtje

| AE 1300 | Innovatie | 26 reacties

Zoiets simpels en openbaar als een postcode blijkt nog steeds een groot geheim, zo opent het 6PP-project. Iedereen heeft een postcode, maar als je ieders postcode wilt weten, zul je bij Postcode.nl een licentie moeten nemen. 6pp vroeg zich af, een vrije postcode database moet toch op te bouwen zijn, net zoals een vrije encyclopedie,… Lees verder