Tag: Api

About Api

Subscribe Feeds

Overheden verzamelen op grote schaal tweets zonder gebruikers te informeren

Geplaatst op in Privacy, 40 reacties
OpenClipart-Vectors / Pixabay

Overheidsinstanties zoals het ministerie van sociale zaken, de Belastingdienst en de Nederlandse Voedsel- en Warenautoriteit (NVWA) verzamelen op grote schaal tweets over onder andere hun beleid zonder Twittergebruikers hierover te informeren. Dat meldde Security.nl onlangs op gezag van onderzoek door AG Connect en Trouw. Het gaat om sentimentanalyse, data-analyse waarbij bakken met tweets zeg maar als “positief” of “negatief” worden gelabeld zodat je kunt zien hoe je beleid valt bij de mensen. Ook hier heerst dus die misvatting dat dat mag omdat Twitter openbaar is. Kunnen we eens ophouden met “ja maar openbare bron” als argument?

Het idee achter sentimentanalyse is dat je op basis van grote datasets de werkelijkheid kunt meten, en dat dat een stuk goedkoper/makkelijker is dan steeds een enquête eruit doen of 1200 Nederlands bellen. Waar zeker wat in zit, en we hebben ook genoeg tools (zoals van Microsoft) die op basis van statistische tekstanalyse kunnen zeggen of een tweet over een onderwerp gaat en daar dan positief of negatief over is. Dat kun je dan over de tijd meten, groeperen naar locatie van gebruikers (Randstad versus de provincie, bijvoorbeeld), groei of daling signaleren en ga zo maar door.

Punt is natuurlijk wel, dat begint allemaal bij een enorme verzameling berichten van Twitter. En tweets (met Twitternaam) zijn nu eenmaal persoonsgegevens en dus valt het verzamelen en tot sentimenten omturnen van die gegevens onder de AVG. Mag dat? Ja, in principe wel: dit is een vorm van wetenschappelijk en statistisch onderzoek en dat kun je binnen de grondslag van het gerechtvaardigd belang (art. 6 lid 1 sub f AVG) prima rechtvaardigen. (Ook bij overheden, omdat dit niet gaat om uitoefening van een publiekrechtelijke taak.) Toestemming van de twitteraars is dus niet nodig.

Wat wél nodig is, is dat mensen worden geïnformeerd over dit verdere gebruik. Dat staat gewoon in de AVG, en is iets dat altijd moet bij data harvesting. Ik geef toe dat dit bij een klantanalyse wat makkelijker is, daar zet je het in je privacyverklaring of je stuurt een update in het portaal. Bij dit soort gebruik van Twitterdata is er maar één manier en dat is iedereen een tweet sturen (DM’s sturen kan niet altijd). Daar zouden we gek van worden als iedereen dat deed, maar dat is voor een individuele organisatie niet disproportioneel of onmogelijk. (Bij data-verzameling met een drone of sensoren op straat is het natuurlijk een ander verhaal qua complexiteit, dus dan is een bordje of banner genoeg.)

Ik zie in de reacties her en der boosheid met het argument “kom op, Twitter is openbaar en iedereen doet het”. Dat laatste is vast waar, maar verandert niets aan het punt dat de makkelijke toegankelijkheid van de bron géén argument is onder de AVG. Je bent niet vogelvrij omdat men kan scrapen zonder ingewikkelde contracten of toelatingsprocedure. En vanuit juridisch perspectief zou dat ook heel raar zijn, dat het legaal is om iets te doen omdat het heel makkelijk is, en dat alleen bij moeilijk scrapen je mensen zou moeten gaan informeren of zo?

Arnoud

 

Webshop die geen back-ups maakte verliest rechtszaak van softwareleverancier

Geplaatst op in Ondernemingsvrijheid, 9 reacties

Een webshop die geen back-ups van haar boekhoudgegevens maakte, en door een probleem met een softwarekoppeling klantgegevens verloor, heeft de rechtszaak tegen de leverancier van de koppeling verloren. Dat meldde Security.nl vorige week. De koppeling bleek gegevens van crediteuren in het boekhoudprogramma te overschrijven met debiteurenboekingen. Volgens het Gerechtshof staat het vast dat de webshop geen back-ups maakte en heeft de softwareleverancier met recht aangevoerd dat de webshop zelf verantwoordelijk is voor het regelmatig maken van back-ups. “Dat zij dat achterwege heeft gelaten, terwijl het wel mogelijk was, is dan ook een omstandigheid die haar valt toe te rekenen”, aldus het hof.

Het gaat concreet om een koppeling tussen het bekende webshoppakket Magento en Exact Online, waardoor de transacties van de Magento webshop worden doorgestuurd naar de boekhoudsoftware van Exact. Meelezende QA specialisten mogen even wegkijken, voor de rest:

Het boekhoudprogramma maakt gebruik van een tabel van nummering waarbij voor debiteuren en crediteuren dezelfde tabel wordt gebruikt. Beide groepen krijgen om die reden een verschillend startnummer. Voor debiteuren (klanten met een account en gastklanten zonder een account) is in dit geval gekozen voor een nummer beginnend met 3.000 respectievelijk 7.000 en voor crediteuren beginnend met 1-2.999 en vanaf 15.000. De crediteuren moeten handmatig worden ingevoerd, de debiteuren (zowel de bestellingen van klanten met een account als die van gastklanten) worden door de koppeling automatisch in het boekhoudprogramma ingevoerd.
Deze wijze van scheiden van relaties staat onder programmeurs ook wel bekend als een WTF want op deze manier is het natuurlijk mogelijk dat het aantal aankopen zo oploopt dat je de 15.000 aantikt en dat je debiteur dan een crediteur is. En dat gebeurde ook, omdat er een foutje zat in het toekennen van nummers bij klanten die als gast bestellen:
Hallo … De gast accounts beginnen bij 7000. Inmiddels hebben we al meer dan 8000 gast accounts, waardoor je dus uit komt op de nummering van de crediteuren.
Dit hoort natuurlijk niet te gebeuren, en pijnlijk voor de webshop was vervolgens dat men geen backup had van de relevante tabellen zodat het een berg werk was om alle debiteuren en crediteuren weer in ere te herstellen. Is dit nu het soort fout waar je voor aansprakelijk bent vanuit je zorgplicht als ICT-er? Helaas komt het Hof niet aan die vraag toe, maar ze bevestigt wel dat we zoiets best “eigen schuld” kunnen noemen.

Iedereen die met digitale gegevens werkt in de bedrijfsvoering, moet daar gewoon backups van hebben. Want of het nou gaat om ransomware, dikke vingers of een API koppeling die debiteuren moet invoeren maar die soms als crediteur aanmerkt, als je die data kwijt bent dan heb je een enórm probleem.

Juridisch gezien kom je dan uit bij “eigen schuld” (art. 6:101 BW): weliswaar ontslaat dat de leverancier niet van aansprakelijkheid, maar hij hoeft minder van de schade te vergoeden omdat de gevolgen mede aan de webwinkel te wijten zijn.

Het is aannemelijk dat geen handmatig herstel met de gevorderde kosten nodig was geweest als de door [de webwinkel] gestelde tekortkoming achterwege zou zijn gebleven (zo die na bewijslevering zou komen vast te staan). Maar dat geldt ook indien [de webwinkel] zelf de nodige zorgvuldigheid zou hebben betracht door een back-up te maken. De kosten van de advocaat in verband met het verhaal van herstelkosten bij [de leverancier] zouden ook niet gemaakt zijn.

Je kunt je natuurlijk afvragen of de leverancier niet meer had moeten doen. Nee, niet in dit geval:
Het hof betrekt daar ook bij (i) dat het ging om een standaardkoppeling tegen een lage prijs zonder abonnement, (ii) dat de koppeling als zodanig jarenlang goed heeft gefunctioneerd, (iii) dat [de webwinkel] zelf voor Exact Online heeft gekozen, (iv) dat zij zich in de werking en de beperkingen daarvan kennelijk niet voldoende heeft verdiept, (v) dat de koppeling is hersteld en (vi) dat [de webwinkel] niet onderbouwd heeft gesteld dat zij door het tijdelijk kwijtraken van enkele gegevens van crediteuren (andere financiële) problemen heeft ondervonden.
Met name dat laatste geeft voor mij de doorslag: er zijn geen daadwerkelijke problemen, alleen maar rotzooi die opgeruimd moest worden omdat er geen backup was. Heel vervelend, maar dát is dan het gevolg van je eigen schuld.

Ondertussen blijft wel open de vraag of de leverancier beter had moeten programmeren, bijvoorbeeld een check dat het debiteurennummer altijd kleiner dan 15.000 had moeten zijn. Als je een koppeling met Exact verkoopt, en die heeft deze rare constructie in haar database-tabellen, dan moet je zulke dingen wel doen lijkt me. Maar kennelijk komt het weinig voor dat Exact Online-gebruikers meer dan 8000 klanten zonder registratie hebben?

Arnoud

Raad van State: Tweede Kamer hoeft broncode van debat-app niet openbaar te maken

Geplaatst op in Informatiemaatschappij, 1 reacties

De Tweede Kamer hoeft de broncode van de Debat Direct-app definitief niet openbaar te maken, meldde Tweakers donderdag. Dit is de einduitspraak in die zaak van laatst, waarin een IT’er al sinds 2018 probeert toegang te krijgen tot de broncode van de Debat Direct app van het parlement. De Raad van State oordeelt nu dat dit niet kan, omdat de ingezette wetten – de Wob en de Wet hergebruik overheidsinformatie – niet van toepassing zijn op de Tweede Kamer als orgaan. Het artikel bij Tweakers gaf vele reacties, inclusief speculatie waarom de overheid toch zo moeilijk zou doen met het achterhouden van deze informatie. Die nota bene feitelijk al online staat, want het is Javascript.

Mijn gevoel bij de zaak is dat men dacht, een Apple + Android app én een webapp dan kan iedereen erbij. Er is dan geen reden om ook nog de API’s vrij te geven. Misschien kortzichtig/naïef, maar ik zie het praktijkgerichte argument wel dat “iedereen er nu toch naar kan kijken”? De vraag om API’s is marginaal te noemen.

Je houdt dan het principiële punt over, en dat is natuurlijk een zeer geliefde kluif voor juristen. (Wat zegt een advocaat in een contractenzaak als eerste? “Pacta sunt servanda”. En als tweede? “Dit lijkt een eenvoudig geschil, maar het gaat om het principe”. De rechter weet dat het dan een lange dag gaat worden.)

Bij een principieel punt moet natuurlijk je algemene regels aandragen om je zaak te onderbouwen, en dan gaan andere belangen meespelen. Zoals hier, als je zegt “in principe heeft de burger recht op de broncode” dan moet je een wet zoals de Wet hergebruik overheidsinformatie erbij slepen. En dan is er een principieel verweer: de TK valt buiten die wet. Je wilt dan niet als TK het precedent scheppen dat je voor software wél onder die wet valt. Waarom niet? Uit principe niet. Dat werkt twee kanten op.

Vervolgens liet men de advocaten los en die zijn vanuit dat principieel verweer gaan terugvechten. Er is dan niemand die een stap terugdoet, zoals door te zeggen “jongens alles stáát al online” of “weet je wat, hier is een API definitie en onze endpoint staat hier, zullen we de rest van het geld besteden aan wat nuttigs”. Want het ligt onder de rechter, dus blijf je eraf.

Zoals ik wel vaker zeg, geen complot veronderstellen waarin simpele incompetentie of naïviteit genoeg is als verklaring.

Arnoud

Google wint van Oracle, maar de rest van de wereld heeft daar weinig aan

Geplaatst op in Intellectuele rechten, 10 reacties

Google heeft geen inbreuk gemaakt op het copyright van softwarebedrijf Oracle toen het de code uit de programmeertaal Java gebruikte voor zijn mobiele besturingssysteem Android. Dat meldde RTL Nieuws onlangs. De Amerikaanse Supreme Court bepaalde namelijk dat de relevante code een fair use was onder eventuele auteursrechten van Oracle op diens Java-implementatie. Leuk voor Google, maar een uitspraak dat iets fair use is, daar heeft de rest van de wereld weinig aan. De kern van de zaak was namelijk: rust er überhaupt auteursrecht op een API definitie, wat de betreffende regels code uiteindelijk waren.

De zaak Google/Oracle draait om de universele programmeertaal Java, die begin jaren negentig is ontwikkeld door Sun Microsystems. 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. Alleen, de implementatie was verschillend.

Dat mag, zo dachten de meeste juristen destijds. Op een definitie of een naam rust geen auteursrecht. De implementatie wel, maar die was dus niet overgenomen. Desondanks kwam dit voor de Supreme Court en die bepaalde tot veler verrassing dat je op een API wél auteursrecht kunt hebben. Dit zou betekenen dat het interface-conform ontwikkelen van een implementatiekloon juridisch onmogelijk zou zijn, vandaar dat Google er met een truc een nieuwe zaak van maakte.

Die nieuwe zaak ging over fair use: mag je andermans werk gebruiken zonder toestemming als dat eerlijk of redelijk is, even kort gezegd. Dit Amerikaanse begrip is breder dan ons citaatrecht, parodierecht et cetera: weliswaar zijn al die dingen van ons vormen van fair use, maar wij hebben in Europa geen algemeen criterium “jamaar dat is toch doodnormaal, kom nou toch hoezo mag dat niet”. Dat is zowel een voordeel als een nadeel. Een nadeel, want als het niet in de wet staat dan vereist het dus toestemming. Maar ook een voordeel, want je weet nu precies wat wel en niet mag.

In de VS hebben ze dus die open norm, en de Supreme Court oordeelt nu dat Google daaronder dit mocht doen. Google had alleen die regels broncode gekopieerd – die API definities overgeschreven – die ze echt nodig had:

Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. The record demonstrates numerous ways in which reimplementing an interface can further the development of computer programs.
Het probleem is alleen: geldt dit voor íedere 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 zeg de elearning-provider 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 eigen precedenten opzij zetten. Men 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 idéé van een API hergebruikt zonder de letterlijke functienamen en dergelijke te gebruiken, daar laat men zich wijselijk niet over uit.

We kunnen dus nu wel roepen dat Google gewonnen heeft, maar de conclusie die op lange termijn blijft staan is dat vrijwel iedere API auteursrechtelijk beschermd is, met als gevolg dat interoperabiliteit vrijwel onmogelijk wordt. Immers, wil je die herimplementeren dan heb je toestemming nodig tenzij je in een beperkte uitzondering valt.

Dit versterkt de macht van rechthebbenden enorm. En ja, ik maak me daar ook bij Europese bedrijven zorgen over. De meeste innovatieve softwaredienstverleners opereren immers vanuit de VS. De ervaring leert dat hun gedrag (en contractuele voorwaarden) sterk Amerikaans georiënteerd zal zijn, waarbij men niet snel Europeesrechtelijk water bij de wijn zal doen. Daar komt bij dat een concurrent binnen dit juridisch kader geen API-compatibele eigen dienst kan aanbieden, omdat dit op auteursrechtelijke bezwaren zal stuiten in de VS – en de dienst aldaar niet aanbieden is commercieel dan geen optie.

Daar staat natuurlijk tegenover dat zeker de web API’s vaak al onder bepaalde voorwaarden worden aangeboden, zodat de praktijk niet direct zal wijzigen. 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. Dus nee, ik vind deze ‘overwinning’ best zorgelijk.

Arnoud

Gaat het om open source of open API’s bij de overheid?

Geplaatst op in Regulering, 6 reacties

De overheid heeft een moeizame relatie met ict, zo poneert een interessant Tweakers-artikel over openbaarheid bij overheids-ICT-projecten. Al geruime tijd (sinds 2002, Motie-Vendrik) worstelt men met het idee van openheid bij software en data die door de overheid wordt ontwikkeld. Het sterkst is het pleidooi geweest voor het openen (bevrijden) van software. Maar zelf neig ik er steeds meer naar om te zeggen: het gaat om de data en de API’s. Dat ga ik uitleggen.

Het Tweakers-artikel gaat in op een recente rechtszaak om vrije (vrij als in vrijheid) toegang te krijgen tot de broncode van de “Debat Direct”-app, waarmee het mogelijk is om debatten in het parlement live te bekijken of achteraf terug te kijken. Er is alleen geen Linux versie, uitsluitend MacOS en Windows worden ondersteund. In maart bepaalde de rechtbank dat deze app wettelijk niet openbaar hoeft te zijn, onder meer omdat de Wet openbaarheid van bestuur niet geldt voor de Tweede Kamer en de Wet hergebruik overheidsinformatie niet geldt voor apps.

Vervolgens blijkt dat de app gewoon Javascript is, niet eens obfuscated, zodat je je kunt afvragen wat er dan niet openbaar is aan die broncode. En het gevolg is natuurlijk dat alleen een licentie nodig is, want zonder licentie mag je niets met software, hoe openbaar of publiek beschikbaar de broncode ook is.

Vanaf 2021 moet alle nieuwe software van de overheid openbaar zijn, maar dat helpt natuurlijk niet voor al die legacy software die er al is. Of voor al die data en protocollen die er achter zitten. Gelukkig is er het Open Data portaal, waar je alvast een hoop overheidsdata in kunt vinden. Maar nog lang niet alles.

En ja die API’s dus. De Application Programming Interfaces dus, de manier waarop je als applicatie tegen een andere zegt wat ‘ie moet doen of geven. Die zijn de kern van het samenwerken tussen applicaties – en van het kunnen herimplementeren van functionaliteit, zoals bij die Debat Direct app. Als je weet hoe je moet vragen om een lijst van debatten en de livestream van debat 23, dan hoef je die hele app niet meer te hebben. Dat integreer je dan zelf in je dashboard of eigen app.

Wat mij betreft is dat de kern van vrije informatie: dat je overal bij kunt en alles kunt gebruiken waar je bij kunt. Of je dat nou doet met een bijgeleverde app of dat je er zelf eentje maakt, dat hoort niet ter zake te doen. Daarom: het gaat om de data (en de API).

Arnoud

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

Geplaatst op in 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

Geplaatst op in 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?

Geplaatst op in 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?

Geplaatst op in Intellectuele rechten, 9 reacties

twitter-agent-politieEen 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 delen met anderen, wat het weer moeilijk maakt voor écht onderzoek.

Op het eerste gezicht zou je zeggen dat onderzoek op Twitterberichten geen probleem zou zijn. Onderzoek op basis van krantenberichten is al decennia oud en geen probleem. En wat is Twitter nou anders dan een krant, zij het sneller en korter en met megaveel meer berichten?

Nou ja, om er eens eentje te noemen: Twitter is een dienst, en een krant is een product. Kranten kun je dan ook legaal inzien vanuit allerlei plekken, zoals bibliotheken, zonder dat daar allerlei gebruiksvoorwaarden gelden. Natuurlijk is het kopiëren van krantenberichten auteursrechtelijk een probleem, maar onderzoeken welke artikelen in Nederlandse kranten door ghostwriter zijn geschreven, is volgens mij volstrekt legaal.

