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

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

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

| AE 13396 | 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

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

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

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

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

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

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

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

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

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

Niet noemen open source licentie is auteursrechtinbreuk

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