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

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

Maakt die Google/Oracle-uitspraak de GPL krachteloos?

gpl-sans-plombeJe kunt je mooie GPL vaarwel kussen, las ik bij Ars Technica vorige week. Die Google/Oracle uitspraak die een API fair use verklaarde, gaat namelijk de GPL en consorten onderuit schoffelen. Oké, het was de advocaat van Oracle die dat schreef, maar er zit een argumentatie bij. Dus laten we die eens nader bekijken.

In het kort is het een typisch “de wereld stort in want ik kreeg ongelijk”-verhaal dat te reduceren is tot deze quote:

While we don’t know what ultimately swayed the jury, Google’s narrative boiled down to this: because the Java APIs have been open, any use of them was justified and all licensing restrictions should be disregarded. In other words, if you offer your software on an open and free basis, any use is fair use.

Volgens mij slaat advocate Hurst hier de plank stevig mis, want er is nogal een verschil tussen een API hergebruiken met je eigen code en het hergebruiken van code. En dát is waar de GPL voor geschreven is: copypasten van code, of het linken/combineren van die code in je eigen software. Bij dergelijke handelingen heb ik weinig twijfel dat sprake is van een auteursrechtelijk relevante handeling.

Inderdaad, als iemand een GPL header file of API zou hebben en jij zou een eigen implementatie daarvan schrijven, dan zou je waarschijnlijk in Amerika onder fair use daarmee vrij lopen zodat de GPL niet op jou van toepassing zou zijn. Maar is dat vervelend? Volgens mij is dat een behoorlijk uitzonderlijke situatie en zeker niet de normale wijze van hergebruiken van iemands GPL werk.

Dus nee, hier wordt uit de nek gekletst.

Arnoud

Amerikaanse rechtbank: Gebruik van Java API in Android is fair use

aapje-api.pngNa twee weken was de jury er snel uit: wat Google deed met de Java API in Android is een “fair use” onder het Amerikaans auteursrecht, derhalve worden geen rechten van Java-eigenaar Oracle geschonden. Dat las ik bij Ars Technica. Google en Oracle liggen al een paar jaar in de clinch over de vraag of (kort gezegd) Google een herimplementatie van Java-functionaliteit mag doen als ze daarbij de API-definities overtypt uit de specificaties van Oracle. Oracle vond van niet en eiste diverse miljarden schadevergoeding.

In 2014 werd nog bepaald dat Android wél inbreuk maakte op de rechten van Oracle. De aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn creatieve keuzes die de resulterende api een auteursrechtelijk beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Althans, in principe. Dit is immers recht: er is altijd een uitzondering mogelijk. Omdat Google ongelijk had gekregen op het punt van de auteursrechten (zij hadden gezegd dat er geen auteursrecht zit op een API) was de rechtbank niet toegekomen aan de vervolgvraag of een wettelijke uitzondering op het auteursrecht zou gelden. Dat moest dus alsnog worden bepaald, en bij deze: fair use.

Fair use is een open norm in het Amerikaans auteursrecht. Alles kan fair zijn als je maar kunt uitleggen waarom. Er zijn dan vier factoren:

  1. Het doel en karakter van het gebruik, inclusief de vraag of het gebruik commercieel is of educatief en non-profit;
  2. De aard van het beschermde werk;
  3. De omvang en de scope van het overgenomen deel in verhouding tot het beschermde werk als geheel; en
  4. Het effect van het gebruik op de potentiële markt voor of waarde van het beschermde werk.

Helaas komt dat in dit vonnis niet heel goed uit de verf. Het was een jury-oordeel en die komen niet verder dan “inderdaad, dit is fair.” De jury-instructies geven mij de indruk dat het vooral zal zijn gegaan om de aard van het werk: als Google een eigen herimplementatie mocht doen van de functies, dan móet ze wel de API overtypen anders is haar werk volslagen onbruikbaar. Maar het is nog even afwachten hoe een en ander in vonnis wordt gegoten. En natuurlijk gaat Oracle in hoger beroep.

In Europa ligt het 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.

We hebben nu dus twee systemen: in Amerika zit er auteursrecht op een API máár is hergebruik daarvan fair use, en bij ons zit er geen auteursrecht op een API dus leef je uit, qua hergebruik.

Is Java op Android eigenlijk nog wel belangrijk? Ik zie nooit meer Java-applicaties op dat platform.

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