Het Amerikaanse Hooggerechtshof heeft onlangs een beslissing genomen in de zaak Google v. Oracle. Een belangrijke vraag was of de code van API’s auteursrechtelijk kan worden beschermd, zoals Oracle beweert, of dat het strikt functionele code is die hooguit zou kunnen worden beschermd op grond van het octrooirecht, zoals Google beweert. De partijen waren het erover eens dat een beslissing ten gunste van de andere partij de hemel zou doen neerstorten. Maar is het zo ver gekomen?
Historiek van Google v. Oracle
De zaak vloeit voort uit het feit dat Google bij het creëren van het Android-besturingssysteem aanvankelijk 11.500 regels JAVA-declaratiecode kopieerde – de code die aangeeft welke JAVA-routines door programmeurs kunnen worden aangeroepen – naast de uitvoerig georganiseerde taxonomie die bekend staat als de “structure, sequence, and organization” (“SSO“) van de Java API-pakketten.
Oracle (dat JAVA verworven had bij de aankoop van Sun) sleepte Google voor de rechter met als argument dat de API’s auteursrechtelijk beschermd waren, en vorderde 8.8 miljard USD schadevergoeding wegens auteursrechtelijke inbreuk.
Twee district court jury’s stelden Google in het gelijk, maar werden teruggefloten door een beslissing van het Federal Circuit dat stelde dat API’s wel degelijk auteursrechtelijke bescherming genoten, en dat Google zich niet kon beroepen op een uitzondering van “fair use”. Dit laatste is een doctrine in het recht van de Verenigde Staten die beperkt gebruik van auteursrechtelijk beschermd materiaal toestaat zonder eerst toestemming van de auteursrechthebbende te hoeven verkrijgen. Fair use is één van de beperkingen van het auteursrecht, bedoeld om de belangen van auteursrechthebbenden in evenwicht te brengen met het algemeen belang van een bredere verspreiding en een breder gebruik van creatieve werken, door als verweer tegen vorderingen wegens inbreuk op het auteursrecht bepaalde beperkte vormen van gebruik toe te staan die anders als inbreuk zouden kunnen worden aangemerkt.
Het belang van de discussie kan niet overschat worden: waren de partijen het ten gronde helemaal oneens, dan deelden ze wél de mening dat een beslissing ten gunste van de andere partij de hemel zou doen neerstorten. Volgens Google is de hele software-industrie immers geëvolueerd op basis van de veronderstelling dat de declaratiecode van API’s vrij te kopiëren is, en zou het onverstandig zijn om deze vaste verwachtingen teniet te doen. Volgens Oracle daarentegen zou het toestaan van dergelijk kopiëren de auteursrechtelijke bescherming van software ondermijnen en de industrie tot stilstand brengen.
Maar is een API eigenlijk wel software?
Een API of Application Programming Interface is de toegangspoort die het mogelijk maakt om de functionaliteit van een software oplossing beschikbaar te maken voor andere systemen. Het slaat dus een brug tussen verschillende computersystemen, en maakt het uitwisselen van informatie mogelijk.
Als je in je boekhoudprogramma wil weten hoe lang een factuur al onbetaald is, kan het zijn dat de applicatie elke dag voor alle onbetaalde facturen het aantal dagen met 1 verhoogt en dat vervolgens ergens opslaat. Het is echter evenzeer mogelijk dat het programma de factuurdatum ophaalt en elke keer uitrekent hoeveel dagen de factuur onbetaald is gebleven. De uitkomst is echter hetzelfde, en voor de functionaliteit van het programma is dat het enige dat telt. Een API zal hier zorgen voor een aantal vragen die kunnen worden gesteld, en de daarbij horende antwoorden. De manier waarop het antwoord wordt bepaald, is van geen belang.
Vanwaar het belang van auteursrechtelijke bescherming voor software en API’s?
Het auteursrecht is een steeds belangrijker instrument voor de bescherming van software. Als ijzeren regel geldt dat het auteursrecht alleen uitdrukkingen beschermt, en niet de ideeën die in de uitdrukkingen vervat zijn. In de context van computersoftware is het onderscheid tussen een uitdrukking en een idee echter vaak vaag.
Maar zijn er dan geen alternatieven?
Softwarebedrijven kunnen immers juridische bescherming zoeken voor computerprogramma’s op grond van bedrijfsgeheimen, octrooien en auteursrechten.
Bedrijfsgeheim
Om bescherming als bedrijfsgeheim te genieten, hielden de meeste softwarebedrijven de broncodes, algoritmen en gegevensstructuren geheim, en gaven zij alleen de binaire versie van het programma vrij. Hun licentieovereenkomsten bevatten gewoonlijk een bepaling die gebruikers verbiedt om reverse engineering toe te passen. Het is echter moeilijk om sommige zichtbare elementen, zoals de gebruikersinterface, geheim te houden. Bovendien hebben open source bedrijven zoals Oracle hun broncodes reeds openbaar gemaakt, zodat de regels rond bedrijfsgeheimen hun software zoals Java API niet langer kon beschermen.
Octrooien
Aangezien een computerprogramma van nature functioneel is, lijkt octrooibescherming beter geschikt om in de eerste plaats software te beschermen. Er zijn echter aanzienlijke hinderpalen voor octrooibescherming.
Zo is het “algoritme” van software een abstract idee dat niet octrooieerbaar is, tenzij er sprake is van “een ander inventief concept in de toepassing ervan”. Bovendien is er de strenge vereiste rond niet-vanzelfsprekendheid en nieuwheid, het gebrek aan middelen bij onderzoekers om verleende octrooien te controleren, en het dure en tijdrovende aspect van octrooiaanvragen.
Wat is dan het probleem met auteursrechtelijke bescherming voor API’s?
Dat de auteurswet de belangrijkste rechtsgrond is voor de bescherming van software, staat buiten kijf. De huidige auteurswet impliceert de bescherming van computerprogramma’s, maar wat zijn dat? De rechter moet dus bepalen welke elementen beschermbaar zijn: broncode, interface, modulaire structuur, gegevensstructuur en/of functie van het programma.
Het proces om software te maken zou op de een of andere manier analoog kunnen zijn met het schrijven van een roman. Om een computerprogramma te maken, moet het softwareteam vijf stappen doorlopen:
- het definiëren van het doel en de functie van het programma;
- het ontwerpen van de gegevensstructuur;
- het ontwerpen van de modulaire structuur;
- het ontwerpen van de gebruikersinterface; en
- het coderen van het programmaontwerp uit de delen twee, drie en vier in broncode.
Het is onbetwistbaar dat broncodes auteursrechtelijk beschermd zijn. Meestal rijst de vraag of de structuur, de volgorde en de organisatie beschermd moeten worden, oftewel de “SSO”.
Rechtspraak en rechtsleer baseren zich op de dichotomie idee/expressie om een dergelijke beslissing te nemen. Auteursrechtelijke bescherming strekt zich immers uit tot de uitdrukking van een idee, maar niet tot het onderliggende idee zelf. Maar van “uitdrukking” of “idee” bestaan geen juridische definities. Het onderscheid idee/uitdrukking is veeleer een onderscheid dat een beleidskeuze weerspiegelt over welke elementen van een werk onderworpen moeten zijn aan de exclusieve rechten van de auteursrechthebbende en welke elementen vrij moeten zijn voor anderen.
Een computerprogramma is samengesteld uit samenhangende procedures die samen moeten werken, en de SSO is de manier om procedures samen te brengen voor een gewenst resultaat. Net daarom bevinden de SSO’s zich tussen het algemene idee (het doel of de functie van het programma) en de uitdrukking (codes). Indien de auteursrechtelijke bescherming beperkt wordt tot codes, zullen de intellectuele investeringen niet doeltreffend beschermd worden, omdat andere programmeurs gemakkelijk de code zouden kunnen wijzigen op basis van de architectuur van de auteursrechtelijk beschermde software. In een dergelijke glijdende schaal van dichotomie idee/expressie, moet dus een pragmatische lijn worden getrokken.
De beslissing van het Hooggerechtshof: een Salomonsoordeel
Het Hooggerechtshof vermeed echter op slinkse wijze de fundamentele vraag of Oracle daadwerkelijk auteursrecht kon laten gelden op de betrokken coderegels in JAVA. Louter om het conflict te kunnen oplossen, heeft de meerderheid van de rechters zich achter de aanname geschaard dat deze code daadwerkelijk auteursrechtelijk beschermd zou zijn, waardoor het Hooggerechtshof zich kon beperken tot de vraag of Google’s gebruik van die code al dan niet werd gerechtvaardigd door de doctrine van “fair use”.
Er zijn daarbij vier determinerende factoren om te bepalen of er sprake is van fair use:
- het doel en de aard van het gebruik;
- de aard van het auteursrechtelijk beschermde werk;
- de hoeveelheid en de wezenlijkheid van het gekopieerde gedeelte in verhouding tot het auteursrechtelijk beschermde werk als geheel; en
- het effect dat het gebruik heeft op de marktwaarde van het auteursrechtelijk beschermde werk.
Het Hooggerechtshof oordeelde dat al deze vier factoren in het voordeel wogen van Google’s kopiëren van de JAVA code, en besliste dus dat “Google’s kopiëren van de Java SE API, die alleen die regels code bevatte die nodig waren om programmeurs in staat te stellen hun opgebouwde talenten in een nieuw en transformatief programma aan het werk te zetten, rechtens een eerlijk gebruik van dat materiaal vormde”.
Besluit
De tech industrie hield de zaak Google v. Oracle nauwlettend in de gaten: een uitspraak ten gunste van Oracle had immers significante gevolgen kunnen hebben voor de ontwikkeling van software in het verleden en de toekomst, gezien het veelvuldige gebruik van API’s. Google en andere ontwikkelaars van Android-gebaseerde software, hadden daarentegen verschillende zorgen geuit, waaronder de impact op interoperabiliteit en software innovatie.
Al is het geschil beslecht, grote duidelijkheid in de fundamentele kwestie rond het auteursrechtelijke statuut van API’s is er met deze beslissing nog steeds niet gekomen. Of positiever gesteld: de hemel is nog niet op ons neergestort.
Stel jij je software platform echter ook open via API’s? Maak dan vooraf een analyse van hoe je dit wil aanpakken, en zorg voor een optimale juridische omkadering. Bij vragen hierover kan je ons steeds contacteren via hallo@dejuristen.be.
Geschreven door Kris Seyen, Partner deJuristen
