Mag ik de hardcoded sleutel van een app gebruiken voor mijn eigen aanroepen?

| AE 11944 | Ondernemingsvrijheid | 36 reacties

Een lezer vroeg me:

Ik wil gebruik maken van een online tool vanuit mijn eigen software. Helaas is een zakelijke licentie op die tool veel te duur. Nu zat ik in de bijbehorende app voor consumentengebruik te kijken, en die blijkt met een hardcoded key te authenticeren. Ik kan daarmee dus perfect een aanroep simuleren, want het http verkeer is ook nog eens onversleuteld. Is dit toegestaan?

Het is in principe de bedoeling dat je aangeboden tools gebruikt zoals ze je aangereikt worden. Dat staat niet letterlijk in de wet maar volgt volgens mij uit wat juristen de redelijkheid en billijkheid noemen. Maar daar staat tegenover dat het dus niet automatisch strafbaar of onrechtmatig is als je iets anders inzet dan de aangeboden tooling.

In het geval van de vraagsteller kun je die app zien als niet meer dan een schil waarmee een server wordt aangeroepen. Ik zie het onrechtmatige niet in het zelf doen van die aanroep. In dit geval wordt er geen account van een ander gebruikt of een achterdeurtje aangeroepen. Alle apps hebben dezelfde sleutel, dus waartegen die sleutel moet beveiligen is me een raadsel.

Ook vraag je op deze manier geen informatie op waar je geen recht op had. Je had exact deze gegevens gekregen als je via de app de informatie op had gevraagd. Van computervredebreuk – ergens binnengaan waar je weet dat je niet mag zijn – kan ik dus niet spreken hier. Wellicht als je de API gaat manipuleren door extra velden te proberen, of counters gaat veranderen buiten de range die de app zelf gebruikt. Dat zou ik dus afraden.

Een complicatie bij deze vraag is dat de aanbieder zakelijke licenties onderscheidt van consumentengebruik met de app. De werkwijze van deze vraagsteller leidt ertoe dat hij onder een consumentenmantel informatie krijgt die hij zakelijk gaat inzetten. Dat zou je kunnen zien als contractbreuk: er staat vast iets in de app-licentie dat de informatie uitsluitend huishoudelijk of privé gebruikt mag worden.

Daar staat voor mij tegenover dat de vraagsteller ook met de app in de hand de informatie had kunnen verkrijgen en dan zakelijk inzetten. Daar doet die app niets tegen. Ik zie de schade niet voor de aanbieder in dat geval, dus waarom zou het dan wél schadelijk zijn als hij dat met een eigen tool doet?

Arnoud

Googles gebruik van de Java API is nu toch weer geen fair use

| AE 10509 | Intellectuele rechten | 13 reacties

Googles gebruik van de Java API packages is geen fair use, las ik bij ITenRecht. Dit is de vierde stap in hoger beroep van de Google/Oracle rechtszaak over auteursrecht op de Java API die al enige jaren loopt. In eerste instantie bleek de API niet beschermd, in hoger beroep wel, toen bleek Googles gebruik een fair use en nu dus weer niet. Waar staan we nu met deze zaak?

De centrale kwestie is of Google de API van de taal Java van een eigen implementatie mag voorzien, om zo Java-compatibel te worden zonder een licentie van Oracle nodig te hebben. Dat kan alleen als op de API zelf geen auteursrecht rust, of als het gebruik van Google onder de Amerikaanse noemer van “fair use” gerechtvaardigd is.

In de eerste serie rechtszaken ging het om de vraag of er of de API auteursrecht rust. Een API is op zich een set creatieve keuzes (welke functie doet wat, hoe heet hij en welke variabelen zijn relevant), maar er zit ook een sterke technische component in. Daarom bepaalde de rechtbank in eerste instantie dat er geen sprake was van (Amerikaans) auteursrecht. In hoger beroep werd dat teruggedraaid, omdat weliswaar de functies zelf technische dingen doen, maar de keuze voor wélke functies en hoe dat te organiseren voldoende creatief te noemen is.

Heb je auteursrecht op een API, dan mogen anderen die dus niet gebruiken zonder een licentie. Echter, in Amerika geldt de algemene uitzondering van “fair use”: alle zeg maar legitieme, normale vormen van gebruik zijn legaal. Daarbij wordt een vierstappentoets langsgelopen waarbij zaken als de hoeveelheid overgenomen werk, de mate van aanpassing/transformatie en de aard van het werk meegewogen worden. Met deze open norm is in principe alles als “fair” aan te merken als je maar hard genoeg je best doet, maar er zit ook het nadeel aan dat je het nooit zeker weet tot de rechtbank er wat van gevonden heeft.

In het vervolg van de zaak beriep Google zich natuurlijk op fair use. Kern van het argument is dat als iemand een API maakt, het de bedoeling is dat mensen moeten weten wat deze kan. Daar een applicatie op schrijven is dan gewoon legitiem, normaal, zeker als je het argument interoperabiliteit meeweegt. Daar staat tegenover, aldus Oracle, dat Google met deze gratis weggegeven herimplementatie de hele markt voor de betaalde Java-licentie ondermijnde en vanwege de gigantische marktmacht van Google zou dat een enorme impact hebben op Oracle.

