Google wint van Oracle, maar de rest van de wereld heeft daar weinig aan

Google heeft geen inbreuk gemaakt op het copyright van softwarebedrijf Oracle toen het de code uit de programmeertaal Java gebruikte voor zijn mobiele besturingssysteem Android. Dat meldde RTL Nieuws onlangs. De Amerikaanse Supreme Court bepaalde namelijk dat de relevante code een fair use was onder eventuele auteursrechten van Oracle op diens Java-implementatie. Leuk voor Google, maar een uitspraak dat iets fair use is, daar heeft de rest van de wereld weinig aan. De kern van de zaak was namelijk: rust er überhaupt auteursrecht op een API definitie, wat de betreffende regels code uiteindelijk waren.

De zaak Google/Oracle draait om de universele programmeertaal Java, die begin jaren negentig is ontwikkeld door Sun Microsystems. In 2007 kwam het voor mobiele apparaten ontwikkelde besturingssysteem Android op de markt. Om ontwikkelaars over de streep te trekken Android-applicaties te maken, had Google daarin verschillende API’s opgenomen. Deze API’s bevatten elementen die ook aanwezig waren in de API’s van Java en droegen bovendien dezelfde namen. Alleen, de implementatie was verschillend.

Dat mag, zo dachten de meeste juristen destijds. Op een definitie of een naam rust geen auteursrecht. De implementatie wel, maar die was dus niet overgenomen. Desondanks kwam dit voor de Supreme Court en die bepaalde tot veler verrassing dat je op een API wél auteursrecht kunt hebben. Dit zou betekenen dat het interface-conform ontwikkelen van een implementatiekloon juridisch onmogelijk zou zijn, vandaar dat Google er met een truc een nieuwe zaak van maakte.

Die nieuwe zaak ging over fair use: mag je andermans werk gebruiken zonder toestemming als dat eerlijk of redelijk is, even kort gezegd. Dit Amerikaanse begrip is breder dan ons citaatrecht, parodierecht et cetera: weliswaar zijn al die dingen van ons vormen van fair use, maar wij hebben in Europa geen algemeen criterium “jamaar dat is toch doodnormaal, kom nou toch hoezo mag dat niet”. Dat is zowel een voordeel als een nadeel. Een nadeel, want als het niet in de wet staat dan vereist het dus toestemming. Maar ook een voordeel, want je weet nu precies wat wel en niet mag.

In de VS hebben ze dus die open norm, en de Supreme Court oordeelt nu dat Google daaronder dit mocht doen. Google had alleen die regels broncode gekopieerd – die API definities overgeschreven – die ze echt nodig had:

Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. The record demonstrates numerous ways in which reimplementing an interface can further the development of computer programs.
Het probleem is alleen: geldt dit voor íedere herimplementatie van andermans API? Hoe ver gaat dat “what was needed”, hoe anders moet jouw eigen programmeeromgeving zijn en moet het gaan om een “bekende” (familiar) programmeertaal? Als ik de API van zeg de elearning-provider op de hoek kopieer, val ik dan hieronder? En dat is dan alleen nog maar wat ik in vijf seconden kan bedenken na het lezen van deze zin; kun je nagaan wat een advocaat van Oracle daarvan maakt als hij zes maanden fulltime 800 dollar per uur daarvoor mag rekenen.

Het Hof danst om de vraag heen of haar vorige uitspraak over auteursrecht op API definities terecht was. Dat is ook lastig want zelfs de Supreme Court kan niet zomaar haar eigen precedenten opzij zetten. Men houdt het dan ook bij

We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. … As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google).
Dit laat dus het principe overeind dat er best auteursrecht op een API als zodanig kan zitten. Weliswaar niet heel veel, maar kennelijk net genoeg. En hoe je het idéé van een API hergebruikt zonder de letterlijke functienamen en dergelijke te gebruiken, daar laat men zich wijselijk niet over uit.

We kunnen dus nu wel roepen dat Google gewonnen heeft, maar de conclusie die op lange termijn blijft staan is dat vrijwel iedere API auteursrechtelijk beschermd is, met als gevolg dat interoperabiliteit vrijwel onmogelijk wordt. Immers, wil je die herimplementeren dan heb je toestemming nodig tenzij je in een beperkte uitzondering valt.

Dit versterkt de macht van rechthebbenden enorm. En ja, ik maak me daar ook bij Europese bedrijven zorgen over. De meeste innovatieve softwaredienstverleners opereren immers vanuit de VS. De ervaring leert dat hun gedrag (en contractuele voorwaarden) sterk Amerikaans georiënteerd zal zijn, waarbij men niet snel Europeesrechtelijk water bij de wijn zal doen. Daar komt bij dat een concurrent binnen dit juridisch kader geen API-compatibele eigen dienst kan aanbieden, omdat dit op auteursrechtelijke bezwaren zal stuiten in de VS – en de dienst aldaar niet aanbieden is commercieel dan geen optie.