Bij Twitter ligt dat anders. Twitter is een dienst, en kan daar voorwaarden aan verbinden. Die hebben ze dan ook, maar ik kan er geen specifieke regels over wetenschappelijk onderzoek in vinden. Deze API licentie gaat primair over het kunnen vertonen van tweets in je eigen dienst, eventueel licht gemasseerd om ze passend te krijgen. Het is bijvoorbeeld expliciet verboden de berichten op te slaan, wat onderzoek al bemoeilijkt – helemaal voor het verifieerbaar maken van je onderzoek want je mag de dataset dus niet vrijgeven.

Op zich is dat legaal. Een dienstverlener mag zelf weten wat ze toestaat met de resultaten van haar dienst, er is geen regeling zoals de auteursrechtelijke uitputting die bepaalt dat beschermde producten zoals boeken of kranten vrij bruikbaar zijn voor legale verkrijgers.

In de praktijk lijkt het wel mee te vallen. Ik heb nog nooit gezien dat Twitter een sommatie stuurde naar een researcher, en kan me dat (afgezien van research dat de servers overbelast) ook eigenlijk niet voorstellen. Twitter zou er weinig mee te winnen hebben en veel te verliezen. Maar afhankelijk zijn van een welwillende opstelling van een dienstverlener is natuurlijk wat anders dan iets mógen.

Arnoud

Amerikaanse rechtbank: Gebruik van Java API in Android is fair use

Geplaatst op in Intellectuele rechten, 28 reacties

aapje-api.pngNa twee weken was de jury er snel uit: wat Google deed met de Java API in Android is een “fair use” onder het Amerikaans auteursrecht, derhalve worden geen rechten van Java-eigenaar Oracle geschonden. Dat las ik bij Ars Technica. Google en Oracle liggen al een paar jaar in de clinch over de vraag of (kort gezegd) Google een herimplementatie van Java-functionaliteit mag doen als ze daarbij de API-definities overtypt uit de specificaties van Oracle. Oracle vond van niet en eiste diverse miljarden schadevergoeding.

In 2014 werd nog bepaald dat Android wél inbreuk maakte op de rechten van Oracle. De aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn creatieve keuzes die de resulterende api een auteursrechtelijk beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Althans, in principe. Dit is immers recht: er is altijd een uitzondering mogelijk. Omdat Google ongelijk had gekregen op het punt van de auteursrechten (zij hadden gezegd dat er geen auteursrecht zit op een API) was de rechtbank niet toegekomen aan de vervolgvraag of een wettelijke uitzondering op het auteursrecht zou gelden. Dat moest dus alsnog worden bepaald, en bij deze: fair use.

Fair use is een open norm in het Amerikaans auteursrecht. Alles kan fair zijn als je maar kunt uitleggen waarom. Er zijn dan vier factoren:

  1. Het doel en karakter van het gebruik, inclusief de vraag of het gebruik commercieel is of educatief en non-profit;
  2. De aard van het beschermde werk;
  3. De omvang en de scope van het overgenomen deel in verhouding tot het beschermde werk als geheel; en
  4. Het effect van het gebruik op de potentiële markt voor of waarde van het beschermde werk.

Helaas komt dat in dit vonnis niet heel goed uit de verf. Het was een jury-oordeel en die komen niet verder dan “inderdaad, dit is fair.” De jury-instructies geven mij de indruk dat het vooral zal zijn gegaan om de aard van het werk: als Google een eigen herimplementatie mocht doen van de functies, dan móet ze wel de API overtypen anders is haar werk volslagen onbruikbaar. Maar het is nog even afwachten hoe een en ander in vonnis wordt gegoten. En natuurlijk gaat Oracle in hoger beroep.

In Europa ligt het 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.

… 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.

We hebben nu dus twee systemen: in Amerika zit er auteursrecht op een API máár is hergebruik daarvan fair use, en bij ons zit er geen auteursrecht op een API dus leef je uit, qua hergebruik.

Is Java op Android eigenlijk nog wel belangrijk? Ik zie nooit meer Java-applicaties op dat platform.

Arnoud