Internetrecht door Arnoud Engelfriet

Soms lijkt het wel of de softwareindustrie nog in 2002 leeft, toen Linux nog als Lainux werd uitgesproken en SCO nog geloofwaardig was met haar claims van gestolen code. In een onderzoek van de European Software Association, waar ik ook nog nooit van gehoord had, las ik weer de bekende taal over open source als ‘bedreiging’ of ‘concurrentie’ voor de softwareindustrie. Wat moet ik me daarbij voorstellen?

Open source software is een ontwikkelmodel. Je schrijft (mee aan) software en stelt die beschikbaar onder een licentie waarmee anderen erop door mogen ontwikkelen. Je kunt kiezen voor een liberale licentie (BSD), of de eis stellen dat die anderen ook weer onder open source voorwaarden moeten doorontwikkelen (GPL). Dat komt in wezen neer op een hele grote samenwerkingsovereenkomst.

Als ik het zo lees, dan vinden de ESA-leden vooral dat idee van samenwerken eng, omdat je dan code beschikbaar stelt waar een concurrent wat mee mag doen. Iets waar “certain vendors, particularly those developing widely used applications” kennelijk nogal wat moeite mee hebben. Oh ja, en het feit dat overheden steeds vaker open source-oplossingen eisen is vervelend, want dan kan die overheid na oplevering van de software zomaar iemand anders vragen om het onderhoud te doen als je niet genoeg kwaliteit voor je geld levert.

Stel je voor zeg, straks moet je nog je best gaan doen als softwarebedrijf omdat iemand anders naar de concurrent stapt. Waar is de tijd gebleven dat je gewoon een matig stuk software kon opleveren en jarenlang grof geld kon opstrijken voor onderhoud en doorontwikkeling?

Arnoud

Op 13 november organiseert de Vereniging Informaticarecht Advocaten een studiemiddag/avond over open source software (meelezende advocaten: 5 PO punten!). Drie keer raden wie er over GPLv2 versus GPLv3 mag komen vertellen.

De organisatie was zo vriendelijk mij na de borrel en het diner in te plannen, dus dat kan nog leuk worden.

Arnoud

Vorige week verscheen versie 1 van de GPL Compliance Engineering Guide, geschreven door Armijn Hemel die u waarschijnlijk wel kent van het GPL-Violations project. Dit is een handleiding over hoe GPL-schendingen op te sporen. Een mooie aanvulling dus op de gids van SFLC waarin algemene stappen staan over hoe je je als bedrijf aan de GPL moet houden.

Wie zin heeft om eens wat apparaatjes open te schroeven en te kijken welke GPL software hij kan vinden, moet zeker eens met deze gids aan de gang gaan. Van nmap commando’s tot soldeerinstructies om een apparaat aan je PC te kunnen hangen zodat je het kunt inspecteren.

Veel schendingen blijken in de CE industrie voor te komen. Niet zo gek gezien de zeer lage marges en hoge volumes: het gaat om snelheid en kostenbesparingen bij veel dozenschuivers, en de kosten van het volledig compliant zijn met open source licenties wegen daar niet altijd tegenop. Met gidsen als deze kunnen mensen gemakkelijker violations aantonen, en bedrijven die dit doen onder druk zetten zodat iedereen, ook de low-margin CE industrie, zich netjes aan de licenties houdt.

Via The Inquirer.

Arnoud

De Software Freedom Law Center (SFLC) heeft een gids uitgebracht over hoe bedrijven zich aan de GPL moeten houden. De SFLC is verantwoordelijk voor de meeste Amerikaanse rechtszaken over inbreuk op de GPL, hoewel ze in tegenstelling tot het Duitse GPL-Violations.org eigenlijk altijd schikken, maar dat terzijde.

Nu wil je als bedrijf natuurlijk niet in een rechtszaak verwikkeld raken over een vermeende GPL-schending, of er nu geschikt wordt of niet. Het is dus zaak te zorgen dat je weet aan welke verplichtingen je je moet houden, en om dat ook aan je ontwikkelaars uit te dragen. Plus, niet te vergeten, aan je bedrijfsjurist of advocaat, zodat die niet de hele tijd “nee” zegt uit vermeende angst voor aansprakelijkheid of het zogenaamde virale aspect van de GPL. Deze gids kan daarbij helpen.

De belangrijkste punten uit de gids op een rijtje:

• Weet wanneer de licentie van toepassing is: klinkt als een open deur, maar dit is de grootste uitdaging voor bedrijven die GPL software gebruiken.
• Let op uw software-acquisitie: uw leveranciers leveren u open source, en met een beetje geluk weten ze dat zelf ook. Controleer dus wat u krijgt, en neem een boetebeding op in de leveringscontracten voor het geval u iets krijgt waar u niet om gevraagd heeft.
• Houd alle releases goed bij: tussen releases kan het nodige veranderen aan de software-architectuur. De kans is dan aanwezig dat GPL software ineens anders wordt meegelinkt of gecombineerd, en dat kan juridische gevolgen hebben.
• Ontsla uw “build guru”: zorg ervoor dat het build-proces waarmee de software wordt gecompileerd en voor verspreiding geschikt gemaakt, niet afhankelijk is van één persoon. De kennis in het hoofd van die persoon moet worden gedeeld.

Deze punten zijn inderdaad relevant voor elk bedrijf, maar hoe je ze praktisch uitwerkt is een heel ander verhaal. Ik heb zelf van 2002 tot 2008 bij Philips aan deze en vergelijkbare punten gewerkt, en ik weet uit eigen ervaring en die van collega’s bij andere bedrijven dat dit soms jaren kan duren om goed te krijgen. Met name het punt van leveranciers is een continu proces van aandacht, opletten en aanpakken. Deze gids is dan ook een goed startpunt om je eigen bedrijfsprocessen mee te verbeteren, maar verwacht niet dat het rondmailen van deze gids naar de ontwikkelaars en juristen voldoende is om open source problemen te vermijden.

De gids bevat verder nog een goede uitleg over wat je nu precies moet uitleveren als je GPL software in een product verwerkt, en een sectie over hoe om te gaan met vermeende inbreuk op de GPL.

Via Slashdot.

Arnoud

Bij de phpBB-gemeenschap een interessante discussie over plugins voor deze forumsoftware. PhpBB is open source en beschikbaar onder de GPL (versie 2). De vraag is dan wat dat betekent voor uitbreidingen en plugins voor phpBB.

De phpBB software is niet zo netjes opgezet als Joomla!, waardoor mijn redenering over plugins voor Joomla van afgelopen februari hier niet zomaar opgaat. Bij phpBB kun je een uitbreiding (een “mod”) alleen maken door regels code uit phpBB zelf te wijzigen en van uitbreidingen te voorzien. Dan zitten er in je mod dus stukken code die uit phpBB-bestanden komen. Dat is in principe een verveelvoudiging in gewijzigde vorm of een ‘afgeleid werk’ in de terminologie van de GPL.

Op de phpBB-site zelf wordt het zo uitgelegd:

Most modification require phpBB to work so most modifications need to be released under the GPL v2. … All modifications will have some part of it that needs to be released under GPL v2. These parts are usually what is in the install script or in other words, the part that integrates the script in to phpBB.

In de discussie zegt ene Alfatrion nog:

Copying several lines of could would fall under fair use for the states or the more limited European quoatation exemptions (art. 15a). This is true for most of the world because of the Berne Convention.

Wellicht is dit gebruik ‘fair use’ naar Amerikaans recht, maar ik betwijfel het. En gezien het feit dat deze persoon mijn blog citeert, is hij (zij?) waarschijnlijk Nederlander. En dan kan hij geen beroep doen op ‘fair use’. Wie in Nederland een beschermd werk wijzigt op een manier die schending van auteursrecht oplevert, kan in Nederland voor de rechter worden gedaagd. De zaak zal dan naar Nederlands recht worden beoordeeld.

Citaatrecht bij software is iets waar weinig juristen in geloven. Ik zou denken dat het opgaat als sprake is van een bug report, dan moet je regels citeren om te laten zien waar de fout zit. Maar jij bespreekt of bekritiseert deze regels niet, je breidt ze uit. En dat is een verveelvoudiging in gewijzigde vorm en geen citaat.

Afhankelijk van hoe veel je kopieert uit de originele bestanden, zou je wellicht aanspraak kunnen maken op artikel 18a Auteurswet:

Als inbreuk op het auteursrecht op een werk van letterkunde, wetenschap of kunst wordt niet beschouwd de incidentele verwerking ervan als onderdeel van ondergeschikte betekenis in een ander werk.

Een paar regeltjes uit phpBB in een groot eigen werk, met als enige doel aangeven waar in phpBB het eigen werk moet worden ingevoegd, zou onder deze uitzondering moeten vallen.

Ga je echter uitgebreid bestaande code aanpassen en niet zozeer eigen code toevoegen, dan ben je toch echt een afgeleid werk aan het maken.

Arnoud

Een lezer had een plugin voor het open source content management system Joomla! gemaakt, en vroeg zich af of hij die mocht verkopen zonder de broncode open source te maken. Joomla! is beschikbaar onder de GPL. Een afgeleid werk, dat wil zeggen een aanpassing of uitbreiding, mag je dus alleen ook weer onder de GPL verspreiden. Je mag er best geld voor vragen, maar je moet de broncode meeleveren. Geld vragen heeft niet zo veel zin, want iedereen mag de software weer verspreiden, zelfs gratis.

Maar hoe zit dat met een plugin? De FSF, auteurs van de GPL, vinden niet verrassend dat elke plugin GPL moet worden. De tekst van GPL (v2) zegt echter:

If identifiable sections of [the modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

Een plugin die uitsluitend gebruik maakt van de gewone plugin API zou ik beschouwen als een apart werk. Er zitten geen auteursrechtelijk beschermde stukjes van Joomla zelf in zo’n plugin. Het aanroepen van API calls is technisch noodzakelijk en daarom niet auteursrechtelijk relevant. En in die situatie mag je de plugin los van Joomla! verspreiden op elke manier en onder elke licentie die je goeddunkt.

Wat niet mag, is Joomla! in combinatie met de plugin verspreiden. Maar dat komt niet zo vaak voor, omdat Joomla! een webapplicatie is. Plugins worden eigenlijk altijd los gedownload door mensen die Joomla! al geïnstalleerd hebben. Joomla! zelf heeft hierover nagedacht en concludeert dat :

We’ve also decided that we do not have the authority to publish Joomla! under a version of the GPL that gives exceptions for proprietary extensions. It’s difficult to relicense a GPL’d project, and there is no indication that OSM currently has that ability. Our current understanding is that extensions that aren’t released under the GPL or compatible licenses are non-compliant, and that view is based on the guidance of both the Free Software Foundation and the Software Freedom Law Center.

Op zijn minst zul je dus enige weerstand vanuit de Joomla!-gemeenschap ondervinden als je plugins uitbrengt onder een andere licentie dan de GPL. Echter, gezien het feit dat er heel veel plugins onder een “commercial license” bij Joomla! zelf te vinden zijn, zou ik me daar geen al te grote zorgen over maken.

Zie ook de recente discussie bij Joomla! zelf.

Arnoud

Naar Nederlands recht is een licentie een contract. Helaas voor PJ, maar zo is het toch echt. In Nederland dan; naar Amerikaans recht kun je er over twisten, zeker als de licentie niet voor geld wordt verstrekt.

Deze discussie speelt nogal eens bij open source en Creative Commons, en werd hier zaterdag nog opgerakeld bij mijn blogbericht over het effect van CC. Ik vond het onderwerp te belangrijk om alleen maar in de comments te hebben staan, vandaar dat ik er een nieuwe post aan wijd.

Licentie is een duur Latijns woord voor toestemming (licere) om iets te mogen doen. Als je voorwaarden wilt stellen aan de verstrekking of scope van je licentie (kopiëren mag, maar alleen met broncode er bij bijvoorbeeld), dan kan dat niet eenzijdig. Je kunt immers iemand niet eenzijdig dwingen zich aan bepaalde voorwaarden te houden.

De enige manier om iemand bepaalde voorwaarden op te leggen is middels een overeenkomst. Zo biedt de supermarkt mij elke zaterdag een overeenkomst aan: u krijgt een licentie tot binnentreden, mits u een mandje of winkelwagentje meeneemt. Ik kan die overeenkomst aangaan of niet. In het laatste geval moet ik buiten blijven. Ga ik naar binnen zonder mandje of wagentje, dan kan men mij (proberen te) dwingen er eentje te gebruiken, of de overeenkomst ontbinden wegens wanprestatie en mij buiten zetten. Ik pleeg dan immers lokaalvredebreuk.

Zo ook met software. Je moet als gebruiker natuurlijk akkoord gaan met de voorwaarden waaronder je de licentie geboden wordt. Bijvoorbeeld de prijs betalen, broncode van afgeleide werken publiceren of een bronvermelding doen. Wil je dat niet, dan ben je niet aan de voorwaarden gebonden want dan heb je het aanbod afgewezen.

Natuurlijk verlies je de aangeboden rechten als je de voorwaarden niet wenst te aanvaarden. Je valt dan terug op de wettelijke rechten aangaande software: als rechtmatige verkrijger mag je de software op 1 PC draaien (art. 45j) en een backup maken (art. 45k). Wie dus software legaal downloadt, hoeft geen EULA te aanvaarden om deze te mogen gebruiken.

Arnoud

Een open source ontwikkelaar mailde me:

Ik wil voor mijn programma gebruik maken van de s-lang library. Nu zag ik dat deze onder de GPL valt, maar mijn programma is tot nu toe altijd onder de BSD licentie uitgebracht. Moet ik mijn programma nu GPL maken?

Inderdaad heeft de GNU General Public License (GPL) als eis dat je “afgeleide werken” alleen onder de GPL mag verspreiden. Dit mechanisme zorgt er voor dat mensen die voortbouwen op GPL code, hun bijdragen niet voor zichzelf mogen houden. Nare mensen zien dat als een “viraal effect“, ik zie het als een belangrijke voorwaarde voor open innovatie.

De combinatie van eigen code en GPL code kan dus alleen onder de GPL worden uitgebracht. De vraag wanneer iets nu een afgeleid werk is, laat ik even in het midden. De vraag is hier tenslotte of dat eigen programma op zichzelf ook onder de GPL moet worden geplaatst, of onder de huidige licentie kan blijven.

De GPL zegt daar het volgende over:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Vrije vertaling: jouw code blijft jouw code, en als je daar een BSD licentie onder plakt, dan mag dat. Het is alleen de combinatie van jouw code en de s-lang library die onder GPL verspreid mag/moet worden. Knipt iemand s-lang weg, dan blijft jouw code over en die is onder BSD. Bouwt die iemand de code dan om naar bijvoorbeeld ncurses ipv s-lang, dan kan hij het resultaat onder zijn eigen gesloten licentie aanbieden als hij dat wil (want ncurses is MIT-licensed).

Kortom, laat de BSD license op je eigen werk staan en leg in de README uit dat je s-lang nodig hebt. Met eventueel een tekstje als “Since s-lang is GPL, when you distribute the combination of this software and s-lang, you must comply with the GNU GPLv2 for the combination.”

Arnoud

Versie 3 van populairste open source licentie introduceert vérgaande verboden op octrooien, technische voorzieningen en beperkt toegankelijke hardware.

Na vijftien jaar is er dan eindelijk een derde versie van de GNU General Public License. De reden: onvrede over bepaalde praktijken in de open source wereld. In dit artikel, gepubliceerd in het juridisch tijdschrift Computerrecht bespreekt ICT-jurist en octrooigemachtigde Arnoud Engelfriet de nieuwe bepalingen in GPL versie 3. Download het artikel (PDF, 1.7 MB).

Lees verder in Uit principe: de GNU General Public License (GPL) versie 3 (in Software > Open source software @ iusmentis.com).

Arnoud

Alweer een zeer juiste observatie over GPL versie 3 in The Jem Report:

With events like Eben Moglen’s bizarre tirade against Tim O’Reilly, the FSF leadership (even though Moglen is no longer officially a leader, he still acts as a spokesperson) is appearing more like a group of religious extremists, and less like programmers intent on creating free replacements for proprietary programs. The FSF’s focus is increasingly to protest, boycott, censure, and exclude all things it does not find morally agreeable. By contrast, it is the open source community that is doing all the real work — the coding, the documentation requesting, and the reverse-engineering. The rift is forming primarily between the people who do the talking, and the people who do the actual software development. This has come to mean a rift between free software, which for all its bluster and bombast has failed miserably to produce a complete GNU operating system; and open source, which has produced many financially and/or technologically successful operating systems over virtually the same period of time.

Inderdaad. Open source is een ontwikkelmodel. Vrije software is een sociale beweging.

Alleen die laatste opmerking over “complete GNU operating system” is niet helemaal terecht. De Hurd kan na vijftien jaar ontwikkelen echt wel opstarten. Die oude grap

Q: What’s the difference between GNU and Linux?
A: Linux has a kernel that boots.

is dus echt achterhaald.

Lees verder in The real heart of the GPLv3 rift.

Arnoud