Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

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

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3196115). © Jaarbeurs IT Media.
?

 

Reacties

Ik vermoed dat in 9 van de 10 cases waar open source wordt gebruikt, de broncode niet wordt aangepast. Zolang dat niet gebeurt, is de verplichting om wijzigingen te publiceren, geen enkel probleem. Ik werk al jaren in omgevingen waar Java, Tomcat en PostgreSQL wordt gebruikt, ik heb nog nooit gezien dat men code van deze producten ging aanpassen. Ik denk dat de vraag "gaan we broncode aanpassen?" de belangrijkste vraag is bij de discussie over open source licenties.

"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."
Dan doe je toch _dan pas_ de code erbij? En anders pas je de code gewoon zo aan dat ie geschikt is voor publicatie.

"... té veel inzicht zou geven in het intellectueel eigendom van het bedrijf?"
Is dus niet nodig, als je de software alleen intern gebruikt. Je hoeft geen code naar buiten te brengen. Tenzij natuurlijk een netwerkbeheerder de code van de programmeur kopieert - maar dat kan evengoed gebeuren bij Closed Source. En daar is de schade dan waarschijnlijk groter, omdat programmeurs van Closed Source er meer/vaker vanuit gaan dat toch niemand de code in zal (kunnen) zien.

Zit je te Open Sourceren, dan speelt toch in je (al dan niet onbewust) achterhoofd mee dat iedereen mee kan kijken. (Ook al komt 't er daar nooit van.) Voordeel is ook dat je dan automatisch netter gaat programmeren en geen malware zult inbouwen.

>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).<

Precies, en de vrijheid die jij níet hebt is om die GPL-based code verborgen te houden voor jouw *klant*.

Het kan enkel een probleem vormen indien die klant de software gaat verkopen, want dan moeten ze de code meeleveren. Indien de software enkel in-house ingezet wordt, dan kan er nooit een probleem zijn.

Je mag die software zelf verkopen als iedereen, je moet wel de code meeleveren, of gemakkelijk beschikbaar stellen.

>maar de GPL is de meest gebruikte licentie.
en dat is niet toevallig, de ontwikkelaars willen voorkomen dat broncode kan worden achtergehouden voor gebruikers van hun software.

Conclusie: wil je proprietary license-software op de markt brengen, dan is "parasiteren" op GPL-code niet toegestaan (bij BSD/MIT wel)

Is de software echter gewoon voor intern gebruik, dan ben je nooit verplicht om iets te open sourcen.

Open source != GPL.

Er zijn voldoende alternatieve open source licenties die gebruikers niet verplichten hun in-house ontwikkelde aanpassingen vrij te geven. De BSD licentie is daar een bekend voorbeeld van.

De diverse op BSD UNIX gebaseerde operating systems zoals FreeBSD, NetBSD en OpenBSD maken daar al jaren succesvol gebruik van. Bedrijven als Juniper, Apple etc gebruiken BSD-licensed code in hun producten.

Is dat parasiteren? Dat moet iedereen voor zichzelf uitmaken denk ik.

Wonderlijk verhaal van een productmanager/consultant. Ik begrijp wel de goede bedoeling, maar die komt er niet goed uit. Zo worden potentiële problemen gekoppeld aan open source, ook al gelden die ook voor closed source. Verbeteringen van closed source bij een klant worden bijvoorbeeld vaak meegenomen in volgende releases waar iedereen van kan profiteren. Bedrijven lijken immers heel veel op hun concurrenten. Al die aanpassingen kosten veel geld en die kan je beter delen. De medewerkers bepalen het bedrijf, niet de software.

Er zijn natuurlijk echte bedrijfsgeheimen, maar bedrijfsgebonden business rules en cijfers dienen niet hard in software vastgelegd te worden. Elke maatwerkaanpassing moet ook beoordeeld worden op efficiëntie. Anders krijg je bijvoorbeeld van die BI- of ERP-projecten die financieel volledig uit de hand lopen door de vele specifieke detailaanpassingen.

Jammer dat voor de hand liggende oplossingen niet altijd genoemd worden.

Wat een Marietje, zeg die expert.

Bangmakerij (welk Intellectueel Eigendom leg je nu echt vast in code?) ipv het idee achter de licentie uitleggen.

En als je je zorgen maakt over het vastleggen van IE in de code en het als bedrijf niet snapt en dus een licentie wilt kopen, dan kan dit bij de meeste OS producten door de Enterprise editie aan te schaffen (dan vervalt deze plicht).

De afweging die gemaakt wordt in het artikel 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.

Ik kan me voorstellen dat een bedrijf dat open source code wilt gebruiken in hun eigen product het erg lastig vind met betrekking tot de licentie.
De FSF faq (http://www.fsf.org/licensing/licenses/gpl-faq.html) 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.
(http://www.fsf.org/licensing/licenses/gpl-faq.html#HeardOtherLicense)
Alhoewel hij of zij er niet snel vriendjes mee zal maken (http://www.fsf.org/licensing/licenses/gpl-faq.html#DeveloperViolate).

Een geslaagd artikel om reacties los te krijgen, laten we dat voorop stellen. Dat aan de inhoud heel wat te verbeteren valt is in het bovenstaande al voldoende aangehaald. Bangmakerij of kern van waarheid, ik wil op 2 punten een paar "wat-als" vragen aan de reacties toevoegen:


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 markt situatie 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 Mylene dus, waarin closed source leveranciers geen stokpaardje zullen vinden om klanten van open source af te houden.

Ik vind het 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 opensource tools wordt gebouwt is niet onderdeel van de tool en kun je gewoon in huis houden.

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.

Expert
Mylene  Reiners

Mylene Reiners
Productmanager OSCE, Architect, Atos. Expert van voor het topic .
Hele profiel

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×