Open source: te veel vrijheid is ook niet goed

Licenties zijn een redelijk heet hangijzer in de wereld van open source. De bekendste en meest gebruikte licentie is de GPL, de GNU Public License. Deze licentie kan een enorm nadeel hebben, want bij teruggave aan de community kan jouw concurrent weleens de lachende derde zijn. Hoe moet je hiermee omgaan, waar ligt de balans? Onze experts van het topic Open Source aan het woord.

Mylène Reiners, productmanager OSCE/architect, Atos Origin SI Emerging

 

Stel, je gebruikt een programma onder GPL als basis voor je eigen code, die je verder verspreidt, dan moet ook de broncode daarvan beschikbaar gesteld worden. De GPL biedt de de gebruiker van een programma de vrijheden om het te gebruiken voor elk doel, om de manier waarop het werkt te bestuderen en om het aan te passen aan eigen behoeften, om het te verspreiden en om het te verbeteren. Deze vrijheden worden uitgebreid of, afhankelijk van het gezichtspunt van de aanpasser, beperkt door de verplichting dat alles wat gebruikt maakt van code onder de GPL, ook weer onder een gelijke licentie moet worden gebracht. Waarom hier die nadruk op die beperking?

Regelmatig zouden wij bij bedrijven graag open source inzetten. Stel nu dat die open source net niet helemaal doet wat we willen, dan wordt de code aangepast (die vrijheid hebben we immers). Meestal is het geen probleem dat die code dan algemeen beschikbaar komt, maar stel dat het aanpassingen zijn waarvan het bedrijf niet wil dat ze vrijgegeven worden?

Stel dat het een concurrent, of wie dan ook, té veel inzicht zou geven in het intellectueel eigendom van het bedrijf? Dan werken die vrijheden tegen je… Natuurlijk zijn er veel licenties (denk aan MIT, BSD, Apache) die je niet opleggen dat je de code ook weer open source maakt, maar de GPL is de meest gebruikte licentie. Als consultants kunnen we adviseren wat we willen, er is nog steeds veel 'fear, uncertainty, and doubt (FUD)' over het gebruik van open source en het moeten open source maken van alle code, is de belangrijkste angst. Vaak onterecht, maar overtuig een klant maar!

Natuurlijk ligt alles genuanceerder dan ik hierboven stel. Meestal kun je zonder problemen GPL-software gebruiken en voor eigen doeleinden aanpassen, zonder dat iemand daar over valt. Het is alleen verschrikkelijk moeilijk om in de toekomst te kijken en er zeker van te zijn dat (aangepaste) software inderdaad nooit verspreid zal gaan worden. Soms werkt vrijheid tegen je en jammer genoeg ook tegen de acceptatie van (een deel van de) open source in bedrijfskritische toepassingen…

Ron Bloksma, adviseur, Grontmij GIS & ICT

Veel systemen zijn aggregaten van componenten. Componenten worden gecombineerd ingezet over de verschillende software-architectuurlagen. Het gebruik van één GPL open source softwarecomponent in een dergelijke aggregaat, maakt het gehele systeem niet vallend onder de GPL. De inzet van PostgreSQL/PostGIS voor dataopslag maakt het gehele systeem nog geen open source. Een aanpassing in de broncode betreft dan ook alleen het component. Ik vind wel dat bedrijfsgebonden business rules en cijfers niet hard moet coderen. Ik vrees dat de bijdrage van Reiners eerder en onbedoeld bijdraagt aan 'fear, uncertainty and doubt' dan dat die iets wegneemt.

Richard Jansen, ceo, SDB

Ik vind Reiners' bijdrage wel erg gefocused op het niet vrij willen geven van aanpassingen. We gebruiken volop open source in onze projecten en we hoeven niets aan te passen aan Hybernate of Seam of welke andere gebruikte open source-oplossing dan ook. De bedrijfskritische functionaliteit wordt natuurlijk apart gehouden van de tooling die je gebruikt. Als je iets aanpast dan heeft het te maken met de werking van de tool en maak je de tool beter of los je een probleem van de tool op. Wie heeft er dan bezwaar om deze verbetering ook aan anderen beschikbaar te stellen? Daar zit niet de concurrentiegevoelige kennis. Alle functionaliteit die los van en bovenop de open source-tools wordt gebouwd is niet onderdeel van de tool en kun je gewoon in huis houden.

Eric D. Schabell, JBoss solutions architect Benelux, Red Hat

Waar het om gaat is dat GPL meer beperkend is dan je in eerste instantie zouden denken. Alle code die gebruik maakt (libraries, etc.) van GPL-code valt dan ook hieronder. Dit is bekend als 'derivative work'. Consultants zoals Reiners hebben vaak oplossingen voor hun klanten voor ogen waarbij er met behulp van open source producten/libraries worden gebouwd. Hierbij hebben zij de plicht om de 'FUD' zoals beschreven uit de wereld te helpen en hun klanten op te leiden. Zulke mensen staan vooraan in de open source-linies en zijn waarschijnlijk meer waard dan alle 'evangelisten' bij elkaar.

Jan van Leeuwen, zelfstandig ict-consultant, Stajl IT-Consulting

Het gaat in dit geval om de keuze van het 'verdienmodel'. Als je volkomen open source wilt werken moet het geld uit de service komen. Het idee de source deels gesloten te laten, zal niet werken want communities laten zich op die basis nauwelijks vormen. Pas bij volkomen open source zie je communities ontstaan die gezamenlijk ontwikkelen aan een product wat dat product ten goede komt. Daar waar plotseling delen als gesloten verschijnen, wenden zich de leden van de community van het project af en bloedt een project dood. Iedereen kent zulke projecten. Ontwikkelen en dan vrijgeven is voor velen ongewoon, mijns inziens krijg je als bedrijf meer terug als je er in stopt, namelijk een groot eco-systeem van ontwikkelaars voor 'jouw' product.

Martijn Brekhof, docent/consultant, AT Computing

Ik kan me voorstellen dat een bedrijf dat open source-code wil gebruiken in het eigen product dit erg lastig vind met betrekking tot de licentie. De FSF-faq is een handig overzicht wat eventueel nog mogelijk is. Er zijn genoeg voorbeelden van open source-projecten die hun code onder een duale licentie hebben uitgegeven. Een mogelijkheid om bedrijven tegemoet te komen in hun angst voor open source is om de persoon of personen die het auteursrecht hebben op de open source-code te vragen een versie uit te brengen onder een andere licentie, alhoewel hij of zij er niet snel vriendjes mee zal maken.

Siem Korteweg, consultant, QNH

Wanneer GPL-software wordt aangepast en gedistribueerd, vallen de wijzigingen ook onder de GPL. Dat is natuurlijk niet gewenst wanneer deze wijzigingen intellectueel eigendom van een bedrijf bevatten. Wanneer de eigen uitbreidingen volledig gescheiden kunnen worden van de open source-software, de eigen software draait bijvoorbeeld boven op de LAMP-stack, dan kan de eigen software onder een andere licentie afzonderlijk beschikbaar gesteld worden. Stel in deze situatie via een website een kant en klare virtuele machine beschikbaar waarop de software eenvoudig apart te installeren valt.

Deze vlieger gaat niet op wanneer de wijzigingen nauw verweven zijn met de oorspronkelijke software. Wanneer de gewijzigde GPL-software niet aan anderen beschikbaar gesteld wordt, verplicht de GPL niet tot het publiceren van de wijzigingen. De gewijzigde software mag dan natuurlijk alleen intern gebruikt worden. Voor bedrijven die zelf geen betaalde diensten willen opzetten, is dat geen probleem. Nadeel van deze benadering is wel dat nieuwe releases van de open source-software opnieuw integratie en testen vereisen.

Bedrijven die aangepaste GPL-software wel willen gebruiken om betaalde diensten aan te bieden, hebben natuurlijk ook de mogelijkheid om de software als een service (SaaS) aan te bieden. In dat geval wordt de software zelf niet gedistribueerd en hoeven de wijzigingen dus niet beschikbaar gesteld te worden. De klanten van deze diensten hebben ook helemaal geen interesse in de software, ze willen alleen de dienst afnemen.

Henk van Cann, eigenaar, 2Value

Stel je moet de code vrijgeven en stel je concurrenten lopen ermee weg. Hoe erg is dat? Ik zie voordelen: gratis reclame voor de marktleider en aantoonbaar gebrek aan creativiteit van de concurrent. Wie zal een klant kiezen? Juist. Stel je open source-licentie zegt dat vrijgeven moet en je doet het niet, zelfs niet na aandringen. Wie gaat dat handhaven? Hoe vaak is dat in het verleden gebeurd? Hoe staat een partij die het zou gaan afdwingen erop naar de buitenwereld toe? Denk niet dat ook maar iemand deze zeer positieve feature (copy left) van vele open source-licenties in een concurrerende marktsituatie gaat misbruiken.

Stel er zijn onverlaten die meevaren op de golf van een open source-project en dan vervolgens een paar dingetjes eraan vast coderen zonder ze te willen vrijgeven. En dan roepen 'Wij doen Drupal, maar dan beter'. Of 'We're-invented Joomla'. Deze bedrijven worden vanzelf publiekelijk aan de schandpaal genageld. Komt goed. Al met al een theoretische verhandeling van Reiners dus, waarin closed source-leveranciers geen stokpaardje zullen vinden om klanten van open source af te houden.

Morten Minke, implementatiemanager, Business Momentum

Vrijheid brengt ook verantwoordelijkheid met zich mee. Het feit dat er gesteld wordt dat je open source wel wilt gebruiken maar eventuele aanpassingen niet zou willen teruggeven aan de community, geeft aan dat je niet klaar bent om echt met open source te werken. Zoals al veel is gezegd betekent open source gebruiken helemaal niet dat alles wat je zelf maakt ook meteen open source moet worden. Maar het is juist ook de kracht van open source dat als iemand echte aanpassingen maakt, anderen daarvan ook hun voordeel kunnen nemen. Zo draagt iedereen een stuk bij aan de ontwikkeling.

Ik denk dat het vaak voor een eindklant niet moet uitmaken of er open source of closed source wordt gebruikt. De klant wil gewoon kunnen werken. Mocht het toch een issue zijn, dan is goede voorlichting belangrijk. Mijn ervaring leert dat klanten juist ook zeer geïnteresseerd zijn in deze manier van ontwikkelen. Met name als er goed wordt uitgelegd wie onderdeel uitmaakt van de community en dat ook de klant daarin een rol speelt. Hiermee kun je de betrokkenheid vergroten en aangeven dat ook zij invloed kunnen uitoefenen, al dan niet via de leverancier.

Jos Struik, directeur, Dataccent

De afweging die Reiners maakt is absoluut relevant. Het gaat alleen niet om een beperking van open source-software maar een kenmerk. Dat betekent dus dat wanneer je van plan bent om ontwikkelde sofware en de kennis die daarin is opgenomen, commercieel in te zetten, je niet snel zult kiezen voor sofware met een GPL-licentie. Tenzij je je geld wilt/kunt verdienen met kennis en diensten eromheen en niet zo zeer met de softwarelicentie zelf. Je hebt tenslotte gekozen voor open source en die twee woorden zeggen alles al. Hetzelfde geldt andersom: als je je software breed mee wilt uitleveren zonder beperkingen en kosten voor de gebruiker, kies je ook niet voor closed source-componenten.

In mijn ogen is het 'slechts' een afweging die hoort bij de vraag of je ontwikkelde software ook commercieel wilt inzetten en welke tools dan het beste passen. Overigens zou ik zelf meer energie steken in het ontwikkelen van nieuwe, unieke kennis als mijn product de markt in gaat dan het proberen te beschermen. In deze tijd is dat toch bijna onmogelijk.

Albert Mietus, eigenaar/parttime adviseur, SoftwareBeterMaken.nl

Wat is nu het probleem? Het enige probleem dat ik zie is dat het GPL niet 'alles' toestaat. Alsof dat relevant is! Als je software gebruikt, moet je voldoen aan de licentie die de maker gekozen heeft. Soms is dat GPL, maar vaak ook niet. Gebruik je open source-code, en wil je die veranderen, en moet je voldoen aan het GPL, ja dan moet je die verandering vrijgeven.

Reiners spreek over kleine veranderingen. In de praktijk is dat meetal een bugfix of een triviale aanpassing. Los van de juridische verplichtingen, wat is er moreel op tegen om die 'terug te geven' aan de gemeenschap? Het argument van intellectueel eigendom gaat hier echt niet op. Natuurlijk, het kost tijd en geld om die fout te vinden en op te lossen, maar dat is iets anders dan IP. Wel heeft ze gelijk dat 'de conculega's' ook profiteren van die bugfix. Net zoals jullie profiteren van die van anderen. Als je dat onduidelijk, of FUD, vindt, dan snap ik dat echt niet. Dan ben je een profiteur, dan gaat het niet om open source maar om gestolen source. Dat is heel iets anders…