Hoe juristen naar api's kijken

Arnoud Engelfriet over api's en auteursrecht

Touwtrekken aan een interface: de api juridisch bekeken

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.

Doe één ding en doe het goed

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.

De weg naar standaardisatie

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.

PSD2

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.

De Windows-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 eenieder 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.

Hoe wordt een api in het recht gezien?

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.

Auteursrecht op een api

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.

Andere IE-rechten

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-functienamen beginnen met de term 'java', haar handelsmerk. Gebruik daarvan in andermans software kan worden gezien als inbreuk; het is immers zonder toestemming. Toch is dit nogal twijfelachtig. In de Benelux noemt bijvoorbeeld artikel 2.23 lid 1 sub c BVIE als toegestaan gebruik 'de verwijzing naar waren of diensten als die van de houder van dat merk, in het bijzonder indien het gebruik van dat merk noodzakelijk is om de bestemming van een waar of dienst aan te duiden'. Als een api-functieaanroep nu eenmaal zo héét, dan moet men dat kunnen zeggen.

Informatie over een gesloten api kan een handelsgeheim zijn.De informatie over een private of gesloten api zou zeer wel als handelsgeheim kwalificeren. Dit is immers informatie die handelswaarde bezit omdat zij niet algemeen bekend is (art. 1 Wet bescherming bedrijfsgeheimen). Toegang tot de api moet dan wel strikt worden gereguleerd, waarbij contractueel geheimhouding moet worden afgesproken. Dit is dan ook een standaard werkwijze bij dit type api’s. Voor een openbare api is dit natuurlijk geen optie.

Een twijfelgeval ontstaat wanneer iemand een api kan achterhalen door de software met de implementatie daarvan te reverse-engineeren. Dit is in beginsel uitgezonderd in de Wbb (artikel 3 lid 1 sub b) en onder de Auteurswet onder strikte voorwaarden toegestaan (artikel 45m).

Mededingingsrecht

Totdat de Google/Oracle-zaak de IE-insteek weer op de kaart zette, werd toegang tot api’s voornamelijk gezien als het probleem van het mededingingsrecht. De kern van de discussie is daarbij of de ontwerper van een api het recht moet hebben concurrenten te dwingen de markt met een geheel andere api te bedienen. Dit staat natuurlijk op gespannen voet met het beginsel van interoperabiliteit, wat duidelijke waarde voor de maatschappij heeft. Zeker waar het gaat om een platform of dienstaanbieder met grote marktmacht, zoals voorheen Microsoft met Windows, of tegenwoordig een Google of Facebook, lijkt het vrij evident dat het selectief inzetten van open en gesloten api’s tot botsing met het mededingingsrecht komt.

Daar staat tegenover dat er vele aanbieders van api’s zijn die zeker niet als grote marktpartij, ‘monopolist’, aan te merken zijn. Deze partijen staan dus in beginsel in hun recht om een api beperkt of selectief aan te bieden. In de praktijk lijkt dit meestal tot weinig problemen te leiden, juist omdat door marktwerking een concurrent dan een effectievere api aanbiedt.

De zaak Google/Oracle draait om de universele programmeertaal Java, die begin jaren negentig is ontwikkeld door Sun Microsystems. Door ontwikkelaars een gestandaardiseerde api te bieden, zouden zij eenvoudig applicaties kunnen maken die op iedere computer kunnen werken. 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. De software zelf was echter niet uit Java gekopieerd, maar geheel zelfstandig door Google gemaakt.

In 2010 startte softwaregigant Oracle, de rechtsverkrijger van Sun wat Java betreft, een rechtszaak tegen Google. Overname van die api’s, of beter gezegd: de namen van de functionaliteiten daarvan, vormde volgens Oracle auteursrechtinbreuk. Oracle vorderde daarin maar liefst acht miljard dollar aan schadevergoeding vanwege gederfde licentiekosten. De claims van Oracle maakten veel los, omdat een uitspraak conform haar eis zou betekenen dat het interfaceconform ontwikkelen van een implementatiekloon juridisch onmogelijk zou zijn. Het langlopende traject, inclusief tweemaal hoger beroep en ook twee trips naar de Supreme Court, maakte dat de zaak langdurig in de belangstelling stond, en staat.

In eerste instantie werden de vorderingen van Oracle afgewezen. De rechtbank oordeelde dat het overnemen van functieaanroepen geen inbreuk op het auteursrecht oplevert zolang de overnemer een eigen implementatie daarvan toevoegt. In hoger beroep oordeelde het Hof van Beroep echter dat de api van Java moest worden gezien als een door Sun bedachte taxonomie die naar Amerikaans recht auteursrechtelijk te beschermen valt. Een api was daarmee dus auteursrechtelijk beschermd. Google trachtte vervolgens om de zaak in behandeling te laten nemen door het Supreme Court, maar dit verzoek werd afgewezen.

Fair use

In de vervolgprocedure stond de vraag centraal of het gebruik van een api uitgezonderd was van auteursrecht omdat dit als fair use zou kunnen worden aangemerkt. De rechtbank in eerste aanleg oordeelde dat dit het geval was. In hoger beroep werd dit echter ongedaan gemaakt. Het Hof van Beroep oordeelde dat niet was aangetoond dat aan de vier fairusecriteria was voldaan. Daarop stapte Google (weer) naar de Supreme Court. De belangstelling voor de zaak was ondertussen zo gegroeid dat tientallen amici curiae hun kijk op de zaak aandroegen.

De reden voor deze belangstelling voor een op zich achterhaalde kwestie – de api’s zitten al lang niet meer in Android en Java heeft fors aan relevantie ingeboet – is fundamenteel: zou het oordeel van het Hof van Beroep in stand blijven, dan zou het inmiddels wijdverbreide gebruik van api’s van andermans software toestemming vereisen van de auteursrechthebbende.

Google mocht beroep doen op het fairusegebruik van een api.De Supreme Court oordeelde dat Google inderdaad een beroep op fair use mocht doen. Google had alleen die regels broncode gekopieerd, die api-definities overgeschreven, die ze echt nodig had om haar eigen herimplementatie van de Java-api te maken. Het probleem is alleen: geldt dit voor iedere 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 bijvoorbeeld de e-learningprovider 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 precedenten opzij zetten. Het Hof 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 idee van een api hergebruikt zonder de letterlijke functienamen en dergelijke te gebruiken, daar laat het Hof zich wijselijk niet over uit.

Wat is nu de impact voor de praktijk? Immers, zeker web-api’s worden vaak al onder bepaalde voorwaarden aangeboden, dus daar mag je nu toch al niet doen wat die verbieden. 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. En dat is best een extra stukje macht dat je als maatschappij wellicht niet had willen geven.

Reacties (33)

[Firefly III]

Hiermee konden nieuwe partijen deze markt betreden met nieuwe toepassingen, zoals boekhoudapps gekoppeld aan actuele bankrekeninginformatie.

Het nadeel van de PSD2 werd ook direct duidelijk. "Nieuwe partijen", dat moet een door de lokale toezichthouder (in ons geval De Nederlandse Bank) goedgekeurde partij zijn: eentje met een vergunning. Om dat te bewijzen moet je een PSD2-compatible digitaal certificaat aanschaffen. En dan moeten banken je ook nog toegang geven. Kosten voor entry in deze markt zijn gigantisch en het is niet voor niets dat er maar weinig derde partijtjes zijn die zich hier aan wagen. Plus, als particulier of als open source software developer is er sowieso geen ruimte in dit API model, dus wie hier wat aan heeft is mij nog een raadsel.

Daarnaast is dit voor banken geen fijn businessmodel: ze moeten al hun diensten via een API aanbieden en worden dus gereduceerd tot een soort accountancy-dienst/geld-database. Diensten aanbieden is minder voordelig omdat prijsvergelijkende apps de bank totaal op de achtergrond zet. Je kan een app maken die zegt "MyApp lening!" en op de achtergrond shoppen (ook in de EU!) tot je de goedkoopste lening vindt. Daarvan kan je wel zeggen van "ja maar dit bevordert concurrentie en is GoED vOoR dE MaRKtWErkINg" maar het gaat er op uitdraaien dat banken hun producten ondoorzichtiger en moeilijker vergelijkbaar gaan maken, en dat partijtjes die dit gaan proberen uit te rollen op alle mogelijke manieren getraineerd gaan worden, niet in de laatste plaats door de DNB zelf.

Ook de API's die onder de PSD2 beschikbaar worden gemaakt zijn in geen enkele mate gestandaardiseerd of compatible gemaakt volgens enige standaard. Er zijn genoeg standaarden uiteraard voor het uitwisselen van financiële data, maar elke bank heeft zijn eigen JSON format bedacht en pleurt zijn data daar zo godsonmogelijk inconsistent in. Ja het is allemaal JSON, maar elke bank heeft zijn eigen parsing engine nodig. Oh, en banken zijn niet verplicht om changes aan te kondigen en waarom zouden ze? De verplichte API's kosten ze alleen maar geld. Dus het kost vreselijk veel tijd geld en moeite om een boekhoudapp te maken: met alle banken in Europa kan je vier scrumteams bezig houden met het bijhouden van alle bank-api's: de meeste ook nog via trial and error op basis van de foutmeldingen die je klanten krijgen (want een sandboxomgeving is niet verplicht).

[Blokker_1999]

Ik ben net heel blij dat PSD2 strenge eisen stelt aan wie er gebruik kan maken van die APIs. Ja, je kan wel zeggen dat het voor vele developers moeilijk is om aan te voldoen en voor FOSS en private personen zelfs onmogelijk, maar als ik zie hoe vele mensen omgaan met hun computer, overal maar gewoon op OK klikken zou het volgens mij een enorme ramp zijn geworden had men dit niet gedaan. We zien vandaag al met de cookie wetgeving hoe bedrijven mensen toch altijd maar weer duwen in de richting van alle cookies te aanvaarden. Moet je eens kijken wat vele bedrijven zouden doen als ze ineens toegang konden krijgen tot je financiele data.

Het is ook niet alsof je APIs zoals de PSD2 nodig hebt om producten van banken te gaan vergelijken. Er zijn al decennia bedrijven die proberen zich overal als tussenpersoon tussen te zetten om jouw als consument te helpen het goedkoopste product te vinden. Of het nu om een lening, verzekering of energiecontract gaat, aanbieders genoeg, en sommige bestonden zelfs al van voordat een smartphone bestond of het internet populair was.

Dat de basis van de API niet gestandariseerd is, is ergens spijtig, maar aan de andere kant ook te begrijpen. Je kan niet aan de ene kant gaan eisen dat de API toegang geeft tot alle data, maar aan de andere kant niet alle data gaan opnemen in je API. Want dan heb je weer een probleem. Wetgeving hoort ook niet alles tot in de details uit te werken, de industrie had ook zelf kunnen samenkomen om het probleem van standarisering aan te pakken maar heeft er voor gekozen om dat niet te doen. Daarnaast kosten de APis hen niet alleen geld, als ze slim zijn kunnen ze er zelf ook aan verdienen. Ken al meerdere banken die je nu al toestaan om vanuit hun app ook de rekeningen die je hebt bij andere banken te bekijken, zodat je mogelijks meer tijd doorbrengt in hun eigen app.

[Patriot]

Ik ben net heel blij dat PSD2 strenge eisen stelt aan wie er gebruik kan maken van die APIs. Ja, je kan wel zeggen dat het voor vele developers moeilijk is om aan te voldoen en voor FOSS en private personen zelfs onmogelijk, maar als ik zie hoe vele mensen omgaan met hun computer, overal maar gewoon op OK klikken zou het volgens mij een enorme ramp zijn geworden had men dit niet gedaan. We zien vandaag al met de cookie wetgeving hoe bedrijven mensen toch altijd maar weer duwen in de richting van alle cookies te aanvaarden. Moet je eens kijken wat vele bedrijven zouden doen als ze ineens toegang konden krijgen tot je financiele data.

Dit vind ik grenzen aan FUD. Het is niet alsof het alternatief voor een systeem met een zo sterk gesloten opzet meteen is dat je in feite je bankgegevens op straat gooit als je een website bezoekt en toestemming geeft voor cookies.

[Oon]

Het nut van het gebruik van die koppelingen is ook gewoon erg beperkt voor particulieren, want als je bij bijv. Rabobank of Knab een bankkoppeling hebt werkt die alleen voor je zakelijke rekeningen. Er zullen inmiddels vast banken zijn waar het wel kan als particulier, maar dat is zeker nog niet de standaard.

Wordt tijd dat de DNB verplicht wordt om die licenties gratis aan te bieden (na controle dan wel, je moet wel aan de voorwaarden voldoen) en dat banken verplicht worden om transacties via PSD2 (opt-in) aan te bieden voor alle rekeningen zonder extra kosten. Ik ben nu een paar euro per maand kwijt bij Knab om Snelstart mijn rekening uit te laten lezen, deze mist nog wel eens een transactie, maar ik kan hier zelf ook totaal geen controle op uitvoeren omdat ik zelf geen koppeling op kan zetten met de echte omgeving.

[Blokker_1999]

Vreemd, in Belgie bieden zowat alle banken de mogelijkheid. De PSD2 verplicht banken van hun API open te stellen onder PSD2 als ze deze al in 1 of andere vorm aanbieden, maar verplicht hen niet om een API te bouwen als ze er nog geen hebben.

En waarom zou de DNB een dure controle moeten uitvoeren zonder daarvoor betaald te worden? Dan gaan we met zen allen collectief weer betalen voor iets waar slechts enkelen gebruik van maken. Wil je een dienstverlener zijn in de financiele wereld, dan moet je gewoon zelf instaan voor je licenties.

