Mag ik een API reverse engineeren voor mijn eigen app?

| AE 5041 | Intellectuele rechten | 43 reacties

zoeken-harde-schijf.jpgEen lezer vroeg me:

Steeds meer sites en platforms komen tegenwoordig met een eigen mobiele app, maar lang niet altijd zo handig als wel zou kunnen. Nu werken deze apps met op de achtergrond een API (application programming interface) die ik met mijn eigen app ook zou kunnen aanroepen. Maar mag ik hun app reverse engineeren om zo te achterhalen hoe die API van hen in elkaar steekt?

Reverse engineering, oftewel iets uit elkaar pluizen om te zien hoe het werkt, is in het algemeen toegestaan om principes en ideeën te achterhalen. De Auteurswet bevat een verbod op reverse engineering, maar dat gaat eigenlijk over decompileren: het reconstrueren van broncode uit een applicatie. Dat is aan meer regels gebonden. Je mag niet een applicatie decompileren om deze te klonen, maar wél om een compatibele app te maken.

Als je een app decompileert om zo de API te achterhalen, dan stap je in een grijs gebied. Enerzijds doe je dit om een eigen (met het platform) compatibele app te maken, maar anderzijds produceer je wel een soort van kloon van die “officiële” app, en dát mag dus niet. Gelukkig is het meestal genoeg om het dataverkeer te observeren en daaruit af te leiden hoe de API werkt. En dát mag altijd.

Een bijzonder geval ontstaat wanneer de API of het platform gericht is op het ontsluiten van een databank. Als zo’n databank beschermd is door een databankrecht, dan is jouw app mogelijk in strijd met dat recht, want hij biedt dan een middel voor de voorbehouden handeling van

het herhaald en systematisch opvragen of hergebruiken van in kwalitatief of in kwantitatief opzicht niet-substantiële delen van de inhoud van een databank, voorzover dit in strijd is met de normale exploitatie van die databank of ongerechtvaardigde schade toebrengt aan de rechtmatige belangen van de producent van de databank.

Ja, hele mond vol maar het is ook een draak van een wet. Even kijken: je app vraagt herhaald en systematisch data op, check. Per query is de inhoud niet substantieel (niet 90% van de databank), check. (En haal je wél substantieel de hele databank op dan ga je sowieso onderuit onder het databankenrecht.) Is het in strijd met de normale exploitatie of rechtmatige belangen van de producent? Ah, daar zit hem de kneep.

Ik zou zeggen dat wanneer de app hetzelfde soort functionaliteit biedt (maar dan handiger) als de officiële app, er niet snel strijd met normale exploitatie kan ontstaan. Als er een inkomstenstroom zit aan de officiële app (al zijn het maar advertenties) dan wordt het spannend want jouw app omzeilt die dan. En als je met jouw app iets gratis kunt opvragen dat normaal geld kost, dan zie ik ook wel een databankrechtelijk probleem.

Een app die iets heel nieuws doet op basis van een bestaande API, lijkt me in principe niet snel een probleem zolang er geen overlast komt door bv. onevenredig veel opvragingen. Stel je kunt op de Artis-site via een API de voedertijden opvragen, en jij maakt een app over apen (haha, hij zei apie en dat lijkt op API) die onder meer laat zien waar je in Amsterdam apen kunt bewonderen, inclusief de voedertijden van Artis, dan zie ik niet welk belang van Artis hier geschaad zou worden.

Dat zal rechthebbenden er echter niet van weerhouden met juridische dreigbrieven te komen. Of, iets praktischer, de opvragingen vanuit jouw app detecteren en blokkeren. En dat laatste mogen ze, ook als daar eigenlijk geen reden voor is. Het is hun server en willen ze jou niet faciliteren, dan houdt het op.

Arnoud

Deel dit artikel

      • Daar zit nu net de hele crux van URL manipulatie. Als bijvoorbeeld via http://www.example.com/?id=1234 content is op te vragen, dan “weet” je ook dat /?id=1233 (vermoedelijk) content zal opleveren. Dus als ik een App maak die de content gegeven een nummer oplevert, heet dat re-engineering van een API, en als ik dit in de browser zelf intyp, dan heet dit, uitgaande van je vorige stukken, computervredebreuk? Ik zie het verschil niet?

        Edit: een leuk voorbeeld is de “tekst van de dag” van de willibrordvertaling. Met http://www.bijbel.net/lectionarium/?t=xml krijg je de tekst van de dag. Via reverse-engineering zie je dat http://www.bijbel.net/lectionarium/?t=xml&d=2013-01-01 de tekst voor 1 januari oplevert. Is dit nu URL manipulatie of re-engineering? Het argument dat dit intentioneel gedrag is van de webservice, is gezocht, immers, wanneer ik dit bij het eerste voorbeeld doe, dan valt het (volgens vorige stukken) onder computervredebreuk?

      • Het feit dat je weet hoe iets eruit ziet maakt het nog niet minder manipulatief. Je weet inderdaad de samenstelling van de URL, waarbij de parameters ingevuld moeten worden, bijvoorbeeld /maps/area/[areacode]/level/[level]/division/[division], kun je manipuleren naar /maps/area/51/level/3/division/aliens. Maar of het nou URL manipulatie is of niet, je vraagt nog steeds een URL op zonder daarvoor uitgenodigd te zijn. Die URL / API draait op iemand anders server. Ofwel, je loopt iemands tuin binnen. Dat is vergelijkbaar met de speech van de koninging.

        Of dat nou mag of niet of zou moeten mogen, dat laat ik er even buiten. Maar dat het vergelijkbaar is ben ik sterk van overtuigd.

        • In mijn ogen gaat de vergelijking van “de tuin binnenlopen” mank. Een URL is alsof je bij iemand aanbelt en dan vraagt: “Mag ik van jou …”, waarop je een antwoord krijgt. Wanneer ik in het dagelijks leven bij je aanbel en vraag “Mag ik je pin-code?” Dan zou jouw antwoord moeten zijn “Die krijg je niet, daar ben je niet toe gerechtigd”. Met een URL request doet de server in feite hetzelfde: die antwoordt met “401”.

          In het dagelijks leven kun je niet vereisen dat dit soort vragen niet gesteld mogen worden (cq vrijheid van meningsuiting), en staat het vrij al dan niet te antwoorden. Wat maakt dat dit verschillend is met servers die antwoorden?

          • Het verschil zit hem volgens mij in het aan iemand vragen en het aan iets vragen. Als ik aan jou vraag of ik binnen mag, dan mag ik dat. Maar als ik de pincode op je deurslot raad, mag ik dan naar binnen? Als ik de sleutel uit die klomp aan de muur (of onder de mat) pak, mag ik dan naar binnen? Of als ik weet hoe dat slot met een creditcard open te flipperen is, mag ik dan naar binnen?

            Je kunt uit handelen van een automatisch systeem niet afleiden dat de eigenaar dit zo gewild heeft.

              • Hm goed punt. Even nadenken.

                Het verschil is volgens mij dat je bij CookiesOK de boel specifiek opzet om één ding te automatiseren, namelijk het cookies accepteren. Verder kan de site neit zien óf jij CookiesOK gebruikt dan wel handmatig klikt. Daarom mag de site er gerechtvaardigd op vertrouwen dat jij deze handeling hebt gewild.

                Bij URL-manipulatie doe jij iets dat de site-eigenaar niet per se voorzien heeft. Je vraagt iets op dat hij niet actief als URL/sleutel/ingang heeft aangegeven. Dat weet jíj als uitvoerder van de handeling, en bij de site-eigenaar is het onderscheid tussen “normaal” binnenkomen en via manipulatie binnenkomen te zien. Daarom mag je er niet gerechtvaardigd op vertrouwen dat de site-eigenaar deze handeling heeft gewild.

                Dat het kán betekent nog niet dat het mág, want voor mogen is ook willen door de eigenaar vereist. Ik kán over een hekje stappen maar heb daarmee niet automatisch het récht.

            • @Arnoud. Maar dat is dus precies de onderbouwing die ik gebruik om te zeggen dat dit dan ook computervredebreuk is. Je kunt aan de API zelf niet zien of de eigenaar wil dat deze gebruikt wordt. Het reverse engineeren zelf is niet strafbaar of onrechtmatig, maar het feit dat je iets ongevraagd op de server van een ander aanroept dat zou computervredebreuk kunnen zijn.

              Het verschil tussen URL-manipulatie of API call is puur nomenclatuur (en dat rijmt dus is het waar). Draait die API op je eigen server dan is het een ander verhaal. Je hebt dan een eigen app die een eigen implementatie van andermans API aanroept. Een vreemde situatie, want waarom dan niet ook je eigen API? Geen computervredebreuk in ieder geval, maar wel potentiële patent- en auteursrechtperikelen bij de implementatie van de API.

            • De analogie van een URL en slot op een huis komt regelmatig terug op dit forum, maar ik vind dat die heel raar gebruikt wordt: – Een slot is in de eerste plaats bedoeld om toegang te weigeren; – Een URL is juist bedoeld om op een handige manier toegang te verlenen;

              Ik zie de URL dan ook meer als een deur: beide zijn bedoeld om toegang te verlenen. Het gebruik van een deur of URL lijkt me daarom in principe geen enkel probleem.

              Of je deur of URL mag gebruiken hangt van andere omstandigheden af: – Als een deur beveiligd is met een slot of een URL met een password o.i.d. lijkt me dat een zeer sterke aanwijzing dat het niet de bedoeling is die te gebruiken. – As er een bordje bij een deur staat met verboden toegang of er voorwaarden bij een website staan lijkt me dat ook een duidelijke aanwijzing over de bedoeling. – Uit de context kan ook nog duidelijk zijn dat iets niet bedoeld is te gebruiken: als de voordeur van mijn woonhuis geen slot zou hebben of een server met URL’s naar persoonlijke gegevens (tijdelijk) geen beveiliging zou hebben, lijkt me dat in beide gevallen erg dom. Toch is het nog steeds duidelijk dat het voor derden niet de bedoeling is deze te gebruiken. – Een URL lijkt me in eerste instantie (zonder verder info) het meest in de buurt te komen van een cafedeur, winkeldeur of andere publieke voorziening. Als de API van een server via URL’s zonder beveiligingen toegankelijk is, lijkt me dat een sterke aanwijzing dat je die mag gebruiken, zeker als er ook nog webpagina’s of een WSDL o.i.d. bij staat zonder voorwaarden.

          • Kunnen we de discussie over die analogien alsjeblieft niet weer voeren, of anders in dat andere topic voortzetten.

            Het interessantste voor dit topic is of een API reverse engineeren hetzelfde is als URL manipulatie. Of die URL manipulatie vervolgens computervrede breuk is daat hebben we die andere discussie voor. In het geval van een web api is er naar mijn mening inderdaad geen enkel verschil tussen implementeren van een reverse enigineered web api en URL manipulatie. Juridisch gezien kan het toch geen verschil maken of je URLs handmatig of doormiddel van een programma aanpast? Wel zal het zo zijn dat je met handmatig manipuleren vrijer bent als in een programma die een vast algorithme zal gebruiken voor zijn manipulaties. Een mens kan daar op varieren. Maar uiteindelijk doe je wel hetzelfde.

            • Helemaal mee eens, vandaag geen brakke analogieën. De vraag of het computervredebreuk is vind ik echter wel interessant. In mijn ogen is het aanroepen van een URL (op wat voor manier dan ook samengesteld) of wel computervredebreuk of niet (duh, p | !p). Of dat nou door een mens gedaan is om een toespraak op te vragen, of door een computerprogramma als onderdeel van een API call.

              Eventueel kan er geargumenteerd worden dat als er een link is, of een ‘uitnodiging’ in een andere vorm (zoals een WSDL beschrijving van een SOAP API), er geen computervredebreuk is. Dan moet je die link of WSDL zelf natuurlijk wel op een rechtmatige manier verkregen hebben.

  1. Als een API een implementatie is van een gepatenteerde methode dan zal een reverse engineerde API vrijwel zeker ook inbreuk maken op dat patent. Je kan het dan wel reverse engineeren maar mag het niet niet toepassen in een applicatie zonder licentie van de patenthouder.

    • Is het idee van de api niet dat je die aanroept en het werk gedaan word; je krijgt dan het resultaat terug. De gepatenteerde methode zal dan onderdeel zijn van de service. Ik zie dus niet hoe het programma een licentie nodig heeft, als de server al voorzien is van licentie en deze de methode uitvoert.

      Volgens mij ging zelfs Oracle niet zo ver dat ze claimden dat de API patenteerbaar was. Anders hadden ze niet zo hard geprobeerd om de rechtbank te overtuigen dat de API onder het auteursrecht viel en niet puur functioneel is.

      • Hmm, ik dacht dat ik hier al een reactie op gegeven had, maar misschien ben ik vergeten op de blauwe knop te drukken… Maar inderdaad, een API zelf is niet patenteerbaar, want het is geen uitvinding zelf. Een specifieke implementatie kan natuurlijk wel patenten bevatten (nou ja, natuurlijk), en bij het reverse engineeren moet je daar rekening mee houden. Je moet dan met een andere implementatie komen die functioneel hetzelfde is. In dit artikel gaat het echter niet eens over het reverse engineeren van een API implementatie, maar om het aanroepen van die API. Je kunt dit doen door de app gedeeltelijk te reverse engineeren, en als eventuele patenten in de code van de app moet je ook voorkomen. Maar als je niet naar de code van de app kijkt en alleen maar de externe API aanroept dan kom je nooit in de problemen met patenten.

        Oracle kwam met het argument dat de API (of de specificatie van die API) onder auteursrecht viel, maar kwam daar niet mee weg.

  2. Waarom zou je je API geheim houden? Als je de toegang wilt beperken kun je dat vrij eenvoudig oplossen door de boel te versleutelen, en alleen bezitters van de sleutel toegang te verlenen. Dat wil je typisch als je de dienst achter de API wilt verkopen. De applicatie waar je die toegang op de client mee ondersteund is dan zeker niet je corebusiness: sterker, als iemand anders die beter kan maken, dan voegt dat alleen maar waarde toe aan je dienst.

    Het verbaast mij iedere keer weer hoe technologische nitwits proberen via het justitieel systeem een probleem op te lossen dat of niet bestaat, of waarvoor een technische oplossing veel eenvoudiger is. De wet zou in dat zo in elkaar moeten zitten dat ze daar niet in mee gaat. Ik wacht op de uitspraak ga de tijd van een ander maar verspillen, wij rechters hebben al genoeg te doen — helaas zijn veel wetten ook door technologische nitwits (of erger, mensen die zelfs trots zijn op hun technische onkunde) in elkaar gezet, getuige bijvoorbeeld de cookie-wet, en andere absurditeiten die hier af en toe voorbijkomen.

    • (hmm ook mijn reactie van vanmorgen, waarin ook ik betoogde dat zo’n API gebruiken neerkomt op URL-manipulatie, is nergens te vinden)

      Het probleem met zo’n sleutel is dat die sleutel veelal in de app(licatie) wordt opgeslagen, en die wordt meestal gebruikt om de ‘illegale’ toegang mee te doen. Dat probleem is inherent aan het uitleveren van app(licatie)s en was al een issue sinds de eerste CDFoon-cdroms.

      -edit Arnoud: spambox en alles nagezocht, maar geen reactie te vinden Richard, sorry 🙁 –

  3. Het verbaast mij iedere keer weer hoe technologische nitwits proberen via het justitieel systeem een probleem op te lossen dat of niet bestaat, of waarvoor een technische oplossing veel eenvoudiger is.

    Hoewel ik het er voor een deel wel mee eens ben, is het wat kort door de bocht. In jouw optiek zou je dus ook met brute force de sleutel mogen raden. Hoewel we geen analogie meer deden, zou het argument bij een huisinbraak zijn dat het niet strafbaar kan zijn omdat er een beter slot gebruikt had moeten worden.

    • Van mij mag je het proberen. Bij een goede sleutel is brute force niet de slimste optie, en zouden je pogingen eenvoudig gedetecteerd en gepareerd moeten kunnen worden. (Na elke poging verdubbelen we de periode waarna je het opnieuw mag proberen, en waarschijnlijk heb je meer dan 10 tot 100ste pogingen nodig…)

      Helaas zijn inderdaad veel sleutels niet erg sterk, en worden dit soort maatregelen niet genomen. Mogelijk is dit zelfs het gevolg van wetgeving: als het gewoon zou mogen, zouden er grotere “incentives” zijn het geheel beter te beveiligen, en zou het makkelijker zijn zwaktes te rapporteren. Op die manier is zelfs de wetgeving tegen hacken een veiligheidsrisico.

      • Jeroen, voor alles is toch wel een betere technische mogelijkheid (skimmen, kopieerbeveiliging CD/DVD, etc). Je pleit voor het recht van de slimste en ik weet niet of dat nu echt een goede oplossing is. Je moet er meer naar toe dat er een flink stuk eigen schuld is.

        Als ik mijn fiets bij het station neer zet en deze niet op slot doe, zal geen agent mijn aangifte opnemen en kan ik zelfs een boete krijgen voor uitlokking. Als de RvD de toespraak alvast online zet zonder deze af te schermen mogen ze wat mij betreft niet zeuren. Als er via brute force iets mee gedaan wordt, ben je fout bezig en kan je wel gestraft worden.

  4. Gelukkig is het meestal genoeg om het dataverkeer te observeren en daaruit af te leiden hoe de API werkt.

    Hoe zit dat als het duidelijk is dat die API is beveiligd om dat te voorkomen? Ik heb zelf een keer de stoute schoenen aangetrokken omdat een app over HTTPS communiceerde met de server. In de code was dat een kwestie van de ‘s’ weghalen, opnieuw compileren, app terugzetten op de telefoon zodat ik met een packet sniffer het verkeer kon analyseren. Hier zijn ook nog wel andere manieren voor, zoals proxies als Burp, WebScarab en Fiddler.

    Los van de methode om HTTPS te ontmantelen bleek er nog een tweede beveiligingslaag aanwezig: er werd voor elke request een one-way hash berekend over de URL parameters en de huidige tijd, wat veel gelijkenissen toont met deze methode van Amazon. Hoe deze signature wordt opgebouwd ga je zonder decompileren waarschijnlijk nooit achterkomen, ook moet je moet ook nagenoeg dezelfde code gebruiken om tot een werkende implementatie te komen.

    In hoeverre is bovenstaande toegestaan? Sta je sterk tegenover klonen door clean room reverse engineering toe te passen?

    • In de Amerikaanse jurisprudentie zijn er een aantal precedenten waarbij het letterlijk gebruiken van code die essentieel is voor interoperabiliteit geen inbreuk op het auteursrecht is. (Een van de gevallen betrof een ROM voor een spelcomputer waarvan een bepaald blok specifieke code moest bevatten, anders accepteerde de computer de ROM niet.)

      Een clean room methodiek maakt het makkelijker om beschuldigingen van auteursrechtinbreuk te weerleggen; je documenteert wat je gekopieerd hebt. Het helpt je niet tegen klachten over “inbreuk op de gebruiksvoorwaarden” van een dienst of aanklachten vanwege computervredebreuk.

  5. Stel je kunt op de Artis-site via een API de voedertijden opvragen, en jij maakt een app over apen (haha, hij zei apie en dat lijkt op API) die onder meer laat zien waar je in Amsterdam apen kunt bewonderen, inclusief de voedertijden van Artis, dan zie ik niet welk belang van Artis hier geschaad zou worden.

    Dat kunnen echter diverse belangen zijn. Artis kan bijvoorbeeld de API tegen een vergoeding aanbieden aan een site of een app die daarmee geld wil verdienen. Ook kan Artis zelf een website of app hebben die de API gebruikt waarbij deze API gebruikt wordt in hetproces van het benaderen van potientele nieuwe bezoekers. In beide situaties wordt dan dus de API ingezet ten voordele van artis

    In beide situaties is het niet wenselijk als er derde partijen de API gaan gebruiken voor andere doeleinden waar artis geen voordeel uit haalt. Zo kan de API gebrukt worden op een vergelijkingssite waar de aanbieder van de API niet goed uit de vergelijking komt. Ook kunnen de gegevens uit de API niet goed gerepresenteerd worden. (bv op de Artis site kan naar de API resultaten staan dat bij slecht weer de voedertijden kunnen afwijken terwijl dat op een onofficiele implementatie niet zal staan).

    Er zijn dus zeker wel situaties te bedenken waarbij aanbieders van API’s niet gediend zijn met derden die zonder overeenkomst ook die API gaan gebruiken.

    • Laten we niet alleen kijken naar de belangen van de aanbieder, maar ook kijken naar het “algemeen belang”. Als iemand een app (of webservice) maakt die reisinformatie van de verschillende Europese spoorwegen combineert waardoor internationale reizen beter te plannen zijn; mag de NS dan toegang tot haar reisplanner data weigeren omdat dat concurreert met de crappy internationale reissite van de NS?

      Het lijkt me dat het “algemeen belang” juist baat heeft bij vrije toegang tot data, dan kan iedereen deze data op innovatieve en creatieve wijze combineren, hetgeen weer tot nieuwe Apps leidt.

      • Ja natuurlijk mag de NS toegang weigeren. Het algemeen belang wordt ook vast gediend als jij je voordeur ’s nachts open laat staan zodat we je spullen mee kunnen nemen en er daklozen kunnen pitten, maar dat weiger je ook, neem ik aan. (Ah shit, toch weer een crappy analogie)

        Aan de andere kant is het in mijn ogen niet automatisch onrechtmatig als men de API van de NS gebruikt als deze publiek toegankelijk is (al dan niet na reverse engineering). Ze moeten dan op z’n minst kenbaar maken dat het niet de intentie is dat de API publiekelijk toegangelijk is, en hoe beter dat te doen dan een goede beveiliging?

          • Daar zit inderdaad precies de crux. In hoeverre is kennisgeving noodzakelijk voor het publiekelijk zijn van iets? Dat geldt in deze discussie net zo goed als in de discussie over de toespraak. Constitueert het gebruik van een API of een URL bij gebrek aan een link of een specificatie automatisch computervredebreuk? 2 opties, en dit zijn volgens mij de argumenten:

            Ja, want ik heb je niet uitgenodigd om op mijn server code uit te voeren. Door de API / URL aan te roepen begeef je je ongevraagd op mijn computer. -> computervredebreuk.

            Nee, want ik vraag iets aan de server en deze geeft er geenszins blijk van dat ik iets doe wat niet mag. De API / URL is toegankelijk en deze toegang is publiekelijk, want ik ben publiek. -> geen computervredebreuk.

            Daarnaast is de specificatie gepubliceerd middels de app (van de NS) die er gebruik van maakt, en omdat ik kan zien hoe die app werkt weet ik het ook. Verder heeft de NS nooit vermeld dat de API niet publiek beschikbaar is. Nergens Terms of Service of Algemene Voorwaarden gezien waaruit dat blijkt (ervan uitgaande dat er überhaupt AV zijn, en ik deze daadwerkelijk gelezen heb)

          • Als ik het netwerkverkeer tussen een NS-App en het Internet kan observeren, dan kan ik daaruit het bestaan van een API afleiden. Omdat de NS haar App algemeen beschikbaar maakt, moet de API algemeen toegankelijk zijn. De API is wel degelijk publiek beschikbaar, ondanks het feit dat de NS heeft nagelaten dat aan te kondigen of de specificaties beschikbaar te maken.

            • Helemaal eens met de “open” lezing van Matthijs Wensveen 5 februari 2013 @ 13:27 en MathFox 5 februari 2013 @ 13:36 Als de NS dingen technisch gezien vrij toegankelijk maakt (dmv URLs), is het hun verantwoordelijkheid om – als ze dat nodig vinden – expliciet aan te geven dat de API niet vrij toegankelijk te gebruiken is. Wat mij betreft geeft dat eigenlijk ook een antwoord op de eerdere vraag of het publiceren van een URL verkeerd kan zijn…

  6. Vervolgvraag (waarvan ik het antwoord wel vermoed): “Of, iets praktischer, de opvragingen vanuit jouw app detecteren en blokkeren.” Is het toegestaan, om de communicatie met de server dusdanig te laten verlopen, dat detectie van jouw specifieke app onmogelijk is, bijvoorbeeld door het te anonimiseren, of het voor te doen als een ‘native’ communicatie van een wel toegestane client?

    • Mijn reactie is: “Als het voor interoperabiliteit nodig is om je voor te doen als ‘native’ client, dan is dat toegestaan.” (Ik neem aan dat je met native client de door de API-aanbieder geleverde App bedoelt.) (Ik ben het uitdrukkelijk niet eens met Matthijs: Je authenticeert met een sleutel die je van de API-aanbieder gekregen hebt; je laat alleen je zoontje de deur openmaken omdat jij je handen vol hebt met boodschappen.)

      • Grappig, want ik was aan het twijfelen of ik jouw eerdere interoperabiliteitsargument ging quoten in mijn reactie. Die vind ik namelijk wel zeer sterk. In Amerika (in ieder geval) is interoperabiliteit een speciale uitzondering op de auteursrechtenwetgeving.

        Ik ben echter ook van mening dat een (web)service moet mogen discrimineren in wie ze antwoord geven. Je stopt immers tijd en geld in het ontwikkelen van de service die je terugverdient met het verkopen van je app.

        Daarnaast is het bij breken van authenticatiemechanismen wel een beetje te gemakkelijk om dan “interoperabiliteit!” te roepen. Dat maakt alle vormen van hacken legaal onder het mom van interoperabiliteit. “Die creditcardgegevens waren publiek toegankelijk, ik moest alleen een RSA key verschaffen om binnen te komen, maar uit het oogpunt van interoperabiliteit, wink wink nudge nudge”. In dat standpunt kan ik me zelfs nog wel vinden (ik wel), het is een constante wapenwedloop. Black hat hackers zullen het ook niet laten om het te proberen, dus je moet je zaakjes op orde hebben. Maar het is wel een beetje een extreem standpunt waar weinig (lees: geen) rechters tegenwoordig in mee zullen gaan.

        • Ik ben het met je eens dat een webservice mag (proberen te) discrimineren tussen cliënten. Helaas is dat een race die de webservice gedoemd is te verliezen, want banners kunnen gespoofd worden, wachtwoorden onderschept, geheime sleutels en versleutelingsalgoritmen ge-reverse-engineerd. Er is een belangrijk verschil tussen het creditcard voorbeeld dat je geeft en de sleutels of wachtwoorden in een App-API. De sleutels die je voor de API nodig hebt, heb je rechtmatig verkregen met je App en de auteurswet staat toe dat je ze uit de App reverse-engineered om een ander werkend programma te maken dat met de API samenwerkt. (Let wel op een eventuele EULA bij de App.)

  7. Als de vraagsteller wil ik nog een ander perspectief toevoegen, vooral op het punt “maar wat als je die API gebruikt om Artis in een slecht daglicht te stellen” en “ja maar je gebruikt resources van Artis”: dat zou je ook ook allemaal kunnen doen door de website van Artis te scrapen. Dat is zonder twijfel legaal, maar kost aan beide kanten alleen maar meer resources. Kortom, als je niet wil dat mensen informatie tegen je kunnen gebruiken, publiceer het dan gewoon helemaal niet. In die zin zie ik een API gebruiken als een alternatief voor scrapen, waar iedereen gelukkiger van wordt.

    Op moreel vlak ben ik het sterk eens met Jeroen Hellingman: de wereld zou beter af zijn als meer informatie open zou zijn, op zowel technisch als juridisch vlak. Daarom is er ook een heel actieve open data-beweging in Nederland, om vooral overheidsdata openbaar te krijgen. Artis (of de overheid) richt zich namelijk niet op het produceren van apps, maar het runnen van een dierentuin. Stel dat ik nu de Artis API gebruik om een nog mooiere app voor bij het Artis-bezoek te maken, dan wint iedereen: Artis heeft meer en blijere bezoekers, de bezoekers hebben een betere ervaring, en ik kan een app proberen te verkopen.

    Uiteraard kunnen er ook negatieve dingen met data gedaan worden. Maar, in de ervaring die we tot nu toe hebben met open overheidsdata, zijn die marginaal in vergelijking met de talloze positieve effecten, zowel in Nederland als in landen die al veel langer veel meer data openbaar maken. Kortom, je neemt als data-eigenaar altijd een risico, maar in de praktijk zijn er veel meer voor- dan nadelen.

    Ik zie overigens nog wel een hele praktische reden waarom Artis hun API niet officieel beschikbaar stelt: dat geeft ze ook een verantwoordelijkheid om die te onderhouden. Zelfs als je erbij vermeldt dat er geen garanties zijn, krijg je vast en zeker een hoop gezeur als je de API ineens radicaal aanpast.

  8. Ik heb zo’n modern ding niet, dus misschien ben ik dom, maar is het niet heel raar en inefficiënt dat elke site z’n eigen ‘epp’ (wat? o, app!) nodig heeft? Waarom werken ze niet gewoon met een standaard browser?

    Het lijkt wel de tijd van de bulletin boards, toen moest je voor elke ‘site’ (avant la lettre) op een apart telefoonnummer inbellen met je modempje. Daar waren we toch dankzij internet vanaf? Komt het gewoon weer terug.

    De wet van de remmende voorsprong?

    • No worries, ik ook niet. Apps zijn niet de enige die APIs gebruiken, er zijn heel veel APIs (vroeger heetten die dingen gewoon webservices) die gebruikt worden door andere websites (youtube, flickr, google maps, etc). Maar door het App – API koppel zijn er ineens wel veel meer APIs bijgekomen. De meeste specifiek (al dan niet exclusief) voor de App geschreven. Of dat een stap terug is weet ik niet. Het zijn nog steeds HTTP calls, alleen zonder HTML als communicatiemiddel. HTML is op zich natuurlijk al een API en heeft ook goede middleware features zoals allerlei metadatering (tbv het Semantic Web bijvoorbeeld). Doordat de tegenwoordige APIs elke vorm van standaardisering ontbreken, is iets als een semantic web (web of data) een lastiger doel geworden.

      Beetje off-topic, excuus daarvoor.

  9. Er zijn volgens mij twee, nee, drie dingen aan de hand.

    1. Een API op je telefoon, comp of tablet is een legaal stuk software op een apparaat dat in jouw bezit is. Het aanroepen daarvan door bv een andere applicatie is niet hetzelfde als het aanroepen van een URL, omdat het aanroepen van een URL een server van iemand anders benadert.
    2. Het aanroepen van een URL is niet illegaal of verboden. Ook niet als je daarvoor de parameters van de URL manipuleert. Wat wel verboden is, is het overtreden van de wet door zoals verspreiden van copyrighted materiaal. Zolang je met je URL manipulatie niet over dat soort grenzen gaat, is de aanroep zelf niet verkeerd. Voorbeeld: URL manipulatie geeft jou toegang tot een beschermde foto = verboten URL manipulatie geeft jou toegang tot een setje bustijden die niet onder de databank-bescherming valt = niks aan de hand.
    3. het reverse engineren van een API aanroep is echt iets anders dan het kopiëren van de software of het kopiëren van de API. Met name als je zelf een stuk software schrijft dat qua ontwerp en code nieuw is, maar gebruik maakt van een bestaande API, zie ik geen auteursrechtenprobleem. Voorbeeld: OV9292 wil graag dat je háár app gebruikt. Maar als jij een betere applicatie schrijft, met een eigen (beter) ontwerp, valt die niet onder auteursrechtenbescherming omdat-ie hetzelfde doet. Je kunt niet het concept ‘plannen van een reis’ beschermen, alleen de uitwerking daarvan. En de essentie van de vraag was nu juist: Hoe zit het als mijn uitwerking anders (beter) is dan die van het origineel?

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS