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 “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

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

| 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

Anno 2020 denken mensen nog steeds dat open source juridisch riskant is

| AE 11972 | Intellectuele rechten | 16 reacties

Via Bert Boerland op Twitter las ik: Bijzonder lachwekkend (tot tranen toe!) stukje over #opensource (#cms-en) en licenses. Microsoft deed dit truukje (“Fear, Uncertainty and Doubt) zo’n 10 jaar geleden nog, maar is op het rechte pad. Lang geleden dat ik zo’n tenenkrommend stuk over proprietary vs OSS stuk las Het gaat om dit artikel… Lees verder

Hoe ethisch verantwoord mag een opensourcelicentie zijn?

| AE 11538 | Ondernemingsvrijheid, Uitingsvrijheid | 23 reacties

Een nieuwe toevoeging aan het opensourcefirmament: de Hippocratische licentie, grofweg de MIT licentie met de toevoeging dat de software niet mag worden ingezet voor doelen die de Universele Verklaring van de Rechten van de Mens schenden. Iets preciezer: die mensen in gevaar brengt of hun well-being aantast op een wijze in strijd met de UVRM…. Lees verder