Daar staat natuurlijk tegenover dat zeker de web API’s vaak al onder bepaalde voorwaarden worden aangeboden, zodat de praktijk niet direct zal wijzigen. Maar API-aanbieders hebben nu wel een stuk steviger fundament voor hun voorwaarden, namelijk dat wie deze schendt, tevens het auteursrecht te buiten gaat. Een app die jouw voorwaarden schendt, kun je afsluiten van de API en dat is het. Een app die jouw auteursrecht schendt, kun je van de markt halen onder opvordering winst en een verbod voor de toekomst. Dus nee, ik vind deze ‘overwinning’ best zorgelijk.

Arnoud

10 reacties

  1. Voor mijn begrip: worden er nog creatieve eisen gesteld aan auteurschap? Geef bijvoorbeeld 10 programmeurs een beschrijving van een applicatie waar een API voor moet worden ontworpen, en je krijgt waarschijnlijk slechts 2 architecturen die erg op elkaar lijken. Dan kan je beargumenteren dat de API, vaak inclusief naamgeving, bijna logisch volgt uit de onderliggende applicatie . Dat is wat anders dan een boekje over 110010 tinten grijs schrijven…

    1. Je kan het ook omdraaien. Het creatieve gedeelte zit ‘m in het externe gedrag van het systeem, beschreven in API’s. Hóe het systeem dit uitvoert volgt hier grotendeels uit. Waarom zou er geen auteursrecht rusten op het unieke externe gedrag, en wel op de code om parameter x op te slaan?

    2. De eis voor auteurschap is precies dat: creativiteit in je uitwerking. De vraag is natuurlijk wanneer je een uitwerking creatief moet noemen. Want stel dat het gegeven is dat er twee inputs kunnen zijn en dat jouw uitvoer daar van afhankelijk is. Dan zijn er op zich keuzes: een if statement, een case-structuur of een ternaire operator. Maar is dat creatief? Of is dat gewoon wat je doet?

      Ik denk dat bij het bedenken van een API je wél net genoeg creativiteit hebt. Naamgeving is toch een lastig ding, net zoals wat je waar in de API stopt, welke variabelen verplicht/optioneel et cetera. Natuurlijk, iedereen zal zeg maar open() en close() functies definiëren maar kom je daarna met lezen per regel of per blok data? Worden newlines automatisch omgezet naar spaties, worden HTML entities geëscaped of niet? Heet je functie isIngelogd, isAangemeld,geldigeSessie en retourneert deze true/false of de inlognaam dan wel een null?

  2. Oh. Arnoud heeft het net gecorrigeerd en nu reageerde ik nergens op. Verwijder dit ook maar.

    Zucht. Cache! Zelfs met harde reload zag ik niet dat bovenstaande bewerking wél door was gekomen.

  3. De Supreme Court had nog wel enige vrijheid. De eerste zaak is namelijk nooit door hen behandeld. Door het niet behandelen blef de uitspraak van het Federal Circuit overeind dat een API copyrightable is.

    USSC doet dit wel vaker, als er geen verschillen in uitspraak tussen circuits zijn en als later er toch verschillen ontstaan pakken ze het alsnog op. Er zou dan echter een andere zaak moeten komen over APIs in een andere jurisdictie waar de uitspraak is dat die API niet copyrightable is. SC moet de zaak dan wel oppakken vanwege een cicuit split.

    De reden dat ze nu aannemen dat een API copyrightable is, is omdat er dus geen onderbouwing van de SC ligt en ze er zelf niet eerder naar gekeken hebben of alles wel echt copyrightable is. En als je het op Fair Use gooit, dan maakt het feitelijk niets meer uit voor deze zaak en hoeft men niet alsnog te kijken of men uberhaupt terecht die eerdere zaak geweigerd heeft te behandelen.

    Overigens is Justice Clarence Thomas een idioot die van geluk mag spreken dat hij voor het leven benoemd is. Nu verschillende uitspraken van de man gelezen waaruit volkomen duidelijk is dat hij niets van de materie begrijpt en niet de competentie heeft om zich te realiseren dat hij het niet begrijpt.

  4. Het hof heeft dus geprobeerd zowel de geit als de kool te sparen, en hebben daardoor de wolven (juristen) extra voer gegeven met werderom een extra laag onnodige complexiteit. Hadden ze het op de “merger doctrine” (ofwel, waar idee en expressie inelkaar samenvloeien, verliest auteursrecht zijn werking) gegooid, dan was dit voorkomen. Jammer.

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.