Een application programming interface of api lijkt een technisch detail: een mogelijkheid om een applicatie geautomatiseerd aan te roepen, bijvoorbeeld om deze iets te laten uitrekenen of te produceren waar de eigen applicatie dan weer mee verder kan. Wie slim api’s inzet, kan zo een eigen applicatie fors verrijken zonder grote hoeveelheden programmeerwerk te hoeven doen. Juist de api is echter de laatste jaren zwaar onder de juridische schijnwerpers komen te liggen.
Het concept van api’s, koppelingen tussen software, is ontstaan in de Unix-wereld eind jaren zeventig. De centrale filosofie van het platform was do one thing and do it well. Een applicatie kon daarmee klein en overzichtelijk gehouden worden, wat belangrijk was gezien de beperkte capaciteiten van computers in die tijd. De jaren zeventig had in zijn totaliteit immers minder rekenkracht dan één moderne iPhone.
Ontwikkelaars waren daarmee aangewezen op samenwerking, bijvoorbeeld door de uitvoer van een programma dat bestandsnamen kon tonen, te koppelen aan een programma dat teksten kon filteren op bepaalde patronen, en dat dan weer te koppelen aan een programma dat bepaalde bestanden kon weggooien. Programma’s konden elkaar ook aanroepen of commando’s sturen, al waren er vele verschillende technieken om dat te doen.
De vele varianten van Unix die vervolgens ontstonden, waren onderling maar beperkt compatibel. Leveranciers ontwikkelden hun eigen proprietary functies en interfaces om zo een concurrentievoordeel te halen. In de jaren tachtig werd gewerkt aan de Posix-standaard om weer tot uniformiteit te komen, maar een groot succes is het nooit geworden. Het gesloten houden van het eigen systeem bleek een té aantrekkelijk middel om de klant aan zich te binden; dit staat bekend als vendor lock-in.
Voor technologie zijn standaarden essentieel om dingen met elkaar te laten samenwerken. Zeker in de informatietechnologie, waar vrijwel altijd meerdere apparaten of applicaties op elkaar aangesloten worden. Standaarden scheppen nieuwe markten: als bekend is hoe iets moet werken, kan iedereen het bouwen en verkopen. Dat kan al zo simpel zijn als de afspraak hoe een streepjescode eruit moet zien, zodat iedereen deze kan maken en de daarin opgenomen informatie kan lezen. In ict-termen is een standaard vaak een openbare beschrijving van een api, zodanig dat meerdere partijen deze kunnen implementeren of aanroepen.
In de kern is een api een set afspraken over hoe een ict-systeem zal reageren op bepaalde toegestuurde informatie. Dat kan een webbrowser zijn die vraagt om informatie, of een app die een achterliggende databank bepaalde zaken wil laten uitrekenen. Het grote voordeel van api’s is dat er geen kennis nodig is van het achterliggende systeem. Dit systeem is als een black box, een doos met een onbekende werking waarvan alleen de in- en uitvoer begrepen moet worden. Daarmee is het mogelijk om de verschillende onderdelen van een systeem aan te passen zonder dat alle daarmee samenwerkende onderdelen óók moeten worden aangepast. Dit is de enige manier om de enorme complexiteit te beheersen die in deze systemen bestaat.
Ook bij software-as-a-service en clouddiensten is het belang van api’s groot, maar naast deze blackboxbenadering is er nog een andere reden. Wie een api aanbiedt, stelt zijn systeem daarmee ter beschikking aan anderen. Hiermee creëert de beheerder van die api een ecosysteem, een omgeving waarin de hierboven genoemde parasieten kunnen groeien en gedijen. Zij hoeven de beschikbaar gestelde functionaliteiten niet zelf te maken; simpelweg de api aanroepen en het antwoord gebruiken, is genoeg.
De explosieve groei van software-as-a-service en clouddiensten is direct te linken aan de standaardisatie van de web-api, de manier waarop dergelijke diensten api’s aan konden bieden. Een vergelijkbaar effect deed zich voor in de financiële wereld, nadat de PSD2-richtlijn (2015/2366) van banken en andere financiële marktpartijen eiste dat zij open api’s zouden gaan aanbieden. Hiermee konden nieuwe partijen deze markt betreden met nieuwe toepassingen, zoals boekhoudapps gekoppeld aan actuele bankrekeninginformatie. Niet voor niets heeft de Europese Commissie de api als een van de kernpunten van de Digital Decade uitgeroepen.
Tegelijkertijd schept een api wel een afhankelijkheid, want wanneer de api nu wordt ingeperkt of opgeheven, is de functionaliteit daarachter ook ineens ingeperkt of opgeheven. De voorwaarden die de software- of dienstaanbieder verbindt aan een api, zijn daarmee cruciaal. Misbruik van deze voorwaarden kan de markt dan ook fors beïnvloeden als het gaat om een breed gebruikte api.
Het belang van api’s werd voor het eerst goed zichtbaar met de opkomst van Microsoft Windows 95. Hierin had het softwarebedrijf de Win32-api opgenomen, een uitgebreide set functies waarmee applicaties op een standaardmanier functionaliteit uit het besturingssysteem konden aanroepen. Zo konden applicaties eenvoudig bestanden lezen en schrijven, dialoogvensters tonen, statusbalken aanpassen en netwerkdiensten aanroepen. Dit veroorzaakte een ware hausse aan Windows 95-applicaties, wat in grote mate bijdroeg aan het succes van het besturingssysteem.
Concurrent WordPerfect moest echter constateren dat haar applicatie onder Windows 95 niet zo goed werkte als Microsofts Word. Zij vermoedde daarbij onder meer dat Windows 95 speciale, gesloten api’s aan boord had om Microsoft applicaties een oneerlijk voordeel te geven. De zaak die zij daarover aanspande werd in 2012 afgewezen, omdat WP-eigenaar Novell uiteindelijk het causaal verband tussen het gestelde machtsmisbruik en de ondergang van WP niet kon laten zien. WP kende in 1995 namelijk al een zeer beperkt en snel slinkend marktaandeel.
In 2004 oordeelde het Europese Hof van Justitie dat Microsoft misbruik had gemaakt van haar economische machtspositie in de markt voor besturingssystemen door bepaalde api’s geheim te houden voor concurrenten. De api’s betroffen de manier waarop Windows Media Player functies van Windows kon aanroepen, en daardoor beter kon presteren dan concurrerende muziek- en videospelers. Microsoft ontving een recordboete en werd gedwongen volledige api-informatie te verstrekken aan een ieder die daarom vroeg en bereid was een symbolisch bedrag van 10.000 euro te betalen. Opensourceproject Samba maakte hiervan gebruik om de api’s voor het delen van schijven en netwerkprinten te achterhalen en zo haar kloon van Windows SMB actueel te kunnen houden.
Technisch gezien bestaat een api uit twee delen: de functieaanroepen en de functie-implementatie. Dat die laatste als software auteursrechtelijk beschermd is, staat buiten kijf. Maar de waarde van een api ligt primair in de functieaanroepen. Slim gekozen aanroepen kunnen de waarde van een applicatie of webplatform in hoge mate beïnvloeden. En zoals de Microsoft-voorbeelden lieten zien, kan het geheim houden van enkele api’s tot fors concurrentievoordeel leiden.
In de jaren tachtig is veel geprocedeerd, vooral in de VS, over de vraag of auteursrecht op api-functieaanroepen mogelijk is. Een functieaanroep bevat in de kern niet meer dan een aanduiding van de functie en eventuele parameters of invoer die daarvoor nodig zijn. Dit is in auteursrechtelijke begrippen erg mager voor een werk, en bovendien speelt hier de complicatie dat een functieaanroep sterk technisch bepaald is: dit is nu eenmaal de naam van die functie; zo moet deze nu eenmaal worden aangeroepen.
Naar Amerikaans auteursrecht loopt men dan onder meer tegen de merger doctrine aan: het idee of concept van die functie valt samen met de naam, en parameters, van de aanroep, en dan is auteursrecht op die naam onmogelijk. Natuurlijk kan een ander dezelfde functionaliteit onder een andere functieaanroep, met dus een andere naam, aanbieden, maar dat verwoest de interoperabiliteit en daarmee het hele idee van een api. Uiteindelijk is midden jaren negentig een soort van consensus ontstaan dat auteursrecht op een api niet aanvaardbaar is.
Een functieaanroep valt in Europa waarschijnlijk niet onder het auteursrecht.In de Europese Unie lijkt het een uitgemaakte zaak dat er geen auteursrecht op api-functieaanroepen kan bestaan. Artikel 1 lid 2 van de Softwarerichtlijn bepaalt dat 'ideeën en beginselen die aan enig element van een computerprogramma ten grondslag liggen, met inbegrip van de ideeën en beginselen die aan de interfaces daarvan ten grondslag liggen, niet krachtens deze richtlijn auteursrechtelijk [worden] beschermd'. En in het SAS/WPL-arrest oordeelde het Hof van Justitie dat 'noch de programmeertaal en de indeling van gegevensbestanden die in het kader van een computerprogramma worden gebruikt om bepaalde van de functies van dat programma te kunnen benutten' onder het auteursrecht op dat programma kunnen vallen. Het gebruiken van functies van een programma kan maar op één manier, en dat is met functieaanroepen, precies zoals dat met een api gebeurt. Daarmee lijkt het onvoorstelbaar dat een functieaanroep in een api in Europa onder het auteursrecht van de bedenker daarvan zou vallen.
Naast auteursrecht kunnen ook octrooi- en merkenrechten een rol spelen, net als de bescherming als handelsgeheim, maar hun betekenis in de praktijk is minder. Een octrooi zou de achterliggende implementatie beschermen, maar niet de functieaanroepen als zodanig. Deze zijn in octrooirechtelijke zin immers slechts een ‘presentatie van informatie’, de aanduiding of wijze van starten van de functionaliteit.
Toegang tot een verzameling api’s kan onder een merknaam worden aangeboden; het is immers een dienst, of in ieder geval een digitaal product. Daarbij is het zelfs mogelijk de merknaam te verwerken in de api’s zelf, zoals Oracle, of eigenlijk bedenker Sun, heeft gedaan in de Java-api: alle api-f Source: Tweakers.net