Tien jaar nadat Oracle Google voor het eerst aanklaagde vanwege de code in het Android-platform, staan de twee techgiganten nu eindelijk tegenover elkaar in het Hooggerechtshof. Sindsdien zijn er drie rechtszaken geweest en twee beroepszaken. Miljarden dollars staan op het spel; vele miljoenen zijn waarschijnlijk uitgegeven aan een parade van doorgewinterde procesvoerders, getuige-deskundigen en bizarre processtukken die bedoeld zijn om programmeren uit te leggen aan niet-technische jury’s. Dit alles kan tot een anticlimatisch einde komen op woensdagochtend, met een teleconferentie van het Hooggerechtshof in het midden van een pandemie.
Toen Google voor het eerst Android ontwikkelde, besloot het om het mobiele platform compatibel te maken met Java. In die tijd werden apps voor de iOS-omgeving geschreven in Objective-C, een taal die vergelijkbaar was met het alomtegenwoordige C, maar verder vrijwel alleen werd gebruikt in de context van de ontwikkeling van iOS-apps. Apple had een aanzienlijke voorsprong op mobiel gebied.
Google wilde Android concurrerend maken door het platform interoperabel te maken met Java, een populaire programmeertaal met een robuuste ontwikkelaarsgemeenschap. Om dat te doen heeft het bedrijf verschillende Java API’s opnieuw geïmplementeerd, waaronder de 37 waar het in deze rechtszaak om gaat. Voor Oracle en Google gaat de rechtszaak over de vraag of Oracle – dat eigenaar is van Java Standard Edition – nu recht heeft op een stuk van Android, voor een bedrag van miljarden dollars. Voor alle anderen gaat de rechtszaak over de vraag of taalcompatibiliteit gelijk staat aan schending van het auteursrecht.
Op zijn zachtst gezegd was het een andere wereld toen de zaak voor het eerst werd aangespannen. Beide bedrijven zijn in andere handen overgegaan – de rechtszaak begon toen Larry Ellison nog aan het roer stond van Oracle en Eric Schmidt de CEO van Google was. Google is nu een dochteronderneming van Alphabet. Android is aan versie 11 toe. Het enige dat hetzelfde lijkt te zijn gebleven is de populariteit van Java als programmeertaal.
Maar ver weg van Silicon Valley heeft zich een zee van verandering voorgedaan die veel meer omvat dan slechts 6 miljard dollar en de toekomst van het auteursrecht. Drie zetels bij het Hooggerechtshof zijn vrijgekomen sinds de laatste keer dat Google het Hooggerechtshof vroeg om zijn zaak te beoordelen. In 2014 weigerde SCOTUS certiorari, waardoor de zaak terugging naar de rechtbank in San Francisco voor een nieuw proces. Sindsdien is een rechter met pensioen gegaan en zijn er twee overleden – meest recentelijk rechter Ruth Bader Ginsburg.
Het absoluut minst belangrijke deel van Ginsburgs nalatenschap is dat zij de meest betrouwbare stem was in auteursrechtzaken, omdat zij de neiging had om in het voordeel van rechthebbenden te stemmen. Haar verlies betekent ook dat Google v. Oracle wordt behandeld door acht rechters en dus vatbaar is voor een verdeeld Hof. (In de auteursrechtzaak Lotus v. Borland uit 1996 was het Hof met acht rechters ook verdeeld en kon het geen nationaal precedent scheppen).
Toen Google v. Oracle in 2010 begon, ging het om zeven patenten en een auteursrechtclaim; in 2012 was de zaak teruggebracht tot slechts 37 Java API’s, bestaande uit ongeveer 11.500 regels code. (Schattingen schatten Android rond de 12 miljoen regels code.) De 11.500 regels code in kwestie werden geschreven in een “clean room”, een project afgezonderd van de bestaande code die ze aan het reverse-engineeren waren. Dit staaltje van engineering werd noodzakelijk toen de onderhandelingen tussen Google en Sun Microsystems – dat eigenaar was van het Java-platform – mislukten. Oracle nam Sun begin 2010 over; in augustus had het een rechtszaak tegen Google aangespannen.
Een application programming interface (API) in deze context is een verzameling van goed gedefinieerde interacties in softwareprogrammering. Het is een steno om snel toegang te krijgen tot diensten, bibliotheken en andere functies. Een API kan veelgebruikte of omslachtige code samenvatten, waardoor programmeurs kunnen bouwen zonder het wiel opnieuw te hoeven uitvinden.
Een API is niet precies een woordenboek, maar het komt er dicht genoeg bij in de buurt dat Oracle v. Google een enorm probleem vormt. Technisch gezien kun je in Java programmeren zonder gebruik te maken van de 37 Java API-pakketten waar het hier om gaat. Maar je zou waarschijnlijk niets nuttigs schrijven, aangezien die API’s java.lang en java.util omvatten, basispakketten die functies bieden zoals wiskunde of het weergeven van datums en tijden. Ik kan dit artikel technisch gezien ook zonder metaforen of vergelijkingen schrijven, maar dat is niet iets wat ik zou willen doen, of wat iemand zou willen lezen.
Voor alle duidelijkheid: de 37 Java API’s zijn in een clean room opnieuw geïmplementeerd. Oracle beweert niet dat ze woordelijk hetzelfde zijn, maar eerder dat de “structuur, volgorde en organisatie” van de API’s zo veel op elkaar lijken dat ze de auteurswet schenden. Hiermee wordt bedoeld dat de pakketten, klassen en methoden in deze API’s dezelfde naam hebben. Een regel code die is geschreven om te draaien in Java Standard Edition zal niet noodzakelijkerwijs draaien op Android, maar het zal een stuk dichterbij komen dan anders het geval zou zijn geweest.
De allereerste run op de rechtszaak resulteerde in een gesplitst proces in 2012 – een proces voor de octrooiaanspraken, en een tweede proces alleen voor de auteursrechtaanspraken. In de octrooizaak oordeelde de jury dat Google geen octrooien had geschonden. In de auteursrechtzaak ging het om twee afzonderlijke juridische kwesties: ten eerste of de declaratiecode en de “structuur, volgorde en organisatie” van de API’s auteursrechtelijk beschermd waren; en ten tweede of het gebruik door Google een eerlijk gebruik was. De rechter besliste over de vraag of er auteursrecht op de API’s rustte, en stuurde het fair use ter beoordeling naar de jury.
De jury liet zich niet uit over fair use. Maar de rechter – die toevallig als hobby code schreef – oordeelde dat de declaratiecode en SSO van de API’s toch niet onder het auteursrecht vielen. De Auteurswet is niet van toepassing op een “idee, procedure, proces, systeem, werkwijze”, en de manier waarop de pakketten, klassen en methoden waren benoemd en gesorteerd was te functioneel om auteursrechtelijk te kunnen worden beschermd.
Het was deze specifieke uitspraak die in 2014 door de Federal Circuit werd vernietigd. Omdat de eerste jury geen uitspraak had gedaan over fair use, moest in 2016 een geheel nieuwe jury worden bijeengeroepen voor nog een rechtszaak over fair use. De jury koos de kant van Google.
Maar in 2018 oordeelde de Federal Circuit – hetzelfde hof van beroep dat in 2014 de zaak had teruggestuurd naar de jury – dat de juryuitspraak moest worden vernietigd ten gunste van Oracle, omdat het tijdens het proces gepresenteerde bewijs duidelijk aangaf dat er geen fair use-bepaling kon worden bereikt, en daarom in de eerste plaats niet naar een jury had moeten gaan.
Het vernietigen van een jury-uitspraak is Big Judge Energy op een manier die zeker controversieel zal zijn voor het Hooggerechtshof, en het is waarschijnlijk dat het pleidooi van woensdag veel discussie zal bevatten over de rol van rechter versus jury in een auteursrechtzaak. De vraag wie wanneer mag beslissen over fair use is iets dat kan worden geëxtrapoleerd naar een heleboel verschillende rechtszaken (waar SCOTUS dol op is) en heeft ook niets te maken met wiskunde (waar SCOTUS niet dol op is).
Het echte hart van de zaak ligt helaas in het deel met al die wiskunde en dergelijke. De beslissing van het Hooggerechtshof in Google v. Oracle kan enorme gevolgen hebben voor de software-industrie, vooral omdat het Hooggerechtshof mogelijk de kwestie van de auteursrechten opnieuw aan de orde stelt – de vraag of de verklarende code en de structuur, volgorde en organisatie van de Java API’s überhaupt onder het auteursrecht vallen – die sinds 2014 niet meer aan de orde is geweest.
Deze decennialange rancune tussen Google en Oracle is niet een geheel rationele wedstrijd. Google’s herimplementatie van de Java API’s maakt deel uit van een lange traditie van iteratie die tot nu toe meestal als vanzelfsprekend werd beschouwd. Producten als Oracle’s eigen MySQL zijn ontstaan als iteraties van IBM’s SQL.
Dit wil niet zeggen dat copy-pasting het hart van Silicon Valley is. Maar er is een punt waarop je wilt stimuleren dat dingen er hetzelfde uitzien, in plaats van dat ze verschillend zijn omwille van het verschil. Om het grof uit te drukken: coderen is het proces van spreken met de machine. Maar heel weinig mensen die vandaag software ontwikkelen, spreken rechtstreeks met de machine. Software bestaat in lagen op iteratieve lagen, een spel van gefluister dat uiteindelijk het blanke metaal van de computer bereikt. Nieuwe talen worden afgeleid van de oude; nieuwe bibliotheken worden gebouwd op bestaande; afhankelijkheden worden op elkaar gestapeld als een spelletje Jenga dat elk moment kan eindigen. En Google v. Oracle is een zaak die zich afspeelt op een van de laagste niveaus van een voortdurend spel van Jenga.
We staan op het punt om uit te vinden of het Hooggerechtshof dat weet.
Correctie: In een eerdere versie van het artikel werd ten onrechte gesteld dat de Android-codebasis miljarden regels code omvat. Het gaat om miljoenen. We betreuren de fout.