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