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. 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 vier vrijheden:
1. om het te gebruiken voor elk doel;
2. om de manier waarop het werkt te bestuderen en om het aan te passen aan eigen behoeften;
3. om het te verspreiden;
4. 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…
Beste Mylène,
Wellicht snap ik het verhaal niet, maar gezien de reacties ben ik dan niet de enige. Samengevat kom het er volgens mij op neer dat open-source “eng” zou zijn, omdat je de code kan veranderen. Wat je ook ziet als voordeel…
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. Gezien het aantals en’s, hoeft dat dus vaak niet!
Maar Mylène, je spreek over kleine veranderingen. In 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 heb je gelijk dat “de conculega” ook profiteren van die bugfix. Net zo als jullie profiteren van die van anderen. Als je dat onduidelijk, of FUD, vindt dan snap ik het echt niet. Dan ben ik met anderen eens dat je een profiteur wil zijn; dan gaat het niet om open-source maar om gestolen-source. Dat is heel iets anders …
Waar het om gaat is GPL is meer beperkend dan je in eerste instantie zouden denken; alle code die gebruik maakt (libraries, enz) van GPL code valt dan ook hieronder. Dit is bekend als ‘derivative work.’
Consultants zoals Mylene hebben vaak oplossing 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 zijn voor aan in de Open Source linies en zijn waarschijnlijk meer waard dan alle ‘evangelisten’ bij elkaar!
Het is handig om bij het aanduiden van mogelijke problemen, ook oplossingen te noemen. Anders werk je FUD ongewild in de hand.
Het aanpassen van generieke derden software (open – of closed source) is meestal niet nodig. Soms wel, maar bedrijfsgevoelige informatie in programmacode hard vastleggen is – zoals gezegd – niet erg handig. Het onderhoud van de software kost dan meer werk en je moet ook nog eens meer bedrijfsgevoelige informatie met softwareontwikkelaars delen.
Wil je toch quick-and-dirty werken, dan kan je ook open source gebruiken met een andere licentievorm dan GPL. Verder kan je ook vrije software en eigendomsmatige (proprietary) software combineren (mixed source).
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 OSS, 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 OSS 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.
Goede aanvullingen Siem.
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 terug geven aan de community, dat je in zo’n geval niet klaar bent om echt met Open Source te werken.
Zoals al veel is gezegd betekend 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 eind klant 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 geinteresseerd zijn in deze manier van ontwikkelen. Met name als er goed wordt uitgelegt 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.
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 Communities laten zich op die basis nauwelijks vormen. Pas bij een volkomen open source zie je communities onstaan die gezamelijk ontwikkelen aan een produkt wat dat produkt ten goede komt.
Daar waar plotseling delen als gesloten verschijnen wenden zich de leden van de community van het projekt af en bloedt een projekt dood, iedereen kent zulke projekten.
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” produkt.
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 geheel 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 die component. Daarbij ben ik het geheel met John eens: bedrijfsgebonden business rules en cijfers codeer je niet hard. Ik vrees dat de opinie van Mylène eerder en onbedoeld bijdraagt aan ‘fear, uncertainty and doubt’ dan die wegneemt
We vergeten voor het gemak dat de essentie van een organisatie meestal niet ligt in één onderdeel van de ICT afdeling. Sec een stukje software kopiëren wil niet zeggen dat daarmee de marktaanpak, klantrelaties, het merk en het vertrouwen kan worden gekopieerd.
Er zijn vast wel uitzonderingen te bedenken waarbij de component wel een essentieel competatief voordeel oplevert, maar in mijn optiek is het meer een emotie dan dat we dat hard meetbaar kunnen maken. In de 7 jaar dat wij voor klanten maatwerk op Open Source hebben gerealiseerd zijn er maar heel weinig situaties waarbij in mijn optiek het maatwerk echt zo essentieel is dat uitlekken een bedreiging zou vormen.
Overigens staan de veel licentievormen toe dat de maatwerk aanpassingen die voor eigen gebruik zijn gedaan niet gepubliceerd worden.