Tag: Open source

About Open source

Subscribe Feeds

Wacht even, open source is dus niet voor eeuwig gelicentieerd?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 6 reacties
johnhain / Pixabay

In vervolg op mijn blog van maandag over open source bij de overheid kreeg ik vele vragen over het waarom. De TK als opdrachtgever wilde immers eigenaar van alle software worden, zodat ze kon voorkomen dat een licentie zou vervallen en de leverancier dan lekker binnen kon lopen met een nieuw contract. Hoe kan dat, aldus de diverse vraagstellers (dank, allen) als het open source is? Dat is toch voor eeuwig en onherroepelijk gelicentieerd?

De bedoeling van open source is inderdaad dat de software voor altijd onder duidelijk vastgelegde voorwaarden beschikbaar is. Maar letterlijk “voor eeuwig en altijd” (juristen houden van dubbele herhalingen, twee keer genaaid houdt beter)

De BSD licentie bevat bijvoorbeeld helemaal niets over de looptijd of intrekbaarheid, dat is simpelweg een “je gaat je gang maar binnen dit kader” verklaring. Hetzelfde voor de Mozilla Public License, en daar zit veel meer juridisch geweld in. In de Apache 2.0 licentie vind je weer wel “perpetual” bij de licentieverlening. en de GPL (versie 3) noemt de licentie “irrevocable”. Hier staat dan ook meteen het voorbehoud dat verklaart waarom deze term niet standaard genoemd wordt:

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met.
Dit is het instrument voor de handhaving: OSS licenties vervallen zodra je de voorwaarden schendt. (Sommige hebben automatische herstelbepalingen als je de schending opheft.) Daarmee is voortgezet gebruik van de software een inbreuk op auteursrechten, waar een enorm arsenaal aan handhavingsbepalingen uit de kast voor kan worden gehaald. Dus logisch dat OSS licenties niet letterlijk “perpetual and irrevocable” vermelden.

Dat gezegd hebbende, de strekking van die licenties is dat natuurlijk wel. Er staat geen harde termijn, en het is ook niet echt de bedoeling dat er na ${periode} opnieuw een licentie moet worden aanvaard of iets dergelijks. Naar Nederlands recht zouden we van een licentie voor onbepaalde tijd spreken. Die zijn in principe opzegbaar, mits met voldoende opzegtermijn en/of zwaarwegende reden en/of opzegvergoeding (je moet er 2 kiezen, succes George Boole) tenzij de strekking van de licentie anders is. En dat laatste lijkt me hier wel opgaan.

Blijft echter over de gekke randgevallen, en dat is waar juristen voor leven. Het voor de hand liggende randgeval is overlijden of faillissement van de rechthebbende. De auteursrechten komen dan bij een ander terecht, en het is geen uitgemaakte zaak dat de licenties dan meegaan. Voor juristen: de vraag is of een licentie een goederenrechtelijk recht is of slechts een persoonlijk recht, en het lijkt dat laatste te zijn. Je kunt als licentienemer dan alleen een schadeclaim indienen, in juridische termen heb je dan dikke pech met je concurrente vordering op een failliete boedel.

Langs een ander argument kom je bij hetzelfde probleem uit: via het Nebula- en Berzona-arrest is verdedigbaar dat de curator een licentie mag schenden (wanpresteren) wanneer dat in het belang is van de boedel. En daaronder valt dan het te gelde maken van het onderliggende auteursrecht. Hoewel daar de nodige nuances bij te maken zijn, is het zeer zeker niet uitgesloten dat er een route is waarmee een curator hiermee wegkomt. En dat wil je dan natuurlijk voorkomen met je inkoopvoorwaarden.

