Googles gebruik van de Java API is nu toch weer geen fair use

| AE 10509 | Software | 13 reacties

Googles gebruik van de Java API packages is geen fair use, las ik bij ITenRecht. Dit is de vierde stap in hoger beroep van de Google/Oracle rechtszaak over auteursrecht op de Java API die al enige jaren loopt. In eerste instantie bleek de API niet beschermd, in hoger beroep wel, toen bleek Googles gebruik een fair use en nu dus weer niet. Waar staan we nu met deze zaak?

De centrale kwestie is of Google de API van de taal Java van een eigen implementatie mag voorzien, om zo Java-compatibel te worden zonder een licentie van Oracle nodig te hebben. Dat kan alleen als op de API zelf geen auteursrecht rust, of als het gebruik van Google onder de Amerikaanse noemer van “fair use” gerechtvaardigd is.

In de eerste serie rechtszaken ging het om de vraag of er of de API auteursrecht rust. Een API is op zich een set creatieve keuzes (welke functie doet wat, hoe heet hij en welke variabelen zijn relevant), maar er zit ook een sterke technische component in. Daarom bepaalde de rechtbank in eerste instantie dat er geen sprake was van (Amerikaans) auteursrecht. In hoger beroep werd dat teruggedraaid, omdat weliswaar de functies zelf technische dingen doen, maar de keuze voor wélke functies en hoe dat te organiseren voldoende creatief te noemen is.

Heb je auteursrecht op een API, dan mogen anderen die dus niet gebruiken zonder een licentie. Echter, in Amerika geldt de algemene uitzondering van “fair use”: alle zeg maar legitieme, normale vormen van gebruik zijn legaal. Daarbij wordt een vierstappentoets langsgelopen waarbij zaken als de hoeveelheid overgenomen werk, de mate van aanpassing/transformatie en de aard van het werk meegewogen worden. Met deze open norm is in principe alles als “fair” aan te merken als je maar hard genoeg je best doet, maar er zit ook het nadeel aan dat je het nooit zeker weet tot de rechtbank er wat van gevonden heeft.

In het vervolg van de zaak beriep Google zich natuurlijk op fair use. Kern van het argument is dat als iemand een API maakt, het de bedoeling is dat mensen moeten weten wat deze kan. Daar een applicatie op schrijven is dan gewoon legitiem, normaal, zeker als je het argument interoperabiliteit meeweegt. Daar staat tegenover, aldus Oracle, dat Google met deze gratis weggegeven herimplementatie de hele markt voor de betaalde Java-licentie ondermijnde en vanwege de gigantische marktmacht van Google zou dat een enorme impact hebben op Oracle.

De rechtbank (en de jury) gaf Google gelijk, maar Oracle ging in hoger beroep. En nu wordt het even complex, want in de VS geldt een strikte scheiding tussen wat juries mogen zeggen en wat het primaat van de rechter is. De jury beslist wat de feiten zijn, de rechter past het recht toe. En bij fair use is dat ingewikkeld, omdat je daarbij feiten juridisch kwalificeert. Het Hof in hoger beroep moet dan ook de feiten en de juridische analyse uit elkaar trekken en vooral op die laatste gaan schieten.

Uiteindelijk weegt dan de vierde factor – het effect op de markt voor het origineel – het sterkste: Googles herimplementatie geeft een grote impact op de betaalde licentiemarkt voor Java (zelfs als je de open implementatie van Oracle zelf erbij betrekt), en daarmee blokkeert men eigenlijk de mogelijkheden voor Oracle compleet om geld te verdienen met haar werk. En iets waarmee de rechthebbende volledig met lege handen komt te staan, kan niet fair use zijn.

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. Zoals het Hof het formuleerde:

… 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?

Arnoud

Mag ik de API achter een app zelf aanroepen?

| AE 9484 | Innovatie | 26 reacties

Een lezer vroeg me:

De app van mijn bank is leuk en aardig, maar ik wil eigenlijk bepaalde kerncijfers in mijn thuisdashboard getoond hebben. Technisch kom ik daar wel uit, maar mag ik die API aanroepen voor mezelf? Het is in principe dezelfde informatie heen en weer als de app zou doen, maar ik doe het niet op de officiële manier. Krijg ik dan problemen?

Zuiver juridisch gezien zie ik hier geen probleem mee. Als je gerechtigd bent een API aan te roepen, dan is het niet strafbaar of onrechtmatig om die aan te roepen. Je gaat hier dus niet voor de cel in, en de bank zal ook geen schadeclaim kunnen indienen.

Als je rare trucs gaat toepassen om de API dingen te laten doen die niet de bedoeling zijn, dan kan dat anders liggen. Informatie opvragen waar je eigenlijk niet bijhoort, mag je niet zomaar doen. In theorie is dat computervredebreuk.

Praktisch gezien kun je er wel problemen mee krijgen, in ieder geval één simpele: als de bank jouw aanroepen ziet als misbruik of bedreiging, dan blokkeren ze die. Dat zal al snel betekenen dat je ook via de officiële app niet meer bij je bankgegevens kunt of overboekingen kunt doen, en dat lijkt me erg vervelend voor een consument. Want zonder internetbankieren je bankzaken doen is een hele uitdaging tegenwoordig.

Ik zou dit dus alleen doen als de bank het goedvindt, of als je zeker weet dat de aanroepen niet te onderscheiden zijn van ‘echte’ aanroepen.

Arnoud

Mag je de Twitter API scrapen voor wetenschappelijk onderzoek?

| AE 8877 | Auteursrecht | 9 reacties

twitter-agent-politieEen lezer vroeg me:

Deze meneer heeft een mooie data-analyse gemaakt van Donald Trump zijn tweets: Trump zelf gebruikt een Android-apparaat en een ghostwriter nuanceert de boel vanaf een iPhone. Daarbij vroeg ik mij af of dit zomaar mocht. Twitter zegt van wel bij onderzoeksdoeleinden (onder bepaalde voorwaarden). Zoals dat je je dataset niet mag delen met anderen, wat het weer moeilijk maakt voor écht onderzoek.

Op het eerste gezicht zou je zeggen dat onderzoek op Twitterberichten geen probleem zou zijn. Onderzoek op basis van krantenberichten is al decennia oud en geen probleem. En wat is Twitter nou anders dan een krant, zij het sneller en korter en met megaveel meer berichten?

Nou ja, om er eens eentje te noemen: Twitter is een dienst, en een krant is een product. Kranten kun je dan ook legaal inzien vanuit allerlei plekken, zoals bibliotheken, zonder dat daar allerlei gebruiksvoorwaarden gelden. Natuurlijk is het kopiëren van krantenberichten auteursrechtelijk een probleem, maar onderzoeken welke artikelen in Nederlandse kranten door ghostwriter zijn geschreven, is volgens mij volstrekt legaal.

Bij Twitter ligt dat anders. Twitter is een dienst, en kan daar voorwaarden aan verbinden. Die hebben ze dan ook, maar ik kan er geen specifieke regels over wetenschappelijk onderzoek in vinden. Deze API licentie gaat primair over het kunnen vertonen van tweets in je eigen dienst, eventueel licht gemasseerd om ze passend te krijgen. Het is bijvoorbeeld expliciet verboden de berichten op te slaan, wat onderzoek al bemoeilijkt – helemaal voor het verifieerbaar maken van je onderzoek want je mag de dataset dus niet vrijgeven.

Op zich is dat legaal. Een dienstverlener mag zelf weten wat ze toestaat met de resultaten van haar dienst, er is geen regeling zoals de auteursrechtelijke uitputting die bepaalt dat beschermde producten zoals boeken of kranten vrij bruikbaar zijn voor legale verkrijgers.

In de praktijk lijkt het wel mee te vallen. Ik heb nog nooit gezien dat Twitter een sommatie stuurde naar een researcher, en kan me dat (afgezien van research dat de servers overbelast) ook eigenlijk niet voorstellen. Twitter zou er weinig mee te winnen hebben en veel te verliezen. Maar afhankelijk zijn van een welwillende opstelling van een dienstverlener is natuurlijk wat anders dan iets mógen.

Arnoud

Twitter sluit Amerikaanse Politwoops

| AE 7734 | Meningsuiting | 9 reacties

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

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Open source, Software | 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… Lees verder

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

| AE 6637 | Auteursrecht, Software | 21 reacties

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

Mag je een productnaam noemen zonder toestemming van het bedrijf?

| AE 6634 | Merken | 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