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

 

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

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 van geslotensourcecmsmaker Plate (“Meer met multisites”). In de wereld van contentmanagementsystemen is opensource al lang ingeburgerd dacht ik altijd, met Joomla, WordPress en Drupal als bekendste voorbeelden. Maar zo lees ik dan hier “achter het gemak van open source schuilt namelijk een schimmige wereld van licentievoorwaarden.” Ik heb even gecheckt en het artikel is niet uit 2002 en per abuis opnieuw online gezet. Dus eh, wat krijgen we nou.

Toen open source nog een nieuw verschijnsel was in het zakelijk firmament (eind jaren negentig) ontstond meteen discussie over de bijbehorende licentievoorwaarden. Die waren namelijk nogal anders dan het gebruikelijke licentiegeweld: in tegenstelling tot veel moeten betalen en beperkte rechten krijgen zonder aansprakelijkheid voor fouten, stond in opensourcelicenties dat je niet hoefde te betalen, alles mocht maar dat je (althans soms) wel mee moest doen met de opensourcegedachte. Oh en er was geen aansprakelijkheid voor fouten.

Dat “mee moeten doen” gaf de nodige bedrijven juridische zorgen, want die hadden allemaal net tien jaar geleerd dat geld verdienen met softwarelicenties verkopen het grote ding was. En dan zou je dus die software, die broncode gewoon weggeven en anderen alles laten doen daarmee zonder vergoeding? Kon niet waar zijn. De ietwat principiële opstelling van de Free Software Foundation hielp ook niet echt; nadat een stel slimmeriken de zakelijke term “open source” erop plakten en webbrowser Netscape vrijgaven onder zo’n licentie werd het iets makkelijker maar de twijfels bleven.

Die zorg over geheimhouding van je waardevolle software zien we ook meteen in dit artikel terug:

Stel je daarbij voor dat als je een opdracht hebt gegeven om aanvullend maatwerk te laten ontwikkelen op een Joomla platform, waarin een belangrijk deel van een businessproces in is verwerkt, de kans bestaat dat dit maatwerk vrijgegeven moet worden door de ontwikkelaar.

Ik noem dit altijd de IP-reflex: we hebben een stukje software dat we van onszelf zien (en dat noemen we IP) en dús moet dat waardevol zijn en dus geheim gehouden worden. Voor juristen heel normaal, je leert namelijk dat rechten van iemand zijn, en dus te beschermen. Maar de achterliggende zakelijke afweging – de onderliggende waardering – die blijft dan buiten beschouwing.

Zo ook hier: waarom is het waardevol om die businessprocesinformatie geheim te houden? Is het écht voordeliger voor het bedrijf om dat stukje software voor eeuwig in-house te houden, zelf te onderhouden en bij te werken? Wat voor superwaardevol bedrijfsproces heb je dan? Ik ben heel benieuwd.

Dit nog los van het juridische punt dat de GPL (want dat is de Joomla-licentie) helemaal niet eist dat als je maatwerk ontwikkelt, je dit vrij moet geven of terug moet leveren aan de Joomla community. De GPL zegt: wanneer jij maatwerk (voortbouwend op Joomla) levert aan een derde, dan moet die derde het maatwerk onder GPL kunnen gebruiken.

Maar in de meeste gevallen ga je een CMS helemaal niet aan derden leveren. Je installeert het CMS op je eigen server, voegt daar maatwerk aan toe en zet het ding aan. Er is dan geen situatie waarin de GPL enige eisen stelt. Wie een open source CMS inzet, hoeft zich nul zorgen te maken over het vrijgeven van enige maatwerkcode. Echt nul. Ik vind het echt kwalijk dat men anno 2020 nog steeds wat anders beweert.

Oh ja, inbreuk op rechten van derden. Dat zou zomaar kunnen, blijkt dat je Joomla in gebruik hebt en dat je de GPL schendt. Of dat je leverancier dat heeft gedaan. Dan krijg jij de claim. In theorie een probleem maar in de praktijk nog nooit voorgekomen, en ook iets waar je niet meteen een schádeclaim voor krijgt. In de opensourcegemeenschap is compliance het toverwoord: men eist dat je de licentie naleeft, maar naar de rechter voor een gebruiksverbod of schadevergoeding komt niet voor.

Een derde punt dat wordt aangedragen, is de beveiliging. Daar zou je niemand op aan kunnen spreken. En ja dat klopt, opensourcelicenties zeggen dat de makers nergens voor aansprakelijk zijn. Maar veel gesloten licenties zeggen dat ook (ik heb de Plate licentie niet gezien noch de SLA, dus ik weet niet hoe veel aansprakelijkheid zij aanvaarden voor securityfouten), dus in hoeverre dit uniek OSS aan te wrijven is?

Natuurlijk, met geslotensoftwareleveranciers kun je afspraken maken. En vooral: die kun je aansprakelijkheid en een vrijwaring opdringen, dus dan is het geregeld. Dat is de juridische mindset, wij zijn eigenlijk een soort tovenaars: zeg hoe het moet zijn, laat een handtekening zetten en bracchiabindo, we hebben het geregeld.

Ik sprak ooit een inkoper van IBM die bij leveranciers altijd vroeg om volledige aansprakelijkheid en een onbeperkte vrijwaring. Toen ik zei dat hij dat niet kreeg van mijn klant, was zijn reactie “mooi, want wie dat geeft die vertrouw ik voor geen cent”. Want leuk en aardig dat het op papier staat, maar wat is dat papier waard? Kan deze leverancier die kwaliteit leveren, heeft hij de expertise om de veiligheid echt goed op te lossen? Ja, het is hun product dus dan zullen ze het echt snappen. Precies, dat zeiden ze bij Zoom ook.

En dan de uitsmijter: “Het gebruik van closed source software maakt een organisatie minder kwetsbaar voor claims van buitenaf.” Dat is niet mijn ervaring, als je in de rechtspraak kijkt dan zie je eigenlijk alleen zaken tussen closedsourceleveranciers over inbreuk op elkaars licenties of rechten. Opensourcepartijen die procederen, dat komt gewoon niet voor.

Maar ach, leuk he weer eens terug naar hoe men vorig decennium dacht?

Arnoud

Nu ga ik aan mezelf twijfelen, is de GPLv2 eigenlijk wel een contract?

| AE 10903 | Intellectuele rechten | 48 reacties

Heibel in de Linuxtent, blogde ik vorige week. Ontwikkelaars aan het besturingssysteem lagen in de clinch over een Code of Conduct die ongepast gedrag vastlegt, met de nodige interpretatieproblemen tot gevolg. Dat leidde tot een oproep om je GPL-licentie in te trekken en zo je stem te laten horen. Waarop ik me afvroeg, kan dat… Lees verder

Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Intellectuele rechten | 34 reacties

Een lezer vroeg me: Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?… Lees verder

Wat is beter voor open source: rechtszaken of praten?

| AE 8911 | Intellectuele rechten | 16 reacties

Oh oh, Linus Torvalds in de bocht in een discussie bij de Linuxfoundation over GPL handhaving. Dan weet je het wel. De stelling was: “we can all decide to give up on the GPL, or we can enforce it in Courts.” Torvalds, zeer karakteristiek: “this arguing for lawyering has become a nasty festering disease, and… Lees verder

Hoe kan ik een opensourcemodule opnieuw implementeren?

| AE 8194 | Intellectuele rechten | 18 reacties

Een lezer vroeg me: Ik werk aan een opensourceproject dat een kloon (fork) is van een groter project. Wij krijgen bij onze nieuwste module nu het verwijt hun auteursrechten geschonden te hebben omdat de code te veel lijkt. Maar wij hebben deze echt zelf geschreven, hoewel de module wel exact hetzelfde doet. Plegen wij nu… Lees verder

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Intellectuele rechten | 40 reacties

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library… Lees verder