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

13 reacties

  1. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

    Geen verschil. Maar daar gaat google vs oracle ook niet over. Dat gaat over het feit dat Google java ‘zelf’ geschreven heeft aan de hand van java’s API om zo te voorkomen dat ze een licentie moesten afnemen.

    De API is bekend. Zo weet je dat er een java.net.URL class moet zijn, met bijvoorbeeld de methode getHost(). Je weet dat als je iets aanroept alla ‘new java.net.URL(“https://blog.iusmentis.com/2018/04/10/googles-gebruik-van-de-java-api-is-nu-toch-weer-geen-fair-use/”).getHost()’ je “blog.iusmentis.com” terug moet krijgen. Dat kun je dan vervolgens zelf implementeren in een taal naar keuze. En als je dat voor alle classes en methodes uit de API doet dan heb je ineens een licentievrije java versie.

    Alleen lijkt het mij heel erg terecht dat de rechter daar dan een stokje voor steekt, dit ruikt heel erg naar namaak. Ik mag ook geen louis vuitton tas namaken en daar ‘ vouis luitton’ op plakken en zeggen dat het fundamenteel wat anders is.

    1. Alleen lijkt het mij heel erg terecht dat de rechter daar dan een stokje voor steekt, dit ruikt heel erg naar namaak. Ik mag ook geen louis vuitton tas namaken en daar ‘ vouis luitton’ op plakken en zeggen dat het fundamenteel wat anders is.

      Ik ben geen jurist, maar namaken mag toch voor de auteurswet? Ik ben in de veronderstelling dat de auteurswet vooral gaat over reproductie en herpublicatie.

      Het namaken van een idee is dacht ik octrooi (patent)wetgeving, en het gebruik van andersmans naam valt onder merkenrecht.

      Volgens mij mag je best een bestaand programma nabouwen, zolang je geen onderdelen van het oorspronkelijke programma hergebruik (zoals bijvoorbeeld het copieren van plaatjes in de GUI). Dus ik zie het vergelijk met die lelijke tassen niet.

      1. Als ik me niet vergis gaat het tassenvoorbeeld vooral over het merkenrecht, niet het auteursrecht.

        Volgens mij mag je best een bestaand programma nabouwen, zolang je geen onderdelen van het oorspronkelijke programma hergebruik (zoals bijvoorbeeld het copieren van plaatjes in de GUI).
        Kortom Reverse engineering. Zoals in het Wikipedia artikel ook wordt aangegeven, is dit een veel toegepaste methode. Eén team haalt een bestaand iets uit elkaar, omschrijft precies wat men tegen komt en als een ander dan met alleen maar de informatie die is opgeschreven een stuk software namaakt, dan zou het mogen.

        In de US is het echter gewoonte om dit uit te sluiten in de EULA (en EULA gaat in dat geval voor de Copyright law die Reverse Enginering expliciet toestaat, zie Bowers v. Baystate Technologies)

  2. Door bescherming te geven aan een implementatie van een interpreter van een programmeertaal, verkrijgt het auteursrecht dezelfde beschermingsomvang als een octrooirecht. Alleen duurt deze bescherming wel aanzienlijk langer. Gerechtelijke uitspraken over auteursrecht blijven verbazen.

  3. Ik vind dit zo’n vreemde constructie hier.

    Een API is een interoperatie-standaard. Ik zou zeggen dat in een redelijke wereld, gebruik van / conformatie aan een interoperatie-standaard altijd vrijgesteld is van intellectuele-eigendomsrechten (van alle vormen). Er spelen zeker creatieve beslissingen bij het ontwerpen van een API, en het lijkt me totaal redelijk dat met maken van een aangepaste versie van een API binnen de strekking van het auteursrecht valt; maar interopereren met een standaard zou altijd vrij moeten zijn. En als dat betekent dat Oracle geinvesteerd heeft in een systeem waarvan de belangrijkste waarde in de nauwelijks exploiteerbare standaarden zit, dan is dat hun probleem.

  4. Zover ik weet zijn er meerdere (incomplete) implementaties van Java naast die van Oracle. Zo hebben GNU Classpath en Apache Harmony allebei een poging gedaan om een complete open source implementatie van de Java API te worden. Waten die open source projecten dan ook in overtreding?

    Die projecten zijn overigens gestaakt toen in 2006-2008 de verschillende onderdelen van het Java platform open source gemaakt werden door Sun als OpenJDK (GPL), dus nog voordat Oracle in the picture was als Java lead. Ik snap dan ook nog steeds niet waar deze rechtszaak precies over gaat, en waarom Google überhaupt een eigen implementatie is gaan maken.

    1. De google implementatie is librarie is uitgebracht onder de Apache licentie, welke incompatible is met de GPL Onder andere kan je deze gebruiken in gesloten software, geen verplichting zoals bij de GPL om afgeleide werken ook opensource te maken.

  5. Een beetje laat, maar wat ik altijd verbazend vind, is dat afgezien van het feit of Oracle juridisch gelijk heeft of niet er word gesproken over schade voor Oracle op Java licenties.

    Oracle heeft naar verhouding nauwelijks werk in Java gestoken. Ze hebben Java gekocht/verkregen door Sun Microsystems over te nemen. Sun heeft Google jaren zijn gang laten gaan omdat ze dachten of wisten dat ze geen poot hadden om op te staan. Dan koopt Oracle, Sun willens en wetens en dan heeft Oracle ineens schade ondervonden? Ze wisten dit toen ze Sun (Java) kochten en dus hebben ze wat mij betreft recht op niets. Bedrijven overnemen om rechtszaken te voeren is wat mij betreft iets wat verboden moet worden

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.