[Oon]

En waarom zou de DNB een dure controle moeten uitvoeren zonder daarvoor betaald te worden?

Omdat dat hun functie is?

Niet alle taken van een bedrijf hoeven winstgevend te zijn, maar het heeft weinig nut om een standaard als PSD2 te maken als niemand er gebruik van kan maken zonder een enorme drempel

[Blokker_1999]

Het is hun functie om die controle te doen en bedrijven te certificeren, het is niet hun plicht om dat gratis te doen, en dat is misschien maar goed ook. Zoals ik in een andere reactie reeds geschreven heb, zie ik ook de voordelen in van het huidige systeem, al had ik graag ook de mogelijkheid gezien voor een persoonlijk toegangstoken te kunnen aanvragen. Dat is gecompliceerder dan simpelweg een bedrijf toestemming geven en zou daarom misbruik een stuk moeilijker moeten maken, maar wat vandaag niet is, kan in de toekomst nog komen.

En mijn vraag blijft dan ook: waarom zou de DNB, en dus de belastingbetaler, dure controles moeten subsidieren zodat bedrijven nog meer winst kunnen maken? Dan zijn we zelfs geen verliezen meer aan het subsidieren, maar gewoon kosten die bedrijven zouden hebben.

Heb je er trouwens al eens bij stilgestaan wat er allemaal nodig is om PSD2 compliant te zijn? Dat is niet weinig. Zelfs als de controle gratis zou zijn, is het niet gewoon een formuliertje invullen en je bent er. Er is enorm veel documentatie nodig van hoe je als bedrijf gaat omgaan met de data die je gaat opvragen bij de banken. Het aanpassen van je bedrijfsprocessen, het schrijven van alle documentatie ervoor kost ook veel tijd en geld. Moeten we dat dan ook ineens gaan subsidieren?

Op het einde van de dag zijn we hier nog altijd met zeer vertrouwelijke informatie bezig, dan wil je niet dat iedereen zich zomaar even zonder al te veel controle toegang kan verschaffen tot die data.

[Nss]

PSD2 koppelingen werken wel met particuliere rekeningen, ook voor Rabobank en KNAB. Er zijn diverse partijen met PSD2 vergunning waarbij je dat kan testen (bijv. Ponto, voor het Ponto account zelf moet je bedrijfsgegevens invullen, maar je kan gewoon particuliere rekeningen hierin toevoegen).

De door jou gebruikte koppeling (via Snelstart) zal dan een niet-PSD2 koppeling zijn, deze werkt bij zowel Knab als Rabobank inderdaad alleen voor zakelijke rekeningen.

[sir_huxley]

Gebruik anders Nordigen/Gocardless. Zij bieden een API aan die met honderden banken werkt. Het is gratis tot 50 koppelingen. Iets waar je als particulier niet snel tegenaan loopt.

[Nairu777]

Als ontwikkelaar bij een grote speler als het gaat om boekhoudsoftware kan ik je inderdaad zeggen dat banken niet altijd even goed zijn met het op de hoogte brengen van de gebruikers van api's. Toch merk ik wel dat je als grote speler je in een positie bevindt de bank aan te zetten een bepaalde kant op te bewegen. Dit heb ik ervaren als het gaat om functionaliteit als een statuspagina of het aantal calls per minuut. Wel kan ik mij voorstellen dat dit voor kleine partijen niet te doen is.

Het klopt inderdaad dat banken ook geneigd zijn ieder een ander response format aan te nemen. De keuze is in dit geval om zelf alles te mappen of gebruik te maken van een derde partij.

[cariolive23]

Het nadeel van de PSD2 werd ook direct duidelijk. "Nieuwe partijen", dat moet een door de lokale toezichthouder (in ons geval De Nederlandse Bank) goedgekeurde partij zijn: eentje met een vergunning. Om dat te bewijzen moet je een PSD2-compatible digitaal certificaat aanschaffen. En dan moeten banken je ook nog toegang geven. Kosten voor entry in deze markt zijn gigantisch en het is niet voor niets dat er maar weinig derde partijtjes zijn die zich hier aan wagen.

Dus je vindt het een nadeel dat niet iedere cowboy zomaar iets online kan gooien? En waarbij dat "iets" dan ook nog eens een "dienst" kan zijn om de klanten op te lichten...

Wat jij nu beschrijft als nadeel, zou jij zelf als oplossing aandragen om de problemen van het wilde westen op de PSD2 prairie op te lossen! (in het geval deze eisen er niet zouden zijn geweest)