En ja, dit voelt als schieten met een kanon op een mug: hoe vaak gebéurt het nou dat er OSS uit de markt gaat omdat de rechthebbende/maintainer overlijdt of failliet raakt, waarna hebberige familieleden of bedrijfskopers de hoofdprijs gaan vragen? Je moet allereerst weten dat je overleden tante Agaath uit Nebraska met zo’n project bezig is, vervolgens een familierechtadvocaat met IE-kennis vinden om de rechten te krijgen én ruimte zien voor een businesscase om daar geld te gaan halen bij partijen die de software nu gratis gebruiken, terwijl je niet weet wie dat zijn. Ik zie het niet gebeuren, maar dat heeft nog nooit een inkoopvoorwaardenschrijvende jurist tegengehouden.

Arnoud

Hoezo sluit de Tweede Kamer open source uit bij een aanbesteding?

Geplaatst op in Innovatie, 4 reacties
PeggyMarco / Pixabay

Via Twitter:

Gemiste kans: @2eKamertweets doet een aanbesteding voor #debatdirect waarin open source expliciet wordt uitgesloten (op basis van onjuiste aannames over open source). #opensourcetenzij?
Dit in reactie op stukken in de aanbestedingsprocedure waarin antwoord op vragen van inschrijvers wordt gegeven. Hier wordt “niet akkoord” gezegd bij twee vragen omtrent open source:
“Alle toebehoren zoals source codes, documentatie en intellectueel eigendom worden overgedragen aan de Tweede Kamer.” Is het akkoord dat bij het gebruik van open source software bij de (door)ontwikkeling van Debat Direct geen intellectueel eigendom wordt overgedragen, indien op de betreffende code een open source licentie(s) zonder virale effecten van toepassing is?
Hier wil de leverancier-in-spe dus weten of ze open source mogen verwerken in de applicatie, wat in strijd zou zijn met de aanbestedingseis dat alle eigendomsrechten naar de opdrachtgever (de TK) moeten gaan.
“Het is Opdrachtnemer niet toegestaan om broncodes te (her)gebruiken in de projectuitvoering indien het intellectueel eigendom en vrije gebruik niet volledig overdraagbaar is aan de Tweede Kamer.” Is het akkoord om hieraan toe te voegen: “Het is toegestaan software en code libraries van derden te gebruiken zolang de Tweede Kamer op ieder moment beschikking heeft tot de laatste versie van de betreffende source code en een niet-exclusieve, onbeperkte, wereldwijde licentie, inclusief het recht om te sublicentieren krijgt.”
Dit komt op hetzelfde neer, de leverancier wil graag werk van derden gebruiken maar kan daar natuurlijk niet het eigendom van overdragen. Dat wil de opdrachtgever dus niet. En ja, dat doet raar aan gezien al sinds jaar en dag de mantra is “open source, tenzij”, oftewel kies voor open tenzij je kunt uitleggen waarom dat niet kan.

Mijn vermoeden is dat het hier zuiver gaat om het verkrijgen van de eigendom, en niet perse omdat men open source niet moet. Dat is zo’n punt dat men als eis formuleert vanwege allerlei objectieve redenen, met name dat je dan afscheid kunt nemen van de leverancier en niet jaren later nog een restje eigendomsclaim in je gezicht kunt krijgen. (Het standaardspook daarbij is het faillissement: de curator kan dan de auteursrechten verkopen waarna de nieuwe eigenaar om geld komt vragen. Maar je weet nooit wat er nog op kan duiken in andere krochten van het auteursrecht.)

Het komt door de vraagstelling wel héél onhandig over zo, omdat er specifiek bij de opensourcevragen “niet akkoord” wordt gezegd maar bij een toch vrij essentiële gesloten component wél een uitzondering wordt gemaakt:

Uit het architectuur document blijkt dat het huidige Debat Direct een proprietairy videoplayer gebruikt waarvan de sourcecode niet beschikbaar is en een aparte licentie vereist is. Kan specifiek voor de ‘standaard’ videoplayer overeengekomen worden dat bepaling 21 en 24 van het Programma van eisen niet van toepassing zijn? Akkoord. De videoplayer wordt niet gezien als onderdeel van de sourcecode.
Het gaat dus om Debat Direct, een app en site waarmee je live de Kamerdebatten kunt volgen. Het voelt voor mij vrij essentieel dat daar een videospeler in zit, dus als ik inkoper was dan wilde ik daar toch zeker de eigendom van hebben, als we het hebben over continuïteit en vage claims in de toekomst. Om eens wat te noemen, video-protocollen zitten vol met patenten, door de player buiten “sourcecode” te zetten geldt er dus ook geen vrijwaring vanuit de leverancier. Dat zit me dan toch niet lekker.

Een dag later werd bekend dat een en ander is aangepast: zolang de Tweede Kamer maar onbeperkt en eeuwig kan beschikken over de software, is het goed waar het gaat om werken van derden. De werken van de leverancier zelf moeten wel in eigendom worden overgedragen.

Arnoud

Moet je anno 2022 de broncode van Linux meeleveren?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 10 reacties

Een lezer vroeg me:

Bij de ontwikkelaars van Arch Linux is discussie ontstaan over het mee moeten leveren van de broncode van de GPL software die daar deel van uitmaakt. Vanwege bandbreedte/opslagbeperkingen wil men dit liever niet, maar de GPL lijkt duidelijk te zijn dat het wel moet. Zijn er juridische opties?
Arch Linux is een Linuxdistributie die zich richt op gevorderde Linuxgebruikers die een snel, stabiel, lichtgewicht en minimalistisch systeem willen hebben. (Aldus Wikipedia.) Een bekende feature van Arch is het Pacman package systeem, waarbij je snel voorgecompileerde applicaties kunt downloaden.

Een punt daarbij is dat je Arch Linux en de applicaties vaak alleen in gecompileerde vorm aantreft. Dat is lastig vanuit de GPL, de meestgebruikte open source licentie, die immers eist dat je de broncode erbij doet.

Het is natuurlijk eenvoudig om zo’n package tot de bron(code) te herleiden als je dat graag wil, en vanwege het gemak en de doelgroep zullen weinigen hier een punt van te maken. Maar dat heeft nog nooit een advocaat weerhouden om op een licentie-overtreding te wijzen.

Veel software in de Linux context is GPL versie 2. Deze licentie (uit 1991) is vrij simpel: je doet de broncode erbij, of een brief waarin je zegt dat jij de broncode op verzoek nastuurt. Dat moet je zien in de context van 1991, namelijk dat broncode online vinden en downloaden lastig en tijdrovend is. Een doosje floppies per post was sneller dan een modem (dit was voordat Al Gore het internet uitgevonden had namelijk). Het achterliggende argument dus: je mag de ontvanger het niet moeilijk maken, het is jouw probleem dat deze de broncode (gratis) kan krijgen.

Een contractuele eis wordt door de rechter altijd gelezen in de context van de huidige situatie. Anno 2022 zal voor de meeste mensen (in de Westerse wereld dan) het downloaden van broncode sneller zijn dan een doosje met een USB-stick laten versturen per post. Zeker voor developers, de doelgroep van de broncode-eis. Het lijkt mij dan ook zeer te verwachten dat een rechter mee zal gaan met het argument dat een URL van de broncode hetzelfde is.

GPL versie 3 vermeldt expliciet dat het mogelijk is de broncode ergens anders vandaan te laten komen (artikel 6 sectie d), zelfs als die ergens anders bij een ander onder beheer is. De eis is alleen dat jij (als verspreider van de gecompileerde code) er voor zorgt dat de broncode beschikbaar blijft op de aangegeven plek.

Arnoud

 

Dit is dus niét hoe je reageert als mensen je als gratis leverancier zien met je open source

Geplaatst op in Ondernemingsvrijheid, Security, 44 reacties

Gisteren blogde ik over een OSS developer die de vraag van een gebruiker kreeg “graag binnen 24 uur hoe uw bedrijf is ingericht op het afdekken van risico’s rondom de enorme log4j bug”. Dat is een typische grootzakelijke manier van doen, die verder met de realiteit niets te maken heeft. Kan gebeuren, je stuurt een “haha no sla okthxbye” mailtje of en klaar. In de comments werd ik getipt over ene meneer Marak die anders reageerde: hij saboteerde zijn eigen code, waar vele vele mensen en projecten door gedupeerd werden.

Marak is ontwikkelaar van een uitbreiding op het bekende node.js framework voor Javascript. Zijn module colors zorgt voor mooie stijling van de beheersomgeving. Verder weinig opmerkelijk, alleen bleek dat recent een toevoeging te hebben gekregen die zorgt voor een oneindige lus, waardoor je hele systeem niet meer werkte als je deze module automatisch liet updaten. Wat iedereen en z’n moeder doet, dus dat gaf de nodige ergernis.

Een foutje? Nee, zeker weten niet. Allereerst niet omdat het een losse nieuwe regel was, met ook nog eens “for i = 666; i < infinity” er in, en dat getal heeft natuurlijk een negatieve betekenis. En ten tweede omdat Marak eerder al boos was dat bedrijven zijn code gebruiken zonder hem financieel te steunen. Wat zijn goed recht is, daar niet van, maar dan volautomatisch je code saboteren, dat kun je niet maken.

Of was het dom van al die mensen, hadden ze maar de code moeten controleren en niet automatisch updaten? Dat vind ik te makkelijk. Natuurlijk hoor je niet zomaar willekeurige code van internet te halen en in productie te nemen, maar dit is een project dat al enige tijd bestaat, goed aangeschreven staat en daarom vertrouwd wordt. Dan wek je bepaalde verwachtingen – en dat gaat boven je opensourcelicentie waarin “als het breekt, mag je de stukjes houden” staat als beperking van aansprakelijkheid.

(Voor de juristen: dit lijkt mij zo’n geval  van opzet of grove nalatigheid waarbij je beperking van aansprakelijkheid niet geldt.)

Regelmatig zie ik dan de opvatting “het is mijn code, ik doe wat ik wil en ik heb geen contract met die mensen dus ik ben niets verplicht”. Dat is dus te kort door de bocht. Door op een bepaalde manier te handelen, schep je verwachtingen. Als jij die verwachtingen regelmatig waar maakt, ontstaat een patroon waar mensen op mogen vertrouwen. Dat kun je niet eenzijdig doorbreken, zeker niet op zo’n lompe en schadebrengende manier. Dat noemen we in Nederland gewoon onrechtmatig, dat kun je niet maken.

Arnoud

 

Als je open source als gratis leverancier ziet, dan krijg je dus dit

Geplaatst op in Intellectuele rechten, 25 reacties

Enige ophef op Twitter: OSS-developer Daniel Stenberg kreeg een nogal bars klinkende mail van een gebruiker, die hem als “Maxx Team Partner” aanschreef en graag binnen 24 uur wilde horen hoe zijn bedrijf was ingericht op het afdekken van risico’s rondom de enorme log4j bug van onlangs. “What is the timeline for completing remediation? List the steps, including dates for each.” Eh. Als ik daar leverancier was, zou ik dit niet heel lief vinden. Maar als je enkel iets op internet had gezet?

Het enige logische antwoord is wat Stenberg ook gaf: “I’d be happy to answer all the questions as soon as we have a support contract.” De algemene tip die ik al eerder aanried: OSS drijft op de gedachte van communities. Iedereen helpt elkaar, en daar kan iedereen dus terecht. Maar bedrijven werken met contracten, om zekerheid (althans, de illusie van) te realiseren en om leveranciers bij de nekharen te kunnen grijpen als blijkt dat er iets misging. A throat to choke, extern de schuld neerleggen zeg maar.

Open source licenties zijn natuurlijk contracten, dus als je als bedrijf software van Stenberg installeert (hij maakte onder meer cURL) dan heb je een leveranciersrelatie. Zou je kunnen zeggen als rechtlijnige inkoper. Maar er is dan in het geheel geen sprake van zelfs maar enige inspanningsplicht bij Stenberg, hier is de software en als ‘ie breekt, mag je de stukjes houden. Of zelf aanpassen, zie maar. Dat is de gedachte achter open source: je kunt er zelf mee aan de slag, veel plezier verder.

Ondertussen zijn we denk ik op het punt dat dit geen groot risico meer zou moeten zijn. Veel bedrijven stoppen hun interne pipeline en producten dan ook vol met open source, en ontdekken pas de problemen als er dingen zoals log4j zich voordoen: een kwetsbaarheid in een breed gebruikt stuk software, dat eigenlijk nauwelijks onderhouden wordt omdat die ene aardige man uit Nebraska er niet zo’n zin meer in heeft.

Helaas verbaast het me toch niet dat je zo’n reactie krijgt van een bedrijf dat al jaren gratis die software gebruikt. Het is natuurlijk juridisch complete onzin, je hebt niets te eisen als je geen afspraak over dat onderwerp hebt gemaakt. En zeker waar het gaat om gratis aangeboden software waarbij nadrukkelijk geen enkele verwachting werd gewekt, is dit ook nog eens moreel niet zo netjes. Maar ik snap het wel, dat is nu eenmaal de reflex waar je mee komt als je software van derden gebruikt die lek blijkt te zijn.

Toch zou het goed zijn als organisaties wat vaker op zoek gaan naar mogelijkheden om OSS projecten te sponsoren. Niet perse als dure SLA, maar betalen voor een stuk ontwikkeling voor de toekomst of een preventieve securityscan, het zou geen gek idee zijn. Natuurlijk, daar profiteert de concurrent dan weer van, maar we hebben het hier over software die per definitie geen competitief voordeel geeft, dus of dat nou de ergste reden moet zijn?

Arnoud

GitHub brengt AI-programmer uit die helpt bij het schrijven van code, mag dat van de GPL?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 10 reacties

GitHub heeft een technische preview uitgebracht van Copilot, een AI-gedreven pair programmer die ontwikkelaars helpt bij het schrijven van code. Dat las ik bij Tweakers. Copilot stelt contextgebonden code en functies voor, en helpt acties bij het oplossen van problemen door te leren van de code die iemand schrijft. De AI is getraind op een grote dataset van publieke broncode, en dat zal vast grotendeels open source zijn onder de GPL want dat is nu eenmaal de bulk van de “publieke” software. Maar de GPL vindt daar iets van, van hergebruik.

Copilot kan automatisch opmerkingen omzetten in code, repetitieve code aanvullen en een functie testen tijdens het schrijven. Het systeem leert en verbetert zichzelf. Het klinkt als een hele goede ontwikkeling, maar als je even doordenkt dan besef je dat dit alleen kan door een héle berg broncode door te akkeren en tot een machine learning model om te zetten. Dat zegt men zelf ook:

Trained on billions of lines of public code, GitHub Copilot puts the knowledge you need at your fingertips, saving you time and helping you stay focused.

Er is die merkwaardige gedachte dat als iets “publiek” is, dat je er dan wat mee mag. Misschien moeten we naast “data is niets” nog een juridisch mantra invoeren: “dat het publiek is, is geen argument”. Want het gaat hier om software, en die is zonder twijfel auteursrechtelijk beschermd. En wanneer die “publiek” online staat, dan weet ik vrij zeker dat het om open source gaat. En dan krijg je dus te maken met de licentie. Of niet?

Interessant genoeg zegt men in de FAQ dan:

GitHub Copilot is a code synthesizer, not a search engine: the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set. Here is an in-depth study on the model’s behavior.
Er is natuurlijk een ontzettend groot verschil tussen een lap code copypasten en heel goed kijken naar “billions of lines of code” om jezelf te trainen. Wie zei dat ook weer, kopiëren uit één bron is diefstal en kopiëren uit honderd is inspiratie? Dat lijkt me hier ook van toepassing.

Het komt neer op de algemene vraag of het maken van een machine learning model een kopie is van alle brondocumenten of -data. Als dat zo is, dan krijg je met de licentie te maken en daar zou dan in dit geval de GPL op van toepassing kunnen zijn. Dan zou alle code die Copilot suggereert, onder de GPL vallen, want dan is al die code afgeleid van de GPL code die erin ging. En dan is dus ook elk door Copilot mede geschreven project GPL.

Bewijstechnisch valt daar nog wel wat op aan te merken: de GPL auteur zal moeten bewijzen dat deze suggestie gedaan is op basis van haar code, want zonder kopie geen inbreuk. En dat zal niet meevallen. Maar dat terzijde.

Is een machine learning model inbreuk op de rechten van de brondocumenten? In de VS waarschijnlijk niet. In 2019 oordeelde de Second Ciruit (de hogerberoepsrechter voor New York, Connecticut en Vermont) dat het verwerken van stukjes uit boeken om een boekenzoekalgoritme te trainen géén inbreuk op auteursrechten is. De dataset die daarmee ontstaat, is dus niet onderworpen aan toestemming (of licentie) van de boekenrechthebbenden.

In Europa zijn er geen vergelijkbare zaken. We hebben wel de Infopaq-zaak, waarin werd bepaald dat het overnemen en verspreiden van 11 woorden (een snippet in zoekresultaten) onderworpen kan zijn aan auteursrechten, maar het ging daar om het publiceren van zoekresultaten in een nieuwsbrief. Dat is toch echt wat anders dan een statistisch model maken waarin staat dat codestukje X vaak samengaat met Y, of dat constructie A goed aansluit bij aanhef B. Ik volg dan ook de conclusie van professors Gotzen en Janssens:

Vooral de overwegingen in de arresten Infopaq I, in verband met bepaalde handelingen van ‘data capturing’ die onder het toepassingsgebied van de uitzondering kunnen vallen, verdienen aandacht. Maar de vijf voorwaarden die de uitzondering … oplegt, zijn cumulatief en, mede in het licht van de regel van de strikte interpretatie, zijn we niet geneigd om te concluderen dat alle gebruikshandelingen voor het trainen van AI-systemen die gebruik maken van beschermd materiaal, door deze uitzondering zullen worden afgedekt.
Die vijf voorwaarden zijn als volgt:
  1. deze handeling is tijdelijk;
  2. deze handeling is van voorbijgaande of incidentele aard;
  3. deze handeling vormt een integraal en essentieel onderdeel van een technisch procedé;
  4. dit procedé wordt toegepast met als enig doel de doorgifte in een netwerk tussen derden door een tussenpersoon of een rechtmatig gebruik van een werk of beschermd materiaal mogelijk te maken, en
  5. deze handeling bezit geen zelfstandige economische waarde.
Een machine learning dataset maken is een tijdelijke handeling, die essentieel en integraal nodig is om het neuraal netwerk mee te maken. Dat trainen is niet op zichzelf economisch waardevol (de exploitatie van het resultaat natuurlijk wel, maar dat bedoelt men hier niet). Punt 4 zou je dan naar analogie moeten interpreteren, wat het Hof van Justitie doet in punt 64 van het arrest:
wanneer de levensduur ervan is beperkt tot hetgeen noodzakelijk is voor de goede werking van het betrokken technische procedé, waarbij dit procedé geautomatiseerd moet zijn zodat deze handeling automatisch, zonder menselijke interventie, wordt gewist zodra de functie ervan om dit procedé mogelijk te maken is vervuld.
Oftewel in gewone taal “ik extraheer even de essentiële kenmerken om een statistisch model te maken, daarna gooi ik het weer weg” en dat zou dan mogen.

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

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

Is een contributor license agreement wel gunstig voor een OSS ontwikkelaar?

Geplaatst op in Intellectuele rechten, 19 reacties

Een lezer vroeg me:

Ik wilde een bijdrage doen aan een opensourceproject. De stichting erachter geeft echter aan dat ik daarvoor een contributor license agreement (CLA) moet tekenen. Dit omdat OSS licenties problematisch zijn in Europa vanwege morele rechten? Enig idee hoe dat zit? En welke nadelen haal ik me op de hals?
Een contributor license agreement of CLA is een contract waarbij een persoon die een bijdrage levert aan een OSS project, de beheerder van dat project bepaalde rechten geeft. Op zich is dat niet nodig: de bijdrage zal onder dezelfde licentie zijn als het project zelf, en de beheerder kan de bijdrage dus zo opnemen onder die licentie. Het grote nadeel daarvan is natuurlijk dat je dan mogelijk honderden auteursrechthebbenden in je project hebt.

Voor veel projecten is het een brug te ver om de auteursrechten op te eisen, wat de juridisch beste oplossing zou zijn voor het probleem. En daarom komt men met CLA’s: daar staat namelijk in dat men een onbeperkte licentie krijgt, en/of de mogelijkheid om de OSS licentie naar een andere om te zetten. Als het project dan bijvoorbeeld van BSD naar GPL wil switchen, dan is er toestemming op voorhand van alle bijdragenden.

Er is het theoretisch risico dat een bijdragende zich op hun zogeheten persoonlijkheidsrechten beroept. Dat kan in Europa (artikel 25 Auteurswet, bij ons) en dan kun je met name optreden tegen verminking van je software. Dit ongeacht je licentietekst, want je kunt van dat verzet geen afstand doen. Dan zou je dus zeggen, ook al had ik het open source gemaakt, déze specifieke aanpassing haalt mijn naam als auteur keihard door het slijk, ik ben daar fysiek misselijk van en ik eis dat het stopt.

In de praktijk wordt aangenomen dat dit bij open source eigenlijk niet kan, met name omdat het heel moeilijk voorstelbaar is wat zo’n aanpassing dan zou moeten zijn. (Enkel het werk gebruiken in een verwerpelijke context is niet genoeg, het moet echt om een aantasting van het werk gaan.) Maar goed, als men er anders in zit dan is dit een ingewikkelde discussie. “Iemand op een blog zegt van wel” is meestal geen sterk juridisch argument.

Dit geldt trouwens óók na overdracht auteursrecht (zie lid 1 zin 1 van artikel 25) dus het is geen argument om een CLA in plaats van een OSS licentie te gebruiken.

Voor de bijdragende is er weinig tot geen voordeel voor een CLA. Zelden staat er bijvoorbeeld een betalingsregeling in, of een ander voordeel zoals inspraak of medebeslissingsrecht. Het enige echte voordeel zou zijn dat als je niet tekent, je code niet in het project komt.

Arnoud

 

Niet noemen open source licentie is auteursrechtinbreuk

Geplaatst op in Intellectuele rechten, 6 reacties

Apollo Fintech maakte inbreuk op het auteursrecht van Jelurida door een cryptomunt aan te bieden die is gebaseerd op de ‘Nxt software’, zonder daarbij de licentie van Jelurida (de Jelurida Public License of ‘JPL’) te verstrekken, zo meldde Rechtspraak.nl onlangs (via). Leuk dat dan ‘JPL’ tussen aanhalingstekens moet als kennelijk gekke term, terwijl cryptomunt gewoon ingeburgerd is. Maar dat terzijde: vrij uniek dat er rechtszaken komen over de naleving van open source licenties. Het is hier natuurlijk weer een speciaal geval, een ruzie tussen twee groepen die werken aan dezelfde software.

De Nxt software implementeert blockchains, en de organisatie Jelurida is ooit begonnen met de Nxt software te ontwikkelen. Zij gebruikt daarbij de Jelurida Public License, een zo te lezen van de GPL afgeleide eigen licentie met een paar opmerkelijke bepalingen. Of je de JPL écht open source kan noemen is  daarom de vraag: de licentie eist een betaling in jouw eigen cryptomunt als je met die software een alternatieve blockchain maakt die niet compatibel is met de originele. Dat is niet helemaal hoe we open source normaal bedoelen, namelijk dat alles mag en je nooit hoeft te betalen. Maar dat terzijde.

Een paar jaar later kwam er de club Apollo, die haar eigen cryptomunt aanbiedt. Daarbij dreef zij op de Jelurida software, iets dat in eerste instantie ook erkend werd in de Github, maar ergens in 2019 verdween de licentievermelding en de tekst van de JPL. Onduidelijk is waarom, en in augustus 2020 kwam die vermelding ook weer terug, maar (mogelijk vanwege een breder gevoel van onvrede) toch stapte Jelurida naar de Nederlandse rechter (vanwege de forumkeuze uit de JPL).

De uitspraak heeft toch de nodige pareltjes. Zo was er meteen ruzie over of de ontwikkelaars van de Nxt software hun rechten wel aan Jelurida hadden afgestaan. Die hadden dat wel toegezegd, maar in digitaal getekende tokens en niet in officiële aktes. Dat is wel héél hypermodern (ik weet dat digitale aktes ook kunnen, maar is een token op de blockchain een akte):

Of overdracht onder een pseudoniem, in een Nxt Token, voorzien van een GPG public key en een Nxt account nummer, voldoet aan het dan geldende aktevereiste zal in dat geval ook moeten worden beoordeeld naar buitenlands recht.
Gelukkig voor Jelurida bleken er ook ouderwetse ontwikkelaars te zijn, die keurig een overdrachtscontract getekend hadden. Daarmee had men de ruimte om de claim te doen.

De volgende stap was discussie of Jelurida de licentie wel van de GPL (geldend op versie 0) mocht omzetten naar hun eigen JPL, omdat niet alle developers daarmee ingestemd zouden hebben. De kortgedingrechter veegt dat snel van tafel: te weinig bewijs dat daar rechthebbenden op tegen waren.

En dan de hamvraag: was het auteursrecht geschonden. Apollo had de software grondig herzien:

Niet in geschil is dat Apollo de Nxt Software heeft bewerkt en coderegels heeft toegevoegd bij het ontwikkelen van de Apollo Software. Jelurida heeft een rapport van 19 augustus 2020 van dr. A.K. Seewald overgelegd, waarin de code base van de Nxt public blockchain platform en de Apollo Foundation codebase met elkaar worden vergeleken. Seewald concludeert dat de Apollo Software een significant deel van de Nxt Software code bevat op bestand-, functie- en coderegelniveau. Tussen de 60% en 73% van de functies van de Nxt Software komen voor ten minste 50% overeen met functies van de Apollo Software. Driekwart van die overeenkomende functies is identiek. Van die overeenkomende functies kan 93% van de coderegels worden teruggevoerd op de core developers van de Nxt Software. Apollo stelt echter 400.000 regels aan eigen code te hebben toegevoegd en de code te hebben ge-refactored, met als resultaat dat de Apollo Software een wezenlijk ander product is dat voldoende van de Nxt Software verwijderd is om als zelfstandig werk te kunnen worden aangemerkt.
Dat laatste is geen argument: refactoring is juridisch gezien een vertaling of verfilming. Het betekent dat je het oude werk opnieuw weergeeft in een andere vorm, maar niet dat je alle brokjes creativiteit uit het origineel kwijt bent geraakt. En dat laatste is het enige argument dat je op tafel moet leggen. Iets is pas nieuw als al het oude (oké, al het creatieve oude) eruit verdwenen is.

Inbreuk dus. En in dit geval is dat een hele simpele: alleen al dat je de credit notice naar de originele licentie hebt verwijdert, maakt dat je deze schendt. En daarmee is de licentie automatisch vervallen, zij het dat het probleem natuurlijk wel in 2020 weer hersteld was. De rechtbank bepaalt dan ook (met dwangsom) dat Apollo zich netjes aan de licentie moet blijven houden, en al haar zakelijke klanten moet benaderen om ze de inbreukmakende versie te laten vernietigen. Schadevergoeding is niet aan de orde (het is een kort geding) maar wel moeten ze een kleine 40.000 euro proceskosten betalen.

Arnoud