Tag: Gpl

About Gpl

Subscribe Feeds

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

 

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

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

Geplaatst op in 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?

Geplaatst op in 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 wel, een contract opzeggen in zo’n situatie? Maar nu ga ik zelfs twijfelen of er wel een contract ís.

Dat de GPL naar Europees recht een contract is, is al een hele lange aanname. De standaardlicentie komt uit de VS, en daar is de twijfel wel iets serieuzer: voor een overeenkomst is onder de common law het specifieke concept ‘consideration’ nodig, oftewel een tegenprestatie. Een schenking is dus géén overeenkomst daar, maar een eenzijdige rechtshandeling. In Europa waar de civil law geldt (zeg maar heel Europa behalve Ierland, Engeland en Wales) is het goed mogelijk een overeenkomst te hebben met maar één prestatie.

De GPL kent geen tegenprestatie, en kan daarmee dus geen contract zijn onder common law principes. In Europa is dat geen beletsel, dus kun je hier prima spreken van een GPL contract. (Bijkomstig voordeel is dat het Amerikaanse juristen irriteert zonder dat ze er wat aan kunnen doen.) Voor een contract is niet meer nodig dan een aanbod (dit mag je doen, onder deze voorwaarden) dat wordt aanvaard (lijkt me leuk, ik ga typen en verspreiden).

Hoe meer ik er echter over nadenk, hoe meer ik twijfel of dit eigenlijk wel goed gaat. Want die aanvaarding past niet goed in het systeem van de wet, dat er vanuit gaat dat je akkoord zegt tegen de aanbiedende partij. Als die aanvaarding niet daadwerkelijk aankomt, dan gaat er van alles schuiven. Het belangrijkste is dat de aanbieder dan het aanbod mag intrekken, waarmee het vervalt. Oftewel, zolang niemand jou daadwerkelijk meldt “ik aanvaard de GPL op jouw software, dank je” dan kun je gewoon roepen “licentieaanbod ingetrokken, sorry” en kan niemand meer wat met je software.

De praktijk is natuurlijk dat iedereen gewoon zoekt naar de regel “GPL” in de hoofddirectory van de software en concludeert dat het wel goed zit. Maar je moet je best wel in juridische bochten wringen om dan tot een juridisch perfecte aanvaarding te komen. Een mogelijkheid is bijvoorbeeld dat je zegt, de aanvaardingshandeling (het gebruik van de software) bereikt de aanbieder niet maar dat is de aanbieder zijn eigen probleem (art. 3:37 lid 3 BW), had hij maar meer moeten opletten wie zijn software gebruikt.

Maar wat is het dan wel? De Amerikaanse constructie is een “toestemming onder voorwaarden”, analoog aan een bordje bij je erfgrens. Wie zijn landgoed openstelt met een bordje “Vrije toegang dagelijks tussen zonsopgang en zonsondergang” sluit dan geen overeenkomst, maar verleent eenzijdig toestemming onder een voorwaarde (namelijk dat het overdag is). Zolang die voorwaarde wordt gerespecteerd, mag je er zijn. Schend je de voorwaarde of vervalt deze, dan pleeg je erfvredebreuk en moet je dus wegwezen. Vertaal je dat naar softwareland, dan krijg je toestemming onder het auteursrecht om te handelen maar zodra je de voorwaarden schendt, eindigt de toestemming en heb je een probleem.

Het mooie van deze oplossing is, het maakt niet uit of je de voorwaarden aanvaardt of niet. Negeer ze en je pleegt sowieso inbreuk. Dus je hoeft helemaal niets te zeggen tegen de rechthebbende. De toestemming is ook niet zomaar intrekbaar: gezegd is gezegd, zeker gezien de constructie in de aanhef van de GPL dat het krijgen van een kopie van de software tevens toestemming inhoudt.

Het grote nadeel is natuurlijk, het is nog nooit getest bij de rechter. En ik weet ook niet op welke plek in het Burgerlijk Wetboek ik deze constructie zou moeten duiden. Maar het past beter bij mijn rechtsgevoel anno 2018.

