Internetrecht door Arnoud Engelfriet

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

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

Gisteren gaf ik een lezing over GPL versie 3: Uit principe - de GNU General Public License versie 3. De bijbehorende tekst staat nu via CIER online en verschijnt ook in het eerstvolgende nummer van Computerrecht (2007/5).

Het was een grote uitdaging om deze complexe licentie op een duidelijke manier toe te lichten, maar ik heb wel het gevoel dat het een eind gelukt is.

Een aantal mensen had me nog gevraagd om de sheets, maar die verspreid ik normaal niet. Sheets gebruik ik alleen ter ondersteuning van mijn verhaal, en ze zijn dan ook nauwelijks op zichzelf te begrijpen. Een voorbeeldje:

Dat doet me er aan denken dat ik al een tijd weinig over presenteren heb geblogd. Het ligt ook een beetje buiten het onderwerp internetrecht. Desondanks: zou u, beste lezer, hier meer over willen zien?

Arnoud

Voor wie wil horen waar GPL versie 3 nu eigenlijk over gaat: komt allen volgende week -3 oktober dus- naar het Molengraaff Instituut voor Privaatrecht, Drift 9 te Utrecht. Wel even opgeven bij CIER.

GPLv3 is tegen. Tegen DRM, tegen software-octrooien en vooral tegen bedrijven die hun hardware beperkt toegankelijk maken. En dat is een slechte zaak voor open source. Waar versie 2 een goede, pragmatische basis voor samenwerking bood, dringt versie 3 van de populairste open source licentie een rigide ‘vrije software’ regime op. Dit regime verstoort de balans die ten grondslag ligt aan het zo succesvolle model van open source. En daarmee is GPL versie 3 in feite tegen open source.

Arnoud

De auteurs van het programma BusyBox hebben een rechtszaak aangespannen tegen het bedrijf Monsoon Multimedia wegens schending van GPL versie 2 in digitale videorecorders van Monsoon. Tweakers parafraseert net zoals iedereen klakkeloos het persbericht:

De auteurs, gesteund door de FSF, hebben hiermee de eerste rechtzaak in de Amerikaanse geschiedenis waarin een bedrijf wordt aangeklaagd wegens zijn vermeende disrespect jegens de gpl-softwarelicentie.

Dit is helemaal niet de eerste zaak, dat was MySQL vs Progress maar die zaak werd geschikt. Zoals hier waarschijnlijk ook wel zal gebeurenook gebeurd is trouwens. Maar goed, een persbericht met “Tweede rechtszaak aangespannen” scoort lang zo mooi niet natuurlijk.

Het begon zo onschuldig. In maart postte ene RyecoAaron op een Monsoon support forum

Do the Hava boxes run Linux? nmap reports that it is and thinks it might be a Linksys WRT54GL

Ja, inclusief smiley.

Het duurde even, maar op 5 september postte Gary-MM van Monsoon:

I have a little secret to let you in on - HAVA runs Linux! Yes, much of the source is GPL and we should publish those sections which we have modified per the terms of GPL. A project is underway to pull this together.

Inderdaad, dat klopt niet; ze moeten alle GPL broncode aan klanten beschikbaar stellen, niet alleen de gewijzigde broncode. Maar op 6 september meldde het bedrijf dan ook de hele broncode van Busybox te zullen vrijgeven.

Als iemand aangeeft dat hij fout zit en de fout gaat herstellen, is het wel een beetje erg snel om dan twee weken later een rechtszaak te beginnen. Dat heet rauwelijks dagvaarden en is niet netjes. Zeker als je de bijdragen van het bedrijf aan het forum tegen ze gaat gebruiken:

15. Upon information and belief, on August 28, 2007, Defendants were notified by third parties of Plaintiffs’ copyright in BusyBox and of Defendant’s infringement thereof. This notification was provided via a public forum on Defendant’s website. Upon information and belief, on September 5, 2007, via the same forum, Defendant’s employee or agent, identified as “Gary-MM” of “MyHAVA Support”, confirmed that Defendant was redistributing BusyBox, but not providing source code as per the requirements of the License.

Dit soort dingen zullen bedrijven niet echt happig maken om in het openbaar te praten over hun open source-gebruik.

Gelukkig kan Monsoon er de lol van inzien:

Don’t worry kids, we’re taking care of it. It is all matter of course for such things, there is no conspiracy involved. I have said it before and will say it again, we have every intention of complying with the terms of GPL. This has been raised to the highest levels within the company and we are following through. Not being a lawyer, I am going to refrain from any more detailed comment.

UPDATE: (31 oktober) en natuurlijk is er geschikt.

Arnoud

Linus Torvalds spreekt: liever GPL versie 2 dan versie 3, zo meldt Tweakers.

‘Ik vind niet dat het een ‘verschrikkelijke’ licentie is,’ antwoordde Torvalds op de vraag van EFYTimes onder welke omstandigheden hij het onder de gplv3-licentie uitbrengen van de Linux-kernel zou steunen, ‘Ik vind alleen niet dat het eenzelfde soort ‘geweldige’ licentie is als gplv2.’ Alleen als de tweede versie van gpl er niet zou zijn, zou Torvalds overwegen van versie drie gebruik te maken: ‘Maar aangezien ik een betere keuze heb, waarom zou ik?’

In eerste instantie was Torvalds een van de grootste critici van GPL versie 3.

Hij noemt verder GPL versie 3 ‘egoïstisch’: waar versie 2 slechts eiste dat uitbreidingen werden gedeeld, wil versie 3 ook nog eens bepalen hoe iemand de code mag gebruiken. Iets waar ik het helemaal mee eens ben.

Arnoud