Google ging in de fout met het volgen van de Java-bibliotheek in Android.
Dat heeft het hof van beroep in Washington geoordeeld in de langslepende zaak tussen Google en Oracle. Die uitspraak heeft verreikende gevolgen.
Niet zozeer omdat Google nu misschien wel miljarden en miljarden dollars moet overmaken aan Oracle, maar omdat het duidelijk maakt dat het Amerikaanse rechtssysteem deze praktijk, die in de software-industrie vaker voorkomt, niet accepteert.
De zaak draait om de structuur van packages, classes en methodes in de standaardbibliotheek voor Java. Al vroeg in de ontwikkeling van Android kozen de ontwikkelaars ervoor om de loper uit te rollen voor derden die applicaties wilden ontwikkelen, of ‘apps’ zoals die later zouden gaan heten. In die tijd was dat nog niet heel gebruikelijk.
Daarvoor adopteerden ze Java als de programmeertaal voor applicatieontwikkeling. Dat was destijds een product van Sun Microsystems, maar de taal zelf was vrij te gebruiken en Android - toen nog een zelfstandig bedrijf - schreef een eigen implementatie, vrij van de Sun-code.
Een programmeertaal als Java is echter veel meer dan een taalspecificatie. Om er iets nuttigs mee te doen, heb je al heel snel externe code nodig; in- en output, string-bewerkingen en basale datastructuren zijn bij Java geen onderdeel van de taal, maar ondergebracht in de standaardbibliotheek. Om Android wat betreft die functionaliteit compatibel te houden met standaard Java, kopieerden de ontwikkelaars de declaraties van classes en methode-aanroepen van het desbetreffende deel van deze bibliotheek. De inhoud, de implementerende code, schreven ze zelf opnieuw.
Sun vond dit wel oké, maar het bedrijf werd in 2009 overgenomen door Oracle, en dat stapte een jaar later naar de rechter omwille van het gebruik van Java in Android: Google zou patenten, merknamen en copyrights schenden van Oracle. Hoewel het merendeel van de claims al snel door de mand viel, bleef de kwestie van de gekopieerde structuur plakken.
De kwestie heeft al een aantal rechtszaken achter de rug. In een eerste zaak oordeelde de rechter dat de structuur een specificatie vormt en niet onder copyright kan vallen, maar het hof van beroep was het daar niet mee eens en verwees de zaak naar hem terug. Vervolgens vond een jury dat Google toch niks misdaan had, omdat het gebruik van de structuur onder fair use valt; de ontwikkelaars gebruiken maar een klein deel van de code en bouwen daar iets nieuws mee.
Voor veel ontwikkelaars kwam die uitspraak als een opluchting. Het is helemaal niet ongebruikelijk om een concurrerende, compatibele versie te maken van een bestaand softwarepakket. Beroemd is de Bios-versie van Phoenix uit de jaren tachtig, die de gevestigde code van IBM naar de kroon stak.
Sterker nog: de vrije beschikbaarheid van api’s was essentieel voor de ontwikkeling van de computerindustrie, schreven 77 gerenommeerde informatici in 2014 - toen Google tevergeefs probeerde om de zaak bij het hooggerechtshof aanhangig te maken. In de brief werden tal van voorbeelden aangehaald. C kon zich bijvoorbeeld profileren als wijdverbreide taal omdat iedereen die dat wilde de standaardbibliotheek kon namaken, zo schreven de informatici.
Maar anderen vonden dat Google inderdaad te ver was gegaan met het kopiëren van de codestructuur om een compatibele implementatie te maken. Oracle ging dan ook in hoger beroep en vroeg het hof om te oordelen over de vraag of dit nog onder fair use valt. Dezelfde drie rechters als in de eerdere zaak kiezen nu opnieuw de kant van Oracle: het hof vindt dat er geen sprake is van fair use. Sterker nog: alle vier de argumenten waarop de jury wel tot de fair use-conclusie kwam, werden door het hof neergesabeld.
Beschrijving of code?
Wat de zaak complex maakt, is het duale karakter van de codestructuur. Aan de ene kant is het code, maar tegelijkertijd is het ook een interfacebeschrijving, of api.
Wanneer het bijvoorbeeld om een webservice zou gaan, zou de situatie duidelijker zijn: een api-beschrijving is daar een document dat de gebruikte commando’s en parameters opsomt. Een alternatieve implementatie kan volledig uit nieuwe code bestaan en hoeft alleen die namen over te nemen. Maar wie een alternatieve implementatie van een softwarebibliotheek maakt, moet noodgedwongen de hele organisatie overnemen.
Het lijkt erop dat de lagere rechter steeds is uitgegaan van het eerste standpunt: de structuur is niet meer dan een api-beschrijving. De drie rechters van het hof lijken juist steeds uit te gaan van het tweede geval: het is code waar copyright op rust.
Voor beide standpunten zijn argumenten te bedenken. Een aanzienlijk deel van de tijd en moeite van softwareontwikkeling gaat juist zitten in de organisatie van code, dus het is te beargumenteren dat de structuur een creatief werk is. Bovendien: het is nu eenmaal code die geschreven wordt.
Maar aan de andere kant vormen de structuurbeschrijvingen maar een heel klein deel van het totale aantal coderegels. De logica, het ‘echte werk’, zit bovendien in de implementerende code
Daar komt ook nog eens bij dat een ontwikkelaar geen keuze heeft: als de bibliotheek compatibel moet zijn, moet de structuur wel worden overgenomen. Door nu te stellen dat die organisatie niet vrij te gebruiken is, zegt het hof dus eigenlijk dat het ontwikkelen van een alternatieve, compatibele implementatie van een softwarebibliotheek ook niet zomaar mag.
Kanttekening
Er is wel een grote kanttekening te plaatsen bij die interpretatie. Er spelen allerlei factoren mee die specifiek zijn voor deze zaak, dus de algemene conclusie is niet zonder meer te vertalen naar andere situaties. Zo woog de jury die voor fair use oordeelde het argument mee dat de Java-taal niet te gebruiken is zonder bepaalde delen van de standaardbibliotheek. De bibliotheek kan dus in zekere zin als onderdeel van de taal zelf worden beschouwd.
En er zijn allerlei factoren die niks met technologie te maken hebben. Oracle beargumenteert bijvoorbeeld heel melodramatisch dat het door Android geen kansen meer had om met Java door te breken in de mobiele business. Hoewel die claim nauwelijks serieus genomen kan worden, is die mogelijkheid alleen al genoeg om Android als concurrerend product te beschouwen, wat implicaties heeft voor de fair use-wetgeving.
Zo zijn er meer haken en ogen. Bijvoorbeeld of Google Android alleen wilde gebruiken voor telefoons of ook voor auto’s en laptops. Dat Google Android als opensource weggaf, waardoor het niet puur commercieel was. Dat Google aanvankelijk wel probeerde om een licentieovereenkomst te sluiten met Sun. Enzovoorts. Het hof gaat in zijn argumentatie dan ook uit van dit soort factoren en doet geen algemene uitspraken over het al dan niet toestaan van codestructuur als api-beschrijving voor herimplementaties.
Maar die kanttekening doet er niet veel toe. Een ontwikkelaar die een compatibele implementatie van een softwarebibliotheek maakt, weet nu dat hij vroeg of laat het copyright van de originele partij kan schenden. Zelfs met de juridische middelen die een bedrijf als Google tot zijn beschikking heeft, is daar niet aan te ontkomen.
Het vonnis werpt ook nieuwe vragen op. Want hoe zit het nu met andere typen api’s, die wel uit alleen beschrijving bestaan? Hoe is het nabootsen daarvan geregeld? En mag je in het geval van Java nog wel een class uit de standaardbibliotheek overerven, of schend je daarmee ook het copyright?
Overigens zou de situatie nog kunnen veranderen, want Google heeft nog enkele beperkte mogelijkheden om in beroep te gaan. De kans is echter groot dat de zoekgigant de beurs kan trekken; Oracle claimde tot nog toe een schadevergoeding van 8,8 miljard dollar, maar kan dat verder oprekken. Om het bedrag te bepalen, moet er weer een nieuwe rechtszaak komen.