Arnoud

Mag je licentie-incompatibele dependencies meeleveren met je software?

Geplaatst op in 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?

Het lijkt zo logisch om, als je eigen software afhankelijk is van andermans open source, die open source mee te leveren. Het is immers gewoon toegestaan om open source software te verspreiden, dat is het hele punt van open source. Het doet dus wat raar aan dat je bepaalde open source niet mee mag leveren.

De reden dat het soms toch niet kan, zit hem in de licentievoorwaarden. Sommige opensourcelicenties (met name de GNU GPL) eisen dat zogeheten afgeleide werken alleen mogen worden gedistribueerd onder die licentie. Als de licentie van het andere werk dit niet toestaat – zogeheten licentie-incompatibiliteit – dan is het dus niet mogelijk die twee samen te verspreiden.

Wat precies een afgeleid werk is, is al decennia een lange discussie, maar goed verdedigbaar is dat gebruik van een dependency daaronder valt. Heb je een specifiek ander stuk software nodig, dan bouw je voort op dat andere stuk software en dus ben je daar een afgeleide van. Hoewel ook goed verdedigbaar is dat je dan alleen functionaliteit aanroept, en dat valt buiten het auteursrecht en dus ook buiten de licentiescope. Maar als je dus zegt dat inroepen van dependencies jouw software een afgeleid werk daarvan maakt, dan moeten de licenties van de software en de dependencies allemaal compatibel met elkaar zijn.

Het gekke is dat het wél toegestaan is – ongeacht compatibiliteit – om te melden welke dependencies er gelden en de gebruiker die zelf te laten downloaden en installeren. Dat mag je zelfs automatiseren met een handig installatiescript of package manager-functionaliteit. Opensourcelicenties zijn namelijk distributielicenties, oftewel de voorwaarden gelden pas bij distributie. Wie alleen downloadt en gebruikt, heeft dus niets te maken met compatibiliteit van eventuele licenties.

Arnoud

Wat is beter voor open source: rechtszaken of praten?

Geplaatst op in Intellectuele rechten, 16 reacties

gpl-sans-plombeOh 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 the SFC and Bradley Kuhn has been the Typhoid Mary spreading the disease.” De juristerij als builenpest, oké dan. Heeft hij een bult, eh punt?

Handhaving van de GPL bij de rechter komt zelden voor. Afgezien van een paar simpele kortgedingzaken in Duitsland is er niemand die daarover echt procedeert. Daardoor ontstaat er enige onzekerheid in de markt: hoe ver gaat die GPL nou, wat mag er wel of niet. Maar het omgekeerde komt ook voor: geen rechtszaken, dan geloof ik het wel en ga ik gewoon doen wat ik wil totdat ze piepen.

Dat piepen, dat gebeurt regelmatig. De Linux-mensen, maar ook vele anderen, steken een hoop energie in het aanspreken van bedrijven en instellingen die de GPL niet netjes naleven. Informeel en achter de schermen, joh er gaat iets niet helemaal lekker, mag ik je een tip geven? En vrijwel altijd heeft dat effect, zij het dat het enige tijd kan duren. (Ik spreek uit persoonlijke ervaring vanaf de ‘andere kant’ van die tips.)

Zie je een overtreding van de GPL op jouw code, dan kún je natuurlijk ook een blafbrief sturen en daarna naar de rechter. Dat heeft nog niemand gedaan, mogelijk vanwege de kosten en het gedoe. Ook de onbekende status van de GPL speelt een rol – ga je wel winnen, zegt de rechter niet bijvoorbeeld iets doms straks over afgeleide werken waarmee de GPL tandeloos zou worden.

Torvalds:

But quite apart from the risk of loss in a court, there real risk is something that happens whether you win or lose, and in fact whether you go to court or just threaten: the loss of community, and in particular exactly the kind of community that can (and does) help. You lose your friends.

En dat is natuurlijk waar. Als je iemand aanklaagt, verstoor je de relatie. Want welk bedrijf je ook dagvaardt, de reactie zal eigenlijk altijd hetzelfde zijn: de luiken gaan dicht, een externe advocaat doet de correspondentie en alle banden met het OSS-project in kwestie gaan de ijskast in want alles kan tegen je worden gebruikt. Van zo’n klap herstel je niet makkelijk. En als je dat als community doet, loop je ook de kans dat ánderen gaan denken, die club daar moeten we van wegblijven want die klagen je aan, raar spul dat open source. Dus het is zeker niet gezegd dat het een goede move is.

Natuurlijk, het gevolg van de Linus-aanpak is wel dat sommige gebruikers wegkomen met licentieschendingen. Dat voelt oneerlijk; doe jij veel moeite netjes compliant te zijn, gaat je buurman je de pas afsnijden met in feite gejatte code. En dan zegt die Torvalds “heb geduld, we spreken ze nog wel een keer en over een jaar of twee draaien ze vast bij”. Logisch dat je daar juridisch van gaat dreigen. Maar dan kom ik weer bij het juridische punt: hoe groot acht je de kans dat je gaat winnen, en wat heeft jouw rechtszaak dan voor gevolgen voor de community?

Arnoud

Maakt die Google/Oracle-uitspraak de GPL krachteloos?

Geplaatst op in Intellectuele rechten, 33 reacties

gpl-sans-plombeJe kunt je mooie GPL vaarwel kussen, las ik bij Ars Technica vorige week. Die Google/Oracle uitspraak die een API fair use verklaarde, gaat namelijk de GPL en consorten onderuit schoffelen. Oké, het was de advocaat van Oracle die dat schreef, maar er zit een argumentatie bij. Dus laten we die eens nader bekijken.

In het kort is het een typisch “de wereld stort in want ik kreeg ongelijk”-verhaal dat te reduceren is tot deze quote:

While we don’t know what ultimately swayed the jury, Google’s narrative boiled down to this: because the Java APIs have been open, any use of them was justified and all licensing restrictions should be disregarded. In other words, if you offer your software on an open and free basis, any use is fair use.

Volgens mij slaat advocate Hurst hier de plank stevig mis, want er is nogal een verschil tussen een API hergebruiken met je eigen code en het hergebruiken van code. En dát is waar de GPL voor geschreven is: copypasten van code, of het linken/combineren van die code in je eigen software. Bij dergelijke handelingen heb ik weinig twijfel dat sprake is van een auteursrechtelijk relevante handeling.

Inderdaad, als iemand een GPL header file of API zou hebben en jij zou een eigen implementatie daarvan schrijven, dan zou je waarschijnlijk in Amerika onder fair use daarmee vrij lopen zodat de GPL niet op jou van toepassing zou zijn. Maar is dat vervelend? Volgens mij is dat een behoorlijk uitzonderlijke situatie en zeker niet de normale wijze van hergebruiken van iemands GPL werk.

Dus nee, hier wordt uit de nek gekletst.

Arnoud

Hoe kan ik een opensourcemodule opnieuw implementeren?

Geplaatst op in Intellectuele rechten, 18 reacties

software-disc-cd-dvd-dragerEen 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 inbreuk?

Auteursrecht rust alleen op code zelf. Op functionaliteit of ideeën kun je geen auteursrecht claimen. Als persoon A een module van persoon B opnieuw implementeert zonder naar B’s code te kijken, dan heeft hij geen auteursrecht geschonden. Dit bewijzen is natuurlijk erg ingewikkeld als B’s code vrij op internet staat. Bewijs maar eens dat je die niet gezien hebt.

Mogelijk is er een beter argument. Als het écht zo is dat er maar één manier is om deze code te schrijven, dan kan er geen auteursrecht op rusten. Auteursrecht vereist creativiteit, en die kan niet bestaan als er maar één route is. Ik twijfel wel of het echt zo werkt. Vrijwel altijd zijn er alternatieven waaruit je kunt kiezen bij het schrijven van software. Al is het maar of een while() lus handiger is dan for() of dat je beter iets in een functie kunt stoppen.

