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

Software-licenties, met name open source licenties, hebben altijd uitgebreide en vergaande disclaimers. De OpenBSD open source licentie zegt bijvoorbeeld:

THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

De basisregel uit het recht is dat je aansprakelijk gehouden kunt worden voor onrechtmatig gedrag, en ook voor beloftes die je niet nakomt. Als je dus claimt dat je software perfect werkt, en er blijkt een fout in te zitten, dan heb je een probleem. Vandaar dat iedereen roept dat de software niets kan en nergens geschikt voor is.

Zo’n disclaimer werkt echter niet altijd. Zo mag een bedrijf in relaties met consumenten niet zomaar elke aansprakelijkheid uitsluiten. Als ik een wasmachine koop, dan moet deze gewoon werken en de leverancier kan niet met een sticker “This washing machine is provided as-is” daar onderuit komen.

Waarom trouwens met hoofdletters? Omdat Amerikaans recht (de Uniform Commercial Code, artikel 2-316) eist dat je bepalingen over aansprakelijkheid “conspicuous” weergeeft. En wat dat is, staat weer in artikel 1-201(b)(10):

“Conspicuous”, with reference to a term, means so written, displayed, or presented that a reasonable person against which it is to operate ought to have noticed it. Whether a term is “conspicuous” or not is a decision for the court. Conspicuous terms include the following: (A) a heading in capitals equal to or greater in size than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same or lesser size; and (B) language in the body of a record or display in larger type than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same size, or set off from surrounding text of the same size by symbols or other marks that call attention to the language.

Het hoeft dus niet per se in hoofdletters, maar in een plat tekstbestand heb je weinig andere keus.

Arnoud

Wanneer is bier bier als zodanig? Inderdaad, collega-octrooigemachtigde David Musker schreef een werkelijk briljante parodie op de “software patent” ruzies van 2004 en 2005.

Virtual Worlds, with their own economies and political systems, have become commonplace. This report summarizes the history of the Free Beer debate, which occurred some years ago in Wasted Life, the first virtual world to feature a patent system. For those unfamiliar with Wasted Life, suffice to say that its countries and institutions are closely based on those of our own world, though the many colourful personalities are, of course, entirely fictitious creations of the players themselves.

Lees verder in The great free beer debate or, what ales the patent system?

Arnoud

Op 13 december verscheen de handreiking van programma OSOSS ‘Het verwerven van (open source) software‘ (PDF), meldt Livre. Deze handreiking legt uit hoe de overheid om moet gaan met inkopen van open source software. Livre signaleert een opmerkelijke conclusie: gratis open source hoeft niet te worden aanbesteed.

Nu is dat natuurlijk waar, maar het gaat dan toch om maar een zeer kleine categorie open source software. Want heel veel open source is niet of nauwelijks gratis te gebruiken. De handreiking is iets genuanceerder:

In principe zijn overheidsorganisaties vrij om gratis software zonder aanbesteding in gebruik te nemen. Dit geldt ook voor open source software, mits dat dus gratis is (…). In de praktijk is dat echter niet altijd het geval. Open source software licenties bepalen dat open source software vrij en zonder kosten mag worden gebruikt. Er is dus geen licentievergoeding gekoppeld aan open source software. Dit betekent niet dat aanbieders van open source software dan maar gratis moeten aanbieden.

Wanneer de overheid producten of diensten in wil kopen, gelden daar bijzondere regels voor. Deze aanbestedingsregels schrijven gelijke behandeling van aanbieders, geen discriminatie en transparantie in de besluitvorming voor bij de aankoop. Een aantal actielijnen uit het actieplan open standaards en open source software noemen expliciet aanbesteding, inkoop en het gebruik van open source software. Maar expliciet open source voorschrijven ligt lastig, omdat dan aanbieders van gesloten software buitengesloten worden. Je kunt niet zeggen dat open source categorisch technisch beter is dan gesloten software, dus dan kun je open source niet als eis stellen.

Als software gratis beschikbaar is, hoef je geen aanbestedingsprocedure te volgen voordat je die mag downloaden en gebruiken. Dat is natuurlijk mooi voor open source, want heel veel open source staat gewoon gratis ter download op internet.

Vroegâh was dat een vrij normale manier om met open source aan de slag te gaan. Je had iets nodig, je zocht even op internet en je installeerde wat het meest aansprak of waar mensen op nieuwsgroepen of forums positief over waren. En werkte het niet, dan kon je op diezelfde groepen of forums even snel vragen wat je fout deed, en dan kreeg je nog nuttig advies ook. Sterker nog, als je aan je baas zou vragen of dat wel mocht, had je waarschijnlijk een probleem.

Open source jurist Brendan Scott noemde dat ooit de siege mentality: een IT-er ziet een handig stukje open source, vraagt zijn baas om toestemming, die aarzelt of zegt nee (”wat is dat voor onzin, gratis software”), vervolgens komen ze bij de bedrijfsjurist, die begint kwaad over virale software, slordige aansprakelijkheid en de aanvaarding naar Nederlands recht, en het eind van het liedje is dat de IT-er de software gewoon alsnog gebruikt maar dat tegen niemand zegt.

Maar in veel gevallen kom je er niet met die aanpak. Die is leuk voor een tool binnen de IT-afdeling, of een stuk standaardsoftware (zoals een webserver) dat je neer kunt zetten en dan gewoon werkt. Maar zeker als je met eindgebruikers te maken krijgt, komt er heel wat configuratie, integratie en ondersteuning kijken. Denk bijvoorbeeld aan training om mensen van Microsoft Word naar OpenOffice.org Writer te laten overstappen. Dan zal er al snel een externe partij ingeschakeld moeten worden om dat allemaal voor elkaar te krijgen, en dan kom je eveneens al snel weer bij de aanbestedingsregels. Want het aan de gang krijgen van software is een dienst.

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

Google Android is Java en toch ook weer niet. Onlangs bracht Google het Android-platform voor mobiele telefoons uit. Het platform is Linux-gebaseerd en je kunt de software in Java ontwikkelen. Bovendien is alle code beschikbaar onder de Apache licentie (dezelfde als die van de Apache webserver dus). Daarmee is Android open source. Mooi toch?

Mooi, maar wel vreemd. Sun’s Java platform is GPL, en op mobiele platforms geldt dan de eis dat je Java-applicaties ook als GPL moeten worden uitgebracht. Reden voor veel applicatie-ontwikkelaars voor mobiele platforms om Sun geld te betalen, zodat ze hun code voor zichzelf kunnen houden.

Hoe krijgt Google het met Android voor elkaar om Java te gebruiken en toch mensen toe te laten gesloten software voor Android te bouwen?

Heel simpel: er zit geen Java in Android.

Stefano Mazzocchi ontdekte dit als eerste, en legt uit:

Android uses the syntax of the Java platform (the Java “language”, if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android’s implementation of the Java SE class library is, indeed, Apache Harmony’s!)

The trick is that Google doesn’t claim that Android is a Java platform, although it can run some programs written with the Java language and against some derived version of the Java class library.

Een creatieve aanpak.

Via Planet, Slashdot en Fake Steve Jobs.

Arnoud

Sorry, het is laat en ik vond deze LOLcat grappig:

Arnoud

Een verbaasde lezer mailde me:

Gisteren wilde ik Python downloaden, en tot mijn verrassing kreeg ik toen een licentie voor mijn neus. Nu weet ik dat je voor gebruik en verspreiding van software een licentie nodig hebt, maar voor downloaden van open source? Ik zit toch pas aan de licentie vast als ik de software ga aanpassen of verder verspreiden?

Downloaden is legaal, maar voor software ligt dat anders. kopiëren, verspreiden maar ook downloaden van software mag alleen met toestemming. In plaats van het recht op een kopie voor strikt eigen gebruik, dat bijvoorbeeld downloaden van films en muziek legaliseert (ongeacht de bron), heeft de verkrijger van software alleen recht om een reservekopie (backup) te maken.

Wanneer iemand zelf het werk ter download aanbiedt, geeft hij daarmee een impliciete licentie voor anderen om het ook werkelijk te downloaden. Dat er in de zipfile of tarball misschien een lijst met voorwaarden voor gebruik zitten, is dan niet relevant. Die kun je pas lezen nadat de download klaar is, en die voorwaarden kunnen dan per definitie niet gelden voor de download zelf.

Dus of iets nou open source is of niet, maakt niet uit. Wat met toestemming ter download wordt aangeboden, mag je downloaden. De aanbieder is verantwoordelijk voor de toestemming om het te mogen aanbieden, al kun je als downloader niet zomaar je kop in het zand steken. “Klik hier voor Windows XP” is geen legitieme download.

Sommige download-sites hanteren een doorklikregime: de bezoeker moet eerst voorwaarden accepteren voordat hij een download-link te zien krijgt. Met zo’n regime is de downloader natuurlijk gebonden aan de voorwaarden die hij accepteert.

Een grijs gebied is bijvoorbeeld de tekst “Read and accept the GNU Public License (GPL)” op de SCTP download pagina. Deze link staat los van de echte download-link, die direct naar de tarball verwijst. Is lezen en accepteren van de GPL nu een vereiste om op die link te mogen klikken?

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