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

| AE 12600 | Informatiemaatschappij | 1 reactie

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

| AE 12602 | 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?

| AE 12568 | 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?

| 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,… Lees verder

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… Lees verder

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