Terug bij af dus. Bewijs maar dat je B’s code niet gezien hebt en er dus niet uit gekopieerd. Dat zal niet meevallen. De standaardtruc is clean room reverse engineering, maar dat werkt niet bij open source.

De enige optie denk ik is dat je heel veel tussentijdse versies publiceert om zo te laten zien dat je van nul bent begonnen met die module. Zeg maar elke keer met tien regels code erbij. Dan bewijs je dat je van nul af zelf schreef en dan heb je dus niet gekopieerd. Het lijkt me wel een heel gedoe.

Arnoud

Maakt linken van een GPL bibliotheek je software automatisch GPL?

Geplaatst op in 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 gebruikt? Het programma wérkt niet zonder de library. Maar Europees auteursrechtelijk waag ik dat toch te betwijfelen.

De term ‘afgeleid werk’ is een tikje ongelukkig. De term komt uit het Amerikaans auteursrecht; in Europa kennen we alleen de ‘verveelvoudiging in gewijzigde vorm’, oftewel een kopie, al dan niet aangepast, van (een deel van) het werk. Dat klinkt inderdaad wat beperkter, en dat is het volgens mij ook.

In de SAS/WPL-uitspraak heeft het Hof van Justitie de grenzen getrokken van het software-auteursrecht. In die zaak beriep SAS zich op een auteursrecht voor haar programmeertaal en functionaliteit daarin, maar gedaagde WPL kreeg gelijk, zo’n auteursrecht bestaat niet.

Auteursrecht op software bestaat volgens de hoogste Europese rechter alleen op de broncode en de daarvan afgeleide uitvoerbare code. Men noemt dit de ‘uitdrukkingswijzen’ en daaronder wordt alleen datgeen verstaan dat tot “reproductie van het computerprogramma of tot het computerprogramma zelf kunnen leiden”. Je moet dus, kort gezegd, met wat er overgenomen of gebruikt is in het andere werk, het originele programma zelf althans gedeeltelijk kunnen terugvinden.

Bij het gebruik van een software library roep je in je eigen programma een functie aan, waarna de implementatie van de library wordt uitgevoerd om de betreffende functionaliteit te realiseren. In het SAS/WPL arrest ging het om functies uit een programmeertaal, maar ik zie het verschil niet met een API van een specifieke bibliotheek. In feite is de implementatie van een programmeertaal ook een library (of set libraries) die je middels een API aanroept. Wil je in C een tekst op het scherm, dan zeg je printf("Hello, world!");, waarna libc de implementatie daarvan uitvoert, en wil je bij GNU readline een regel invoer verkrijgen dan zeg je readline(my_prompt);, waarna readline de implementatie daarvan uitvoert. Dat is technisch volgens mij dus hetzelfde.

Meer algemeen, als het aanroepen van een functie van een bibliotheek zou meebrengen dat je het auteursrecht op die bibliotheek schendt, dan zou het auteursrecht dus in feite de functionaliteit beschermen die achter de functie zit. En dát is nadrukkelijk niet de bedoeling in het Europese auteursrecht.

Gelet op deze overwegingen moet worden geconstateerd dat, wat de elementen van een computerprogramma betreft (…), noch de functionaliteit van een computerprogramma, noch de programmeertaal en de indeling van gegevensbestanden die in het kader van een computerprogramma worden gebruikt teneinde de functies daarvan te benutten, een uitdrukkingswijze van dit programma vormen in de zin van [het auteursrecht].

Het opnemen van een functie-aanroep in je programma (zoals printf("Hello, world!"); of readline(my_prompt);) kan dus niet leiden tot een auteursrechtinbreuk op libc of GNU readline, omdat die functie-aanroep nog geen uitdrukkingswijze van het programma libc dan wel readline vormt. Pas als je code zou overnemen, ook in gedeelten, zou er inbreuk kunnen ontstaan.

Wat de GPL of de FSF zeggen over afgeleide werken, linken of Complete Corresponding Source doet er hierbij volstrekt niet toe: je komt pas aan terminologie uit een licentie toe als er sprake is van inbreuk. Pas dan zou de aanroeper van de software immers hoeven te zeggen “geen inbreuk, ik heb een licentie”.

Het argument uit Oracle/Google dat het maken van de API zélf creatief is, gaat hierbij niet op. In die zaak werd Google’s API-kloon van Java inbreukmakend geacht omdat Oracle creatieve arbeid had gestoken in het definiëren daarvan. Maar dat was natuurlijk ook het geval bij de SAS programmeertaal waarvoor WPL programma’s maakte. De functionaliteit, dus ook hoe de functies heten, wat ze doen en welke parameters en return values daarbij horen, is geen “uitdrukkingswijze” van het programma.

Een complete reproductie van de API zou mogelijk wél inbreuk kunnen zijn. In de SAS/WPL uitspraak stond ook de eigen handleiding van WPL ter discussie, waarin elke functie was opgenomen (maar volgens mij ook stukken tekst uit de documentatie van SAS). Dit is iets dat de rechter per geval moet onderzoeken: hoe veel is er overgenomen en hoe creatief is hetgeen overgenomen is? Mogelijk dat bij een handleiding het citaatrecht nog een verweer kan zijn, maar bij een volledige overname met als doel een interface-compatibele kloon te schrijven twijfel ik zeer of dat opgaat. Maar wellicht biedt dit dan een lichtpuntje:

In deze context moet worden gepreciseerd dat indien een derde een gedeelte van de bron- of doelcode betreffende een voor een computerprogramma gebruikte programmeertaal of indeling van gegevensbestanden zou aanschaffen en hij met behulp van deze code soortgelijke elementen in zijn eigen computerprogramma zou creëren, deze handeling mogelijkerwijs een gedeeltelijke reproductie in de zin van [het auteursrecht] zou opleveren.

Het lijkt dus echt nodig dat er ook broncodes worden overgenomen. En puur de definities van de functies voldoen niet snel aan die eis.

Wat vinden jullie? Is er een wezenlijk verschil tussen een API van een of andere bibliotheek aanroepen versus de functies uit een programmeertaal? Maakt het uit of er maar één implementatie van die API+bibliotheek is? Of zijn er andere redenen om een API-aanroep toch inbreuk op het auteursrecht te noemen?

Arnoud

Open source met verspreidingsverbod

Geplaatst op in Intellectuele rechten, 50 reacties

Interessante vraag vorige week bij mijn blog over “van wie is dat CMS”:

Hoe zit het met een constructie waarin de ontwikkelaar jou enerzijds het CMS onder de LGPL beschikbaar stelt en jij je er vervolgens contractueel op vastlegt het niet te verspreiden op last van een fikse boete? Waarbij de boete vervalt bij faillisement van de leverancier.

Dit is een creatieve poging om een soort van escrowregeling op te zetten. Het idee is dan dat je bij faillissement een LGPL opensourcelicentie krijgt, zodat je toch door kunt blijven werken met die software.

Alleen: het gaat niet werken.

De LGPL is in feite gewoon een licentiecontract (ja, een contract) en contracten kunnen door een curator worden gepasseerd. Dus of je nu een speciale escrowclausule in je ‘gewone’ licentie opneemt of zo’n LGPL-met-boete-constructie hanteert, het verliest zijn waarde zodra de leverancier failliet is.

De constructie deed me denken aan de term open source escrow. Dit komt erop neer dat de escrowagent de broncode in escrow houdt en uitbrengt onder een open source licentie zodra bekend is dat de leverancier failliet gaat (of met zijn bedrijfsvoering stopt om andere redenen). Dat kan dus, maar alleen als de agent de auteursrechten heeft.

Zouden mensen hier behoefte aan hebben? En zou het überhaupt werken, een stukje propriëtaire software die ineens open source wordt? Wie heeft zin daaraan te gaan werken?

Arnoud