De API: een IT-rechtelijk punt van zorg?

Kent u de wondere wereld van de API? We hebben het over de ‘bruggetjes’ die nodig zijn om twee softwareapplicaties met elkaar te laten communiceren en te laten samenwerken. De afkorting staat voor Application Programming Interface. In andere beeldspraak: de softwarematige deuren tussen de applicaties A en B die bedoeld zijn om gegevens uit te wisselen (= interoperabiliteit) en om elkaars functionaliteiten te gebruiken (= integratie).

Op talloze domeinen worden interfaces van dit soort gebruikt: social media, het betaalverkeer, de wegenkaarten in auto’s, e-commerce en zoveel meer. Het cruciale belang ervan voor de digitale wereld kan nauwelijks worden overschat. Welbeschouwd hangt het hele internet van API’s aan elkaar, ook al zijn de meeste gebruikers zich daar niet van bewust. Verstuurt uw autodealer vanuit zijn IT-systeem een aankoopbericht voor uw nieuwe bolide naar het systeem van de auto-importeur, dan hebben zij beide – verzender én ontvanger – een passende API als koppelvlak nodig.

Meerdere leveranciers betrokken

Het maken van deze digitale bruggetjes is een bijzondere tak van sport. Dat geldt eens te meer als het om applicaties van verschillende leveranciers gaat. Dus: kan het softwareproduct van leverancier X ‘praten’ met dat van leverancier Y? Het spreekt dan ook voor zich dat niet alleen eindgebruikers, maar juist ook de makers van applicaties gebruik maken van API’s of van daarvoor beschikbare protocollen en standaarden.

API-licentie

Voor het gebruik van andermans API is in de regel een licentie nodig. Voor iedereen die zo’n licentie moet schrijven of beoordelen, is het oppassen geblazen. Reden: de IT-wereld gaat verre van eenduidig met API’s om en juist dat noopt tot voorzichtigheid. Soms blijken softwareleveranciers hun API’s aan te bieden als geïntegreerd onderdeel van hun applicatie. Om juridische duidelijkheid te scheppen is het in zo’n geval wel zo verstandig als de API expliciet genoemd of beschreven wordt in de productdefinitie die in de applicatielicentie zit. En ook moet gekeken worden of de vergoeding voor het recht tot gebruik van de API in de totaalprijs van de applicatie is inbegrepen. Voor de IT-jurist: het is zaak te onderzoeken of en in welke zin de benodigde API’s onder de applicatielicentie vallen.

Een andere insteek die ook voorkomt, is die waarbij voor het gebruik van een API een separate API-licentie nodig is. Soms zijn die afzonderlijke licenties gratis, soms moet er een specifieke gebruiksvergoeding worden betaald, die bijvoorbeeld afhankelijk kan zijn van de hoeveelheid gegevens die door de API lopen. In de praktijk zijn er zowel commerciële API-licenties als open source licenties. Wordt de API direct vanuit de Cloud betrokken, dan is het vaak een kwestie van het aanvinken om het gebruik ervan, al dan niet tegen betaling, te activeren.

Een bijzonder punt van aandacht is dat veel API’s volgens een open standaard – een document met publiek vrijgegeven specificaties – zijn gemaakt. Zo kennen we de veelgebruikte en gezaghebbende open standaarden voor de digitale uitwisseling van gegevens tussen zorgaanbieders. Maar, let op! Aan dergelijke API’s kunnen door de maker specifieke softwarelagen zijn toegevoegd, met extra functionaliteit. Bij de beoordeling van de licentie vraagt dat dus extra aandacht voor de positie van de rechten van intellectuele eigendom.

Onderhoud van een API

Bruggen en deuren behoeven onderhoud, zo ook API’s. Bij het onderhouden van een API moet veelal rekening worden gehouden met de latere wijzigingen in de applicaties die met elkaar moeten interacteren. En ook omgekeerd: wordt een API in het kader van onderhoud aangepast, dan moeten applicaties eventueel ook een code-update ondergaan. In een veld met diverse betrokken leveranciers kan dat zeer lastig zijn. API-onderhoud stelt dus extreem hoge eisen aan de ‘governance’ van het onderhoudsproces, met name vanwege het benodigde afstemming tussen de diverse betrokken software-ontwikkelaars. Idealiter regelt een goed IT-contract dat (mede) over API’s gaat, dat afstemmingsproces.

Fair use?

Ik zei al: gewoonlijk heb je voor het gebruik van een API een licentie nodig. Dat is de hoofdregel. Maar we kennen ook uitzonderingen. Daarvan getuig een uitspraak van het Amerikaanse Hooggerechtshof uit 2021 in een spraakmakende rechtszaak tussen Google en Oracle. Daarin oordeelde het hoogste federale gerechtshof dat Google vrijuit ging door een API van Oracle van 11.000 regels softwarecode in een (inmiddels oudere) versie van Android, het besturingssysteem van Google, over te nemen. Die API werd zonder licentie en zonder financiële tegenprestatie door Google gebruikt.

Kwalijk? Nee, aldus de rechters, want vanwege onder meer “the organizing function” van de API was er sprake van “fair use” door Google. Oftewel: het gedrag van Google kon auteursrechtelijk door de beugel. Daarmee kon Oracle kon naar de door haar gevorderde 8.8 miljard dollar fluiten.
De Amerikaanse uitspraak is ‘verplichte kost’ voor iedereen die over de bijzondere juridische status van API’s wenst na te denken. Weliswaar zit het auteursrecht op software in Europa anders in elkaar, maar vriend en vijand van de Amerikaanse uitspraak zijn het er over eens dat de rechterlijke beslissing feitelijk een stevige mondiale impact heeft.

API Softwarerecht

API’s zijn al met al een boeiend onderdeel van het softwarerecht. In een wereld waarin steeds meer applicaties aan elkaar worden geknoopt, is het onderwerp van toenemend juridisch belang. Zowel in de contractpraktijk als in de hoek van IT-geschillen. Is de API voor u juridisch nog een blinde vlek? Of kent u er alle ‘ins & outs’ van? Het is de moeite waard om u er blijvend in te verdiepen.