De rechtbank (en de jury) gaf Google gelijk, maar Oracle ging in hoger beroep. En nu wordt het even complex, want in de VS geldt een strikte scheiding tussen wat juries mogen zeggen en wat het primaat van de rechter is. De jury beslist wat de feiten zijn, de rechter past het recht toe. En bij fair use is dat ingewikkeld, omdat je daarbij feiten juridisch kwalificeert. Het Hof in hoger beroep moet dan ook de feiten en de juridische analyse uit elkaar trekken en vooral op die laatste gaan schieten.

Uiteindelijk weegt dan de vierde factor – het effect op de markt voor het origineel – het sterkste: Googles herimplementatie geeft een grote impact op de betaalde licentiemarkt voor Java (zelfs als je de open implementatie van Oracle zelf erbij betrekt), en daarmee blokkeert men eigenlijk de mogelijkheden voor Oracle compleet om geld te verdienen met haar werk. En iets waarmee de rechthebbende volledig met lege handen komt te staan, kan niet fair use zijn.

In Europa ligt het compleet anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt. Zoals het Hof het formuleerde:

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

Hiermee zou een API dus wél vrij bruikbaar zijn omdat het dan enkel gaat om de functionaliteit die in de API ligt. Het ging in de SAS-zaak om het gebruik van een programmeertaal waarop auteursrecht werd geclaimd. Het schrijven in die taal zou dan inbreuk opleveren, omdat een programma in die taal immers de beschermde functionaliteit aanroept. En dát wijst het Hof van Justitie af. Dit lijkt mij 1-op-1 door te trekken naar API’s van een programma. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

Arnoud

Mag ik de API achter een app zelf aanroepen?

| AE 9484 | Innovatie | 26 reacties

Een lezer vroeg me:

De app van mijn bank is leuk en aardig, maar ik wil eigenlijk bepaalde kerncijfers in mijn thuisdashboard getoond hebben. Technisch kom ik daar wel uit, maar mag ik die API aanroepen voor mezelf? Het is in principe dezelfde informatie heen en weer als de app zou doen, maar ik doe het niet op de officiële manier. Krijg ik dan problemen?

Zuiver juridisch gezien zie ik hier geen probleem mee. Als je gerechtigd bent een API aan te roepen, dan is het niet strafbaar of onrechtmatig om die aan te roepen. Je gaat hier dus niet voor de cel in, en de bank zal ook geen schadeclaim kunnen indienen.

Als je rare trucs gaat toepassen om de API dingen te laten doen die niet de bedoeling zijn, dan kan dat anders liggen. Informatie opvragen waar je eigenlijk niet bijhoort, mag je niet zomaar doen. In theorie is dat computervredebreuk.

Praktisch gezien kun je er wel problemen mee krijgen, in ieder geval één simpele: als de bank jouw aanroepen ziet als misbruik of bedreiging, dan blokkeren ze die. Dat zal al snel betekenen dat je ook via de officiële app niet meer bij je bankgegevens kunt of overboekingen kunt doen, en dat lijkt me erg vervelend voor een consument. Want zonder internetbankieren je bankzaken doen is een hele uitdaging tegenwoordig.

Ik zou dit dus alleen doen als de bank het goedvindt, of als je zeker weet dat de aanroepen niet te onderscheiden zijn van ‘echte’ aanroepen.

Arnoud

Mag je de Twitter API scrapen voor wetenschappelijk onderzoek?

| AE 8877 | Intellectuele rechten | 9 reacties

Een lezer vroeg me: Deze meneer heeft een mooie data-analyse gemaakt van Donald Trump zijn tweets: Trump zelf gebruikt een Android-apparaat en een ghostwriter nuanceert de boel vanaf een iPhone. Daarbij vroeg ik mij af of dit zomaar mocht. Twitter zegt van wel bij onderzoeksdoeleinden (onder bepaalde voorwaarden). Zoals dat je je dataset niet mag… Lees verder

Twitter sluit Amerikaanse Politwoops

| AE 7734 | Uitingsvrijheid | 9 reacties

Microblogdienst Twitter heeft de Amerikaanse site Politwoops afgesloten, las ik bij Sargasso. Op Politwoops zijn tweets van politici te lezen nadat de twitterende politicus deze had weggehaald. Het idee erachter was dat je zo kon zien welke flaters of andere opmerkelijke uitingen politici weg wilden poetsen (“het gaat niet om de typefouten”), maar Twitter beroept… Lees verder

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Intellectuele rechten | 40 reacties

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library… Lees verder

Oracle’s Java API auteursrechtelijk beschermd in VS, Android maakt inbreuk

| AE 6637 | Intellectuele rechten | 21 reacties

Een Amerikaans gerechtshof heeft vrijdag in hoger beroep bepaald dat Google met zijn Android-besturingssysteem het copyright van Oracle heeft geschonden, las ik bij Tweakers. Nadat eerder nog was bepaald dat er geen auteursrecht zat op de API’s van Oracle’s Java, beslist het Hof van Beroep nu anders: de aangeboden code en de structuur, volgorde en… Lees verder