Plus, als particulier of als open source software developer is er sowieso geen ruimte in dit API model, dus wie hier wat aan heeft is mij nog een raadsel.

Ik zie überhaupt geen toegevoegde waarde voor een API daar waar het één gebruiker betreft. En of je dan de licentievorm van de gebruikte code er wil slepen, dat mag je zelf weten, maar heeft geen enkele invloed op de toegevoegde waarde.

Overigens hebben banken de vrijheid om API's beschikbaar te stellen voor hun klanten, maar doen ze zelden: Zeer hoog IT risico omdat zo'n api gewoon 24x7 onder aanval zal liggen.

Daarnaast is dit voor banken geen fijn businessmodel: ze moeten al hun diensten via een API aanbieden en worden dus gereduceerd tot een soort accountancy-dienst/geld-database.

Het is zeker geen fijn business model, maar besef wel even dat PSD2 er juist is om de de vendor lock in bij de banken te breken. Dit hebben ze over zichzelf afgeroepen, en denk daarbij ook even terug aan 2008, de bankencrisis.

Diensten aanbieden is minder voordelig omdat prijsvergelijkende apps de bank totaal op de achtergrond zet.

Dat doe je als bank helemaal zelf, je zet jezelf buitenspel wanneer je niet meespeelt. Nogmaals, PSD2, want die is er ook om innovatie aan te slingeren. Heb je wel eens gelezen hoe extreem inefficient bankprocessen kunnen zijn? Zie de jaarverslagen en dan vooral de kosten die ze maken. Een bank die niet innoveert en niet efficient is, zal zichzelf uitrangeren en tzt ophouden te bestaan. Of wil jij als consument voor die kosten opdraaien?

maar het gaat er op uitdraaien dat banken hun producten ondoorzichtiger en moeilijker vergelijkbaar gaan maken

Daar is al heel lang heel veel over geschreven, die mogelijkheden zijn wettelijk flink beperkt. Onder aan de streep heb je altijd een "je krijgt X en je betaalt Y" bij een product.

en dat partijtjes die dit gaan proberen uit te rollen op alle mogelijke manieren getraineerd gaan worden

Dat gaat dus niet zomaar, zie de regels van PSD2. Ik zie het al wel gebeuren dat een partij dan gewoon een schadevergoeding gaat eisen bij de banken, wat op zich al een business model kan zijn! Je gebruikt de API, bank verandert iets, je eist een oplossing, geen oplossing, schadeclaim. En dat bij zoveel mogelijk banken tegelijk. Het enige wat je als bedrijf nodig hebt, is een programmeur die genoeg api's kan ontsluiten en veel juristen om de banken aan te pakken. Beetje vergelijkbaar met de bedrijven die patenten kopen met als doel om bedrijven aan te klagen die ogenschijnlijk het patent overtreden.

niet in de laatste plaats door de DNB zelf.

Die is daarin geen partij, de DNB (en de anderen in SEPA) zijn er voor de controles.

Ook de API's die onder de PSD2 beschikbaar worden gemaakt zijn in geen enkele mate gestandaardiseerd of compatible gemaakt volgens enige standaard. Er zijn genoeg standaarden uiteraard voor het uitwisselen van financiële data, maar elke bank heeft zijn eigen JSON format bedacht en pleurt zijn data daar zo godsonmogelijk inconsistent in. Ja het is allemaal JSON, maar elke bank heeft zijn eigen parsing engine nodig.

Klopt, en dat is niet ideaal. Toch biedt dan ook voordelen, want je moet er niet aan denken dat ze hadden gekozen voor de gemene deler van alle API's... Dan had je nu vrijwel niets gehad. En met PSD3 gaat dit ook weer veranderen, en mogelijk/hopelijk verbeteren.

En de wetgever is er imho niet om technische standaarden in de wet op te nemen, dat zou iedere flexibiliteit ondermijnen.

Oh, en banken zijn niet verplicht om changes aan te kondigen en waarom zouden ze? De verplichte API's kosten ze alleen maar geld. Dus het kost vreselijk veel tijd geld en moeite om een boekhoudapp te maken: met alle banken in Europa kan je vier scrumteams bezig houden met het bijhouden van alle bank-api's: de meeste ook nog via trial and error op basis van de foutmeldingen die je klanten krijgen (want een sandboxomgeving is niet verplicht).

Dat is allemaal ruk en zou allemaal beter kunnen, helemaal mee eens. Toch zijn er al vele bedrijven succesvol met het gebruik van de PSD2 api's en is het blijkbaar geen onoverkomelijk probleem.

[Chiwn]

Het gelijknamige open source budgettering /home finance project Firefly III, geniaal project trouwens even tussendoor, zou volgens mij wel degelijk van zulke apis kunnen profiteren. Of beter gezegd, ik als gebruiker zou daarvan profiteren. Als ik het goed heb, zou dit het vereenvoudigen exporteren te automatiseren in een gestandaardiseerd formaat, zodat dit soepel werkt voor iedere Europese bank. Zoals @Firefly III in zijn reactie al aangaf, geeft de situatie een andere variant van iedere bank dat niet lekker gestandaardiseerd is

[cariolive23]

Die kunnen gewoon een licentie aanvragen.

Exporteren van data in standaard formaten wordt al zo lang door elke bank ondersteund, daarvoor was PSD2 überhaupt niet nodig. MT940 en de rest van de familie werkt al vele vele jaren. En wat dacht je van EDI? Ook al bijna 100 jaar oud

[Chiwn]

Het is een vrijwillig open source project. Zoals hij aangaf in zn initiële post, dat is dus knetterduur. De standaard MT940 heb ik door verschillende banken verschillend gebruikt zien worden. Dan staat het IBAN van de tegenrekening alsnog in de beschrijving ipv het bestemde veld voor de IBAN tegenrekening. Dit moet je dan alsnog gaan opschonen.

[cariolive23]

Dat de tegenrekening in een ander veld komt te staan dan wat jij verwacht, kan liggen aan de wijze waarop de betaling wordt aangeleverd en hoe deze wordt verwerkt. Dat heeft niks met de standaard output te maken, maar met de input voor het maken van de MT940.

Een bekend voorbeeld in Nederland, is Tikkie. De begunstigde is een tussenrekening, de uiteindelijke begunstigde staat in de omschrijving. Een ander voorbeeld zijn de rekeningkosten, die worden (vaak?) zonder tegenrekening op je afschrift gezet. Toch is er gewoon een tegenrekening want het geld moet ergens heen zijn gegaan. Ongeacht de wijze waarop je hier een digitaal afschrift van maakt, die tegenrekening ga je niet op dit afschrift krijgen.

[Reactie gewijzigd door cariolive23 op 23 juli 2024 09:26]

[lethalbas]

Kanttekening is wel dat er meerdere bedrijven (als voorbeeld gocardless) zijn die de benodigde certificeringen wel hebben, de standaarden van duizenden banken kennen en voor kleinere partijen een doorverbinding met de PSD2 API aanbieden met een gestandaardiseerde datastructuur die bij elk van de ondersteunde banken hetzelfde is. Het zijn weliswaar vaak dure services maar dit laat toch een stukke makkelijkere entry in deze markt open dan als aanbieders van applicaties die gebruik maken van dergelijke bank-data zelf de certificeringen moeten halen.

[Reinstein]

Interessant stuk!

Wat ik me af vraag is hoe zit met met bineare bericht protocollen. Die zijn lang niet altijd gedocumenteerd, of maar deels gedocumenteerd. Je zou zn binear bericht ook als een API call kunnen zien. Als je daar op dezelfde manier op reageert dan doe je een API na.

Valt een protocol ook onder het auteursrecht? Of is dit vergelijkbaar met een API?

[Ludewig]

Dit stuk onderstreept maar weer eens hoe verschrikkelijk de auteursrechtwetgeving is, waarbij juristen ellenlange gevechten voeren of je met een systeem mag praten via een API. Stel je eens voor dat dit ook bij gesprekken tussen mensen zo zou zijn en je vooraf toestemming zou moeten hebben voordat je met iemand mag spreken.

Het is een totaal onzinnige discussie, want als een bedrijf niet wil dat iemand de API gebruikt, of niet wil dat iemand die op een specifieke manier gebruikt, dan kan dat gewoon met een technische aanpassing opgelost worden, namelijke authenticatie (wie ben je) en authorisatie (wat mag je).

PS. Wat mij betreft is de kern van de auteursrechtwetgeving fout omdat het uitgaat van 'niet, tenzij' terwijl het veel beter zou zijn om 'wel, tenzij' te gebruiken. Dat staat mensen toe om veel meer gebruik te maken van wat anderen produceren, tenzij mensen expliciet aangeven dat dit niet mag. Dat past ook veel beter bij de huidige wereld waar het veel makkelijker is geworden om dingen te produceren & delen, en een groot percentage content helemaal niet meer afkomstig is van bedrijven die het gemaakt hebben om er geld mee te verdienen.

[Reactie gewijzigd door Ludewig op 23 juli 2024 09:26]

[J_van_Ekris]

Stel je eens voor dat dit ook bij gesprekken tussen mensen zo zou zijn en je vooraf toestemming zou moeten hebben voordat je met iemand mag spreken.

In een commerciele setting is dat toch ook zo? Als consultant spreek ik pas met mensen als de randvoorwaarden om de dienstverlening (betaling, aansprakelijkheid) vastgelegd zijn. Natuurlijk ga ik in gesprek over het vaststellen of onze diensten een oplossing zijn voor onze potentiele klant zijn probleem en wat dat dan zou kosten, maar ik ga pas echt dingen doen/adviseren als de randvoorwaarden vastliggen. De praktijk is soms chaotischer, maar elke jurist zal je vertellen dat dat een erg onverstandige aanpak is.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 09:26]

[Ludewig]

[...]
maar ik ga pas echt dingen doen/adviseren als de randvoorwaarden vastliggen.

Bij een API is dat dus eenvoudig te doen door er een wachtwoord op te zetten, waarbij mensen alleen toegang krijgen als ze voldoen aan de voorwaarden (zoals een betaling).

Waar de juridische discussie over ging is een situatie die vergelijkbaar is met de situatie waar jij zonder betaling en zonder voorwaarden te stellen doet wat je gevraagd wordt; en vervolgens achteraf naar de rechter stapt om een vergoeding af te dwingen. Wat mij betreft is dat misbruik van de rechtspraak. Die moet niet gebruikt worden om dingen af te dwingen die men net zo goed zonder tussenkomst van de rechter kan regelen, door als consultant geen dingen te doen voordat daarvoor een vergoeding is afgesproken en door een API pas antwoord te laten geven als er betaalt is, oid.

[J_van_Ekris]

Waar de juridische discussie over ging is een situatie die vergelijkbaar is met de situatie waar jij zonder betaling en zonder voorwaarden te stellen doet wat je gevraagd wordt; en vervolgens achteraf naar de rechter stapt om een vergoeding af te dwingen. Wat mij betreft is dat misbruik van de rechtspraak. Die moet niet gebruikt worden om dingen af te dwingen

Als consultant kun je in zo'n situatie roepen "hier is het advies, en dat kost je x euro. Je had kunnen voorzien dat dit geld kost." Ik heb dit bij een notaris aan de hand gehad, en helaas werkt het wel zo (je zou vanuit het oogpunt van klantvriendelijkheid een signaal verwachten, maar dat hoeft dus niet).

Even voor de duidelijkheid: als je als Nederlander je voordeur open laat staan, wordt iedereen nog steeds geacht zich aan de wet te houden en dus niet je huis leeg te halen. Dit geldt ook voor API's. Dus als een API open staat, betekent nog steeds dat je als gebruikende dev even moet checken of hij publiekelijk toegankelijk is.

En je moet je afvragen of dat allemaal zo simpel is. Want dan deel je een wachtwoord uit, en dan gooien mensen dat ergens publiekelijk op een site of zo. Een hoop gezeik en complexiteit omdat sommige mensen niet het fatsoen hebben even te checken onder welke voorwaarden een API gebruikt mag worden.

[jhhest]

Er zijn ook een hoop api die je gratis kan gebruiken tijdens de ontwikkel fase van je app.

[divvid]

Topstukje, ook in het licht van het Reddit API verhaal. Er zitten echter voor bedrijven ook risico’s aan het beperken van API gebruik. Er zouden zomaar alternatieve diensten kunnen ontstaan die jouw API irrelevant maakt en daarmee je hele dienst op een zijspoor schuift.

[Stoney3K]

Of als je een gepubliceerde API hebt, de achterliggende dienst gaan imiteren en aanbieden via diezelfde api. In goed vertrouwen kan dat een mogelijkheid zijn tot concurrentie (ander product via dezelfde interface) maar kwaadwillende personen kunnen daarmee prima gebruikers duperen.

[Aalard99]

Interssant stuk en geeft eigenlijk een hele andere benadering als waar ik met mijn werk ik security mee bezig ben. Vanuit security zijn we meer bezig op het preventie stuk, dus voorkomen dat er misbruik wordt gemaakt van API’s maar dit stuk beschrijft het juridisch stuk waarom dit nodig is.

Een voorbeeld waar ik ook aan zat te denken is dat Twitter zijn API heeft dichtgezet voor externe apps pas geleden. Ben dan wel benieuwd of deze apps wel het recht hadden om in eerste instantie deze informatie op te halen en dat Twitter achteraf dan het recht heeft om dit eenzijdig dicht te zetten?

[The Zep Man]

Ben dan wel benieuwd of deze apps wel het recht hadden om in eerste instantie deze informatie op te halen

Zie de algemene voorwaarden en de voorwaarden specifiek voor het gebruik van de API.

en dat Twitter achteraf dan het recht heeft om dit eenzijdig dicht te zetten?

Dito. Twitter kan natuurlijk eenzijdig diens dienstverlening aanpassen, zeker voor de API wanneer deze gratis werd aangeboden.

[Nairu777]

Wat ik me nog wel afvraag is waarom Microsoft z'n api moest openstellen. Voor mij is het nou nog niet helemaal duidelijk of dit betekent dat wanneer je een api hebt, deze openbaar moet zijn. Mag een bedrijf geen interne api's hebben dan?

[Arnoud Engelfriet]

De kern is dat MS haar marktmacht misbruikte door haar eigen apps een betere api te bieden dan apps van derden. Voor straf moest die interne api daarna open. Als je een machtige positie op de markt hebt, dan moet je eerlijker opereren dan wanneer je 'gewoon' concurrenten van elkaar bent.

[TD-er]

Ik zie de API interface meer als een soort van "taal".
Je hebt dat namelijk nodig om te kunnen communiceren met de code erachter.
De "zinnen" die je daarvoor nodig hebt zijn ook eigenlijk te kort om als copyright gezien te kunnen worden.
Ook vertelt een API niet een "verhaal", dat is wat jij ervan maakt door die API te gebruiken.

In die zin is het vreemd dat er copyright op een API zou kunnen zitten.

[Gutser]

Mooi stuk! Kom er niet helemaal achter wat dit betekent ten opzichte van het reddit verhaal. Het is natuurlijk relevant, maar ik begrijp niet helemaal wie nou waar staat en of er valide punten tegen het nieuwe beleid van reddit te maken zijn. Ik weet dat het stuk daar niet over gaat, maar het vormt indirect natuurlijk wel de aanleiding om nu met zo'n artikel te komen.

"Als een api-functieaanroep nu eenmaal zo héét, dan moet men dat kunnen zeggen."

Nogal off-topic, maar dat deed me sterk denken aan een truuk die ik gebruikte om een discussie over een heikel punt uit te lokken op de internationale school waar ik werkte. Ik wilde de les beginnen en de leerlingen (15/16 jaar) zaten onderling gezellig over muziek te kletsen. Dus om de boel te rekken vroeg er natuurlijk een naar welke muziek ik luisterde. Die kans liet ik niet liggen: ik luister de laatste tijd in de auto veel naar een band uit mijn jeugd, NWA. Wat voor muziek dat is? Gangsta rap. Waar staat NWA voor? Ja, dat is een beetje lastig want dat woord mag ik niet zeggen. En dat vind ik eigenlijk een beetje raar, want als zei zichzelf zo noemen, dan is het toch een beetje gek als ik die naam niet uit mag spreken. Dus ik zal het je vertellen, het staat voor Niggaz With Attitudes...

Daarna hadden we een half uur lang een hele mooie discussie over het 'n-woord' waar ik me verder fijn buiten kon houden behalve dan om te fungeren als gespreksleider. Dit was een super heikel punt punt dus dat gesprek was hard nodig. En gezien het gebrek aan sociale vaardigheden bij veel van mijn collega's moest ik het dan maar doen. Een paar maanden later was er andere leraar die op hoge toon eiste dat degen die 'het woord' in een audio opname voor een project had gebruikt zich zou melden. Daarbij zelf 'het woord' gebruikend. De leerling die het betrof was zelf afro American, de lerares gebruikte het n-woord meerdere keren zelf (als citaat). De leerlingen vielen massaal over haar heen. Escalatie van hier tot Tokio en einde van het liedje is dat zij nooit meer terugkeerde en aan het eind van het jaar met haar partner en kinderen, die ook op de school zaten en werkte, naar een ander land vertrok.

Maar goed, dit alles dus geheel terzijde, hahaha.
Fijn artikel Arnoud!
Ik ga op zoek naar een alternatief voor reddit. Het was naast tweakers het enige waar ik 'op zat'. Geen twitter, geen FB, geen toktok, geen instagram. Maar goed, ik vind vast wel iets nieuws. Ik ga me in elk geval niet dagelijks lopen ergeren aan de officiele reddit app.

[flyer88]

mooi zwaar stuk wow bedankt

[SRI]

Voor een ieder die dan zich afvraagt waar deze persoon naar linkt: een of ander kinderlied genaamd 'apies kijken'.

Zodoende hopende jullie weer 2 seconden bespaart te hebben op jullie nieuwsgierigheid.

[Reactie gewijzigd door SRI op 23 juli 2024 09:26]