Rusland gaat open source gebruiken, niet teruggeven

oesjanka.pngIntrigerend maar wel lastig te lezen. De Russische Federale overheid overweegt (via Google Translate) bij de selectie van software de voorkeur te geven aan vrije en open source software, zo meldde Livre afgelopen week. Waarom het dan weer Russian FOSS (FROSS) moet heten in plaats van gewoon “open source” is me niet duidelijk.

Het feit dat de software geen licentiekosten kent en de licentie nooit afloopt, bleken de belangrijkste punten voor deze keuze. Dit omdat men wel genoeg had van de Amerikaanse plutocraten en hun betaalde licenties. Opmerkelijk is wel een ander voordeel: eventuele wijzigingen aan de broncode hoeven niet vrijgegeven te worden als de gewijzigde software uitsluitend intern wordt gebruikt.

Tsja. Op zich klopt dat, maar waarom is dat een voordeel? Wat voor bijdragen verwacht men te gaan doen die niet in handen mogen komen van antirussische krachten?

De aangepaste Linux-versie is gebaseerd op Red Hat. Hoe de nieuwe distributie gaat heten, is nog niet bekend. Rode Oesjanka-Linux wellicht?

Arnoud

Open source als concurrent, hoe bedoelt u?

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

After-dinner dip: mijn lezing over GPLv3, 13 november

vira.jpgOp 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

GPL compliance engineering guide uitgebracht

lolcat-im-in-ur-cvs.jpgVorige 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

Gids over GPL compliance uitgebracht

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

Plugins voor phpBB: verplicht GPL of toch niet?

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

Plugins voor Joomla: verplicht GPL of toch niet?

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

Ja, een licentie is een contract!

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.

Update (3 juli 2012): in de octrooicontext wordt een gesloten licentiecontract gebruikt om een beschuldiging van octrooischending te pareren.

Arnoud

Maakt linken met GPL code mijn code open source?

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

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

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