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

 

Deel dit artikel

  1. Maar dit is toch bij de meeste package managers al het geval? Als ik debian neem, heb ik ook .deb of .dpkg bestanden die door de package manager worden gedownload, zonder de broncode erbij. Hetzelfde met systemen die RPM gebruiken. beide package managers moet je wat extra handelingen verrichten om de broncode van de packages te downloaden. Dit is voor Arch dus weinig anders. Ik zie het probleem dus helemaal niet.

    • Het probleem waar het hier over gaat is dat de mensen die de repositories verder verspreiden (de mirrors), zodat je je binaries kan downloaden vanaf een regionale server in plaats van de ‘hoofd’ server niet altijd ook de source-packages mee kopieren.

      Dus dan krijg je iets als: binary packages download je van mirror.nederland.archlinux.org, maar de source kun je daar niet vinden, daarvoor moet je bij source.archlinux.org zijn.

      En dan maar hopen dat ze reproducible builds hebben, zodat je ook kan aantonen dat de source die ze meeleveren ook daadwerkelijk de binary geeft die je kan downloaden.

      • In dit geval is het zo dat een mirror niet hercompileert maar de originele bestanden aanlevert (hoewel niet alle mogelijke bestanden). Wegens veiligheidsoverwegingen is het wel de verwachting dat alle packages/bestanden een digital signature hebben. Dit betekend dat je weet dat de bestanden vanuit arch geleverd zijn. Overigens als de mirrors van arch zelf zijn (door hun beheerd worden) maakt het niet uit welk url ze de broncode door uitleveren. Niets in de GPL verplicht waar vandaan de sourcecode beschikbaar moet zijn. Als de mirrors door derden beheerd worden dan zijn die derden er verantwoordelijk voor dat broncode beschikbaar is. Zolang arch dat levert dan kunnen ze die verantwoordelijkheid doorschuiven.

  2. Het staat niet duidelijk in de GPL of het wel of niet mag… Laten we artikel 3 van de GPL eens bekijken:

    3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

    a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

    [….]

    If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.Als de Arch-Linux ontwikkelaars een schriftelijk aanbod voor het downloaden van de broncode van hun master download-site doen, dan kunnen de mirrors dat doorgeven aan hun downloaders; via 3c, 3b en de “download uitzondering” zou het geheel volgens de GPLv2 correct kunnen zijn.

    Dit vereist wel dat je de GPL op een bepaalde manier leest; maar ik denk dat je als distributeur het van een Open Source ontwikkelaar wint omdat onduidelijkheden in de licentie in het nadeel van de auteursrechthebbende uitgelegd worden.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS