Commercieel gebruik van Open Source

Als Open Source dienstverlener kom je nog wel eens voor verrassingen te staan. Het merendeel van de commerciële software die wij maken leunt op Open Source bibliotheken. Dit stelt ons in staat om sneller en beter software te maken. Echter, Open Source is niet zonder verplichtingen. Bijna alle Open Source bibliotheken hebben een licentie in één of andere vorm. De voorwaarden in deze licentie moeten worden nagekomen anders is er kans op juridische problemen.

Laat ik een voorbeeld geven:

Meestal is het een resultaatgerichte ziel die ‘even’ een bibliotheek downloadt om snel een stuk functionaliteit te realiseren. Uiteraard wordt er op zo een moment niet gekeken naar de licentie. Dat komt pas véél later. De functionaliteit is gereed en geïntegreerd in het eind product, klaar voor oplevering. Pas dan ontdekt de projectverantwoordelijke dat deze bibliotheek de gebruiker verplicht om ook zijn source code vrij te geven. Dat is natuurlijk niet de bedoeling van duurbetaalde maatwerk software. De bibliotheek in kwestie wordt geschrapt en de functionaliteit moet opnieuw worden geïmplementeerd, uiteraard met de nodige vertraging tot gevolg.

In het bovenstaande scenario kwam men er net op tijd achter. Als dat niet was gebeurd had de eigenaar later voor verrassingen kunnen komen te staan. Bekende bedrijven die een soortgelijke situatie al een keer hebben meegemaakt zijn onder andere Asus, TomTom en D-Link.

Inventarisatie

Beter is het natuurlijk om al tijdens het bouwen van de software te weten welke bibliotheken en welke licenties er gebruikt worden. In onze ontwikkelstraat gebruiken we Apache Maven voor bibliotheek management. In Maven zitten verschillende rapportages waaronder het “project-info dependencies rapport”. Dit rapport heeft een aparte sectie waarin alle gebruikte licenties staan. Maar wat houden die licenties precies in?

De tekstuele inhoud van de licenties zijn vrij eenvoudig te vinden op internet. Echter, de inhoud is juridisch geformuleerd. Dat maakt het er niet eenvoudiger op. Globaal kan je de licenties indelen in twee soorten. Ten eerste licenties die vereisen dat je eigen source code ook beschikbaar maakt voor iedereen die de software gebruikt of heeft. De term 'virale' licenties wordt wel eens gebruikt in deze context. Ten tweede licenties die dit soort eisen niet stellen. Deze licenties worden de ‘permissive licenses’ genoemd.

GPL en AGPL

De bekendste Open Source licentie, de GNU General Public License, kortweg GPL, is een voorbeeld van een licentie die vereist dat je eigen source ook beschikbaar maakt.

Dat klinkt vrij drastisch en je zou bijna gaan denken dat het gebruik van GPL database drivers zoals die van MySQL in een private applicatie inhoudt dat ook daarvan de source code publiek gemaakt moet worden. Gelukkig is dat niet altijd zo. Deze blogposting vertelt over twee interessante uitzonderingen.

De eerste uitzondering betreft applicaties die privé of binnen een bedrijf worden gebruikt en niet daarbuiten. De applicatie wordt dus niet aan derden geleverd en dus is de verplichting om de source code ter beschikbaar te stellen niet van toepassing. Dit geldt ook voor publieke web-applicaties waarbij de uitvoerbare code privaat op de server blijft en alleen de gebruikersinterface door middel van HTML getoond wordt. Uiteraard blijft het onmogelijk om de software aan derden beschikbaar te stellen zonder de source code.

De tweede uitzondering kan gemaakt worden op het moment dat de applicatie in kwestie ook prima functioneert zonder de, of met een andere vergelijkbare, bibliotheek in kwestie en de gebruiker van de applicatie deze zelf moet installeren. In het voorbeeld van hiervoor communiceert de web applicatie zeer waarschijnlijk via de JDBC (Java Database Connectivity) API met de MySQL driver. JDBC maakt het mogelijk om op een uniforme manier met databases te communiceren zonder gebruik van bibliotheek specifieke functies. Op deze manier kan de applicatie dus onafhankelijk zijn van specifieke GPL bibliotheken en kan het als gesloten source product geleverd worden aan derden.

Als reactie op de eerste, door sommigen een gat in GPL genoemde, mogelijkheid is er een nieuwe licentie in het leven geroepen die voorkomt dat web applicaties hun source code voor zichzelf kunnen houden:

De GNU Affero GPL (AGPL) stelt wanneer de gebruikers interface of de resultaten van de bibliotheek publiekelijk toegankelijk zijn (zoals bijvoorbeeld bij een web-applicatie op het internet) diezelfde server ook de source code van de applicatie moet aanbieden als download. Een recent voorbeeld van een bibliotheek die deze licentie is gaan gebruiken is iText PDF. Sinds versie 5.0 valt deze bibliotheek onder de AGPL.

Deze licentievorm kan in een publieke commerciële omgeving niet gebruikt worden, tenzij er een commerciële licentie voor wordt aangeschaft.

Meervoudig licentiëren

Als auteur van een software bibliotheek mag je kiezen onder welke licentie je werk beschikbaar stelt aan anderen. Dat kan een Open Source licentie zijn, een commerciële maar ook verscheidene tegelijkertijd. Waarom zou je dat willen? Treed binnen in de wereld van het meervoudig licentiëren.

In zijn algemeenheid zijn er twee redenen om een software bibliotheek te voorzien van een meervoudige licentie. De eerste is licentie compatibiliteit. Dat wil zeggen, bepaalde voorwaarden in de licenties maken het onmogelijk om twee bibliotheken te combineren tot een nieuw product en het resultaat te publiceren. Een voorbeeld is een combinatie van GPL en de Mozilla Public License (MPL). De MPL stelt dat de licentie van een afgeleid werk geen extra beperkingen mag hebben. De GPL legt wel extra beperkingen op en dus kunnen de twee niet gecombineerd worden in één product.

Wanneer de auteur wil dat zijn bibliotheek zo breed mogelijk gebruikt kan worden én de beschikbaarheid van de broncode zoveel mogelijk wil garanderen zal hij de gebruikers de keuze geven uit een aantal sterke Open Source licenties. Bijvoorbeeld de Firefox browser is beschikbaar onder de MPL, GPL en LGPL licenties. Wil de auteur slechts dat zijn bibliotheek zo breed mogelijk gebruikt kan worden dan is het eenvoudiger om voor een licentie vorm te kiezen die ook commercieel gebruik toestaat, zoals de Apache 2.0 licentie of de MIT licentie. Licenties zoals deze zijn vaak compatibel met sterke Open Source licenties omdat ze weinig voorwaarden stellen.

Een tweede reden om meervoudig te licentiëren is een commerciële. Hierbij wordt de bibliotheek aangeboden onder een sterke Open Source licentie (zoals de Affero GPL of GPL) en onder een commerciële licentie. Iedereen is hierbij vrij om de bibliotheek uit te proberen maar zodra er commercieel gebruik van gemaakt gaat worden moet een commerciële licentie worden aangeschaft. De iText bibliotheek voor het genereren van PDF files hanteert deze vorm bijvoorbeeld.

Uit het bovenstaande blijkt dat Open Source licenties in verschillende mate beschikbaarheid van bron code afdwingen en dat sterke Open Source licenties gebruikt kunnen worden om geïnteresseerde private partijen een commerciële licentie te laten kopen. Wellicht is het interessant om een overzicht te maken van een aantal bekende licenties en daarbij aan te geven hoe en in welke mate ze sterk zijn. Interessant materiaal voor een volgende posting!

De belangrijkste open source licenties

Als een Open Source Bibliotheek gebruikt wordt in een commercieel product moet er goed worden opgelet dat de licentie van die bibliotheek commercieel gebruik niet onmogelijk maakt door te eisen dat de source code van het product wordt vrijgegeven. In deze blogposting bespreek ik een aantal veel voorkomende licenties en de consequenties voor commercieel gebruik.

Affero GPL – dit is de sterkste open source licentie van het moment. Wanneer iemand toegang heeft tot een product waarin deze software gebruikt wordt moet de source code van het geheel ook tot die persoon ter beschikking staan. Niet geschikt voor publieke commerciële toepassingen. Neem een commerciële licentie.

GPL – Dit is een sterke open source licentie. In principe is deze software niet bruikbaar voor commerciële toepassingen, tenzij je de software niet distribueert aan derden. Meer details staan hierboven beschreven.

LGPL – Deze licentie staat commercieel gebruik toe, mits het de gebruikers wordt toegestaan een nieuwere versie van deze bibliotheek te gebruiken. Dit impliceert dat het zogenaamde reverse engineeren niet kan worden verboden in licentie voorwaarden van het product. Als er aanpassingen gemaakt worden in de LGPL broncode moet deze, bij publicatie van het product, aan derden beschikbaar gesteld worden. Dit betekent ook dat bij het gebruik in frontend projecten, waarbij de broncode ingedikt en samengevoegd wordt, deze licentie problematisch is. De Mozilla Public License (MPL) heeft soortgelijke implicaties.

Apache Licentie – Deze licentie staat commercieel gebruik ook toe, mits de originele copyright vermeldingen in de source code in takt blijven en bij ieder afgeleid werk expliciet wordt vermeld dat het software van de Apache stichting bevat (hetzij in de handleiding, als tekst op het scherm of in een apart bestand).

MIT – Dit is een permissive licentie die voor commercieel gebruik geschikt is. De enige conditie is dat de copyrightvermelding in de bron code onveranderd blijft. Dit is vooral belangrijk bij software waarbij de bron code gelijk ook de uitvoerbare code is, bijvoorbeeld bij scripttalen zoals JavaScript. De bekende bibliotheek jQuery maakt (onder andere) gebruik van deze licentie. De MIT licentie is vergelijkbaar met BSD en ISC licenties.

Creative Commons (CC) Licenties – Deze licenties zijn eigenlijk niet bedoeld voor software maar voor media zoals tekst, beeld en geluid. Echter het komt voor dat ook software op deze manier gelicentieerd wordt. In dat geval is het belangrijk te weten dat alleen CC-BY acceptabel is voor commercieel gebruik, mits de auteur vermeld wordt in het uiteindelijke product. CC-BY-SA niet, omdat SA – Share Alike – betekent dat een afgeleid werk onder dezelfde condities beschikbaar gesteld moet worden.

Samenvattend zijn veel open source bibliotheken goed te gebruiken in commerciële projecten. De eisen die ze stellen aan gebruik zijn bescheiden en eenvoudig aan te voldoen. Enkel voor bibliotheken die een GPL en Affero GPL licentie hebben kan beter een commerciële licentie aangeschaft worden. Pas op met software die een Creative Commons licentie heeft.