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

21 reacties

  1. Aan de andere kant is een ‘circuit split’ de belangrijkste reden voor SCOTUS om een zaak op te pakken, dus ik zou zeer verbaasd zijn als Google in deze niet voor een ‘writ of certiorari’ gaat. Voorlopig is dit lijkt mij geen gedane zaak.

    En wie weet, als dit blijft staan, komt het congres eens van hun luie reet. De software industrie is groot in de VS en als die op deze manier geschaad wordt hebben ze wellicht eindelijk een belang.

  2. 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?

    Nou, dat verschil is wel groot. Je weet dat ik niet van vergelijkingen houd, maar op die manier zou je ook kunnen betogen dat geschreven teksten vrij zijn van auteursrecht. De Nederlandse taal is vrij van auteursrecht, en een tekst in die taal…

    Ik ben geen fan van Oracle, maar ik kan me eigenlijk toch wel vinden in de uitspraak. Het ontwerpen van een goede API is ingewikkeld werk waar wel degelijk creativiteit in zit. Dingen kunnen niet slechts op 1 manier.

    Feit dat je als ontwikkelaar een API ‘mooi’ of ‘lelijk’ kan vinden lijkt me eigenlijk de beste onderbouwing voor het feit dat er creativiteit aan te pas komt om een API te ontwerpen.

    En een definitie van een (programmeer)taal is toch echt iets anders dan de aanroep van een API. De aanroep van een API is hooguit te vergelijken met een language runtime, die de meest gebruikte functies in een programmeertaal, bijvoorbeeld voor input/output definieert.

    Let wel, ik zeg niet dat je niet blij moet zijn met wat er nu gebeurt, dit “moeten we niet willen met z’n allen”. Maar eigenlijk ging het al mis toen Oracle Sun kocht. Waarom was de Java specificatie niet in een stichting ondergebracht ?

    1. Maar eigenlijk ging het al mis toen Oracle Sun kocht. Waarom was de Java specificatie niet in een stichting ondergebracht ?

      Dat kan je redelijkerwijs niet doen zodra er al sprake is van een overname. Het ging al eerder mis: toen mensen buiten Sun Java zijn gaan gebruiken zonder te eisen dat het in een stichting ondergebracht werd.

      1. Ja, goede nuance, ik probeerde die al uit te drukken met ‘was’. De gebruikers hadden het inderdaad moeten eisen.

        Wat Netscape en Microsoft met ECMAScript hebben gedaan was natuurlijk ook briljant.

    2. Nee, een programmeertaal en een API zijn wel goed met elkaar te vergelijken:

      • bij het ontwerpen van een programmeertaal/API heb je een bepaalde keuzevrijheid, en je kan daarin “creatieve”(*) keuzes maken.
      • Een programmeertaal/API vormt een interface tussen enerzijds 3rd party software, en anderzijds een compiler/runtime/library/service. Als de programmeertaal/API door een commerciële partij wordt gemaakt, dan zal die ook meestal de eerste implementatie maken van de compiler/runtime/library/service.
      • Zodra een programmeertaal/API eenmaal vast ligt, kan daar niet meer van worden afgeweken zonder interoperabiliteit aan te tasten. Een concurrent die interoperabiliteit wil leveren kan dit niet zonder precies de zelfde programmeertaal/API te gebruiken. Als er een exclusief recht ligt op de programmeertaal/API, en de kant van de compiler/runtime/library/service dus maar door één partij mag worden geleverd, dan krijg je gegarandeerd een vendor lock-in.

      (*) Op de één of andere manier heeft “creatief” hier een beetje een sarcastische, negatieve lading voor programmeurs. Een beetje zoals “creatief boekhouden” ook een negatieve lading heeft.

      1. Er is wel een groot verschil. Iedereen kan een eigen API toevoegen aan een programmeertaal. Je kan dus prima een eigen java API maken en toevoegen aan een bestaande programmeertaal. Google had dus best een eigen Android API kunnen toevoegen aan de Java programmeeeromgeving van Android om onderscheid te houden tussen de Java omgeving vanSun/Oracle en de Java omgeving op android. Dat maakt natuurlijk de java code op android minder interoperabel maar dat is een keuze. Ze hadden ook een licentie kunnen vragen aan Sun/Oracle om hun API te gebruiken en daarmee meer interoperabel kunnen zijn met bestaande code.

        1. Iedereen kan een eigen API toevoegen aan een programmeertaal. Je kan dus prima een eigen java API maken en toevoegen aan een bestaande programmeertaal. Google had dus best een eigen Android API kunnen toevoegen aan de Java programmeeeromgeving van Android om onderscheid te houden tussen de Java omgeving vanSun/Oracle en de Java omgeving op android.

          Iedereen(*) kan ook een eigen programmeertaal toevoegen aan een bestaand systeem, en zeker Google, aangezien Google controle heeft over het complete ontwerp van Android, en Google de expertise heeft om zelf programmeertalen te maken (zie bijv. Go).

          (*) Althans, de mensen die daar de vaardigheden voor bezitten; maar dat geldt natuurlijk ook voor APIs.

          1. Iedereen(*) kan ook een eigen programmeertaal toevoegen aan een bestaand systeem, en zeker Google, aangezien Google controle heeft over het complete ontwerp van Android, en Google de expertise heeft om zelf programmeertalen te maken (zie bijv. Go).

            Java is vrijgegeven door Sun zoals bijvoorbeeld C# is vrijgegeven door Microsoft. Java als programmeertaal mag dus gewoon gebruikt worden door Google of iedereen anders. Daar kan Oracle dus geen licentie rechten voor vragen. Google mag de basisprogrammeertaal Java sowieso gewoon gebruiken voor android.

            1. Dat kan wel zo zijn, maar dat is dan een verschil dat door Sun is aangebracht: dat ze de taal wel hebben “vrijgegeven”, en de standaard library API niet. Ze hadden het ook andersom kunnen doen, of alles vrijgeven, of niets.

              Maar ik heb mijn punt volgens mij wel gemaakt, dat er op zich geen belangrijk verschil is tussen programmeertalen en APIs. En als dat zou betekenen dat beide niet beschermd kunnen worden, dan maakt het ook niet meer uit wat Sun nou wel of niet heeft “vrijgegeven”.

              1. Ik denk zelfs dat Sun ook nog de API van Java standaard edition (SE) heeft vrijgegeven onder bepaalde voorwaarden voor de overname door Oracle maar hoe Oracle daarmee toch een claim tegen Google kunnen doen weet ik niet precies.

                1. Ik denk zelfs dat Sun ook nog de API van Java standaard edition (SE) heeft vrijgegeven onder bepaalde voorwaarden voor de overname door Oracle maar hoe Oracle daarmee toch een claim tegen Google kunnen doen weet ik niet precies.

                  Ik heb dat nog even nagezocht en het blijkt dat Sun alle Java code onder GPL licensies beschikbaar heeft gesteld en Google de android API code onder de daarmee absoluut niet compatible Apache licenties.

                  Google kan, door in hun gekopieerde Java API’s voor android geen gebruik te maken van de sterk copyleft GPL licentie maar in plaats daarvan van de NIET copyleft Apache licentie, makkelijke allerlei Google only elementen op Android toevoegen die gebruik maken van de API’s op android zonder dat ze zelfs die zaken open source hoeven te maken.

                  Eigenlijk is dat wel grappig. Google wilde geen gratis vrije copyleft licentie voor de Java API’s gebruiken omdat ze zelf op Android allerlei Google only onderdelen niet open wilden maken maar ze wilden tegelijk niet betalen voor een licentie op de API’s zonder die GPL licentie.

              2. Volgens het hof:

                It is undisputed that the Java programming language is open and free for anyone to use. Except to the limited extent noted below regarding three of the API packages, it is also undisputed that Google could have written its own API packages using the Java language. Google chose not to do that. Instead, it is undisputed that Google copied 7,000 lines of declaring code and generally replicated the overall structure, sequence, and organization of Oracle’s 37 Java API packages.

  3. Nog even in een aparte reactie. Je zegt “Dit kan nog wel eens heel hinderlijk worden want heel veel internet-API’s worden beheerd door Amerikaanse bedrijven. ” Het probleem zit hem natuurlijk vooral bij API’s die door derden kunnen worden gehost. Dus de Facebook-API of Twitter-API zullen nooit dit issue hebben, want dat gebruik wordt al gereguleerd door de ToS van Facebook respectievelijk Twitter. En er is maar 1 Facebook, als ik de Facebook-API nabouw en zelf ga hosten, ik denk niet dat iemand dat iets kan schelen. Ik kan dan ook echt niet ineens concurreren met Facebook.

    Dan kan je hooguit doelen op de publieke internet standaarden zoals HTTP, SMTP etcetera. Maar die worden niet beheerd door Amerikaanse bedrijven.

    Dus kan je voorbeelden noemen van API’s waar dit een issue bij zou kunnen worden?

    1. Behalve dan dat HTTP (C) The Internet Society (1999). is, en SMTP (C) The Internet Society (2001). Dat is dan weliswaar een non-profit, maar de specificaties van HTTP en SMTP zijn zeker niet public domain.

    2. De standaard C bibliotheken zijn nu een ISO standaard, maar uiteindelijk zijn ze afgeleid van het werk van Dennis Ritchie en Brian Kernighan. Al dat afleiden kon natuurlijk prima toen men werkte onder de aanname dat APIs niet onder het auteursrecht vielen. Nu dat vooralsnog niet zo blijkt te zijn heeft er dus iemand een Copyright op de originele api waarvan alle volgende afgeleide werken zijn.

      Idem met de diverse Unix APIs, waarvan de auteursrechten nu bij Attachmate liggen. Gelukkig voor ons is door wat rechtzaken en settlements uit het verleden het auteursrecht op Unix ‘unenforcable’.

      Een project als WINE om windows software onder nx draaiend te krijgen heeft ook opeens een probleem. Zij her-implementeren deels de windows api om die software te draaien. Met deze uitspraak kan MS ze de nek omdraaien, tenzij het project natuurlijk volledig naar buiten de VS uitwijkt. Maar een heleboel devs zullen er dan niet meer aan mee kunnen werken.

      SaMBa is een onafhankelijke implementatie van het Server Message Block protocol welke nu ook opeens een probleem heeft. Daar gaat de interoperabiliteit met windows.

      Of nfs veilig is hangt er vanaf wat voor een licentie Sun heeft gegeven toen het de ONC RPC standaard publiceerde.

      1. Voor Samba ligt de zaak weer anders omdat Microsoft door de EU (Mededinging) gedwongen is om de interface en documentatie vrij te geven. Nu komt de (zeer gerechtvaardigde vraag) vraag hoe legaal het is om het in Australië ontwikkelde Samba in EUropa op je computer te installeren en dan mee te nemen naar de VS. Mag ik dan in de VS mijn laptop aan een bedrijfsLAN hangen? (De LANeigenaar vindt het goed.)

  4. 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?

    Oracle betwist niet het gebruik in een programmeertaal maar het kopieren van de Java API naar een identieke Android (java) API.

    Google had natuurlijk best een eigen API kunnen schrijven met eigen functienamen en eigen parameters (zoals de API’s op iphones of windows phones). Die Android API had ook dan nog best vrijwel dezelfde functionaliteit kunnen bieden als de Java API want die functionaliteit is niet beschermd. Dat heeft Google echter niet gedaan. Die hebben letterlijk dezelfde naamgeving en parameters gebruikt omdat ze daardoor konden profiteren van enorm veel documentatie en bergen bestaande code die voor java geschreven was en die zonder conversie naar android kon worden overgezet omdat de API calls letterlijk hetzelfde waren gemaakt.

  5. 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.

    Hier zit dus volgens mij het probleem met auteursrecht en software. Er zijn twee soorten creativiteit: de creativiteit van de kunstenaar, die leidt tot een artistiek resultaat, en de creativiteit van de uitvinder/ingenieur, die leidt tot een nuttig resultaat. Voor de eerste soort creativiteit is traditioneel het auteursrecht, voor de tweede het patentrecht. Software kan heel creatief zijn, maar wel op de tweede manier. James Watt kreeg ook geen auteursrecht op zijn creatieve arbeid bij het maken van de stoomlocomotief, wel een patent. Het wringt ontzettend als je iets dat bedacht is voor muziek, literatuur en beeldende kunst gaat toepassen op besturingssystemen voor mobieltjes en spreadsheets.

    1. Je probeert auteurrecht te vernauwen tot kunst maar het auteursrecht beschermd ook bijvoorbeeld websites, artikelen van journalisten, schoolboeken geschreven door leraren of catalogussen van bedrijven of andere werken als deze maar originele werken zijn. Iedereen mag (uit bovenstaand voorbeeld) best zelf een ander schoolboek schrijven dat precies dezelfde kennis bevat maar je mag alleen niet blindelings het originele werk kopieren.

      Zo is het ook voor Google. Die mogen best eigen Java API’s maken maar mochten dus niet zonder meer de code kopieren waarin de API’s van Sun/Oracle zijn gedefinieerd. Overigens kan het nog steeds dat Google dat wel mocht onder fair use (alhoewel dat minder waarschijnlijk geworden is omdat het hof daar wel enige meningsvorming over heeft afgegeven)

  6. Dat weet ik, maar auteursrecht is voor unieke, creatieve werken, niet voor “methods of operation”. Bij een kookboek zijn niet de recepten an sich beschermd – zelfs niet als het hele bijzondere, vernieuwende recepten zijn met allemaal molecular gastronomy – maar alleen het hele boek als compleet werk.Het boek waarin Oracle de Java API beschrijft is beschermd, maar de API zelf is een soort recept. Toen computers nog rekenmachines heetten, was er niemand die op het idee kwam dat je de wijze van bediening onder het auteursrecht zou vallen.

    Nu vind ik wel dat software beschermd moet worden, ook de API van Java. Alleen had dat nooit onder het mom van auteursrecht moeten gebeuren. Er hadden aparte regels moeten komen voor software. Dat klinkt misschien moeilijk doen, maar er is bijvoorbeeld ook kwekersrecht, dat specifiek over gewassen gaat (zodat boer Piet niet een paar bollen kan kopen van het nieuwe ras dat boer Kees met veel tijd en moeite heeft ontwikkeld en daar zijn eigen velden mee vol te zetten), omdat er zeer specifieke zaken spelen.

    Nog iets anders: waarom is de site zo traag?

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.