Op mijn blogreeks over software asset management op Computable kreeg ik meerdere reacties van gebruikers, waarbij veelvuldig de term open source viel. 'Gewoon overstappen op open source, dan zijn al je licentieproblemen verleden tijd', was de voornaamste strekking. Ik juich de opkomst van open source absoluut toe, maar hier wil ik toch graag een aantal kanttekeningen bij plaatsen.
Het recente nieuws dat Oracle klanten wil laten betalen voor Java-software (terwijl die klanten denken dat het gratis is), maakt deze discussie nog eens extra actueel. Laat ik vooropstellen: ik ben fan van open source. In onze eigen organisatie proberen we als het kan zoveel mogelijk open source software te gebruiken. En de oplossingen die we zelf ontwikkelen voor klanten maken gebruik van open source software. Maar de stelling dat je met open source software voorgoed ‘verlost’ wordt van licentie-issues klopt simpelweg niet.
Meer dan licenties tellen
Ja, de keuze voor open source betekent over het algemeen dat je bespaart op de licentiekosten. Maar niet alle open source software is in alle gevallen gratis, en als grote organisatie heb je nog wel te maken met supportdiensten en de bijbehorende contracten. Dit is soms optioneel, maar vaak wil je toch iemand kunnen bellen als er problemen zijn (maar soms ook niet als het om een bepaalde versie gaat). Bovendien gaat software asset management over meer dan licenties tellen. Het doel is te weten welke software je in huis hebt, wat je daarmee mag, welke software er in je organisaties precies gebruikt wordt, wat je daar mee doet en hoeveel je precies uitgeeft. En dat is ook bij open source software belangrijk.
Het ontstaan van open source software
Even een korte achtergrond over het ontstaan van open source software vanuit de licentiekant, zodat we allemaal hetzelfde startpunt hebben. Open source software bestaat al sinds de jaren zeventig. Er werd toen software geschreven (zoals Tiny Basic) die werd gepubliceerd en door iedereen gebruikt en veranderd mocht worden. In deze software werd de term ‘copyleft’ als knipoog op ‘copyright’ gebruikt – net als de term ‘all wrongs reserved’ (zie afbeelding). Om te voorkomen dat anderen de code voor commerciële doeleinden gingen gebruiken werd er een licentie bedacht. De eerste die een licentieovereenkomst publiek maakte, was Richard Stallman met zijn GNU General Public License. Inmiddels zijn er allerlei alternatieve licentieovereenkomsten beschikbaar en hebben sommige commerciële bedrijven een eigen, vaak minder vrije, versie van de GNU licentie gemaakt.
Omgekeerde copyright
Copyright wordt gebruikt door een auteur/programmeur om te voorkomen dat anderen de code reproduceren, aanpassen of distribueren zonder zijn of haar toestemming. Bij open source software wordt ditzelfde recht gebruikt om het tegenovergestelde te doen: je mag juist wél de software reproduceren, aanpassen en distribueren. Echter zijn er vaak ook andere voorwaarden aan toegevoegd. Het zijn juist deze voorwaarden waar je van op de hoogte moet zijn en die wel degelijk ‘management’ nodig hebben. Verder vinden veel programmeurs het gaaf om ‘gratis’ code maken, maar vinden ze het minder leuk als anderen daar weer geld mee verdienen. En ook voor hen geldt dat er uiteindelijk geld verdiend moet worden.
Dit alles heeft een aantal consequenties, waarbij ik het onderscheid wil maken tussen drie belangrijke aandachtspunten.
Ook bij open source zijn er verplichtingen
In de basis is open source niet meer dan een stukje code die iedereen vrij mag gebruiken. Behálve als je het voor commerciële doeleinden wilt inzetten. De eigenaar van de code bepaalt dan wat je er als gebruiker mee mag doen. Je mag het bijvoorbeeld helemaal nooit commercieel inzetten of niet als commercieel product verpakken en doorverkopen. Of het mag wel, maar dan is er veel gevallen wel gewoon een licentieovereenkomst.
Die overeenkomst is niet het resultaat van contractonderhandelingen, zoals bij de meeste softwareleveranciers: je downloadt hem gewoon mee met de software. In die overeenkomst staan net zo goed voorwaarden en regels waar je je aan moet houden. Vaak niet zoveel en minder ingewikkeld dan de enterprise contracten bij grote leveranciers, maar ze zijn er wel degelijk. En dat is maar goed ook, omdat het anders voor ontwikkelaars heel moeilijk wordt een boterham op de plank te krijgen. De Boston University heeft daarom een standaard licentieovereenkomst opgesteld die open source developers kunnen gebruiken. En op opensource.org staan tientallen voorbeelden van hoe ontwikkelaars hun software kunnen licenseren. Let wel op: niet al deze voorbeelden geven dezelfde vrijheid.
Geld wordt verdiend met ondersteunende diensten
Toch blijft de open source software zelf in veel gevallen gratis, ook voor bedrijven. Afgedwongen door degene die de originele code heeft gemaakt, vaak uit ideologische redenen. Linux is een goed voorbeeld van open source software die in de enterprise markt echt een voet aan de grond heeft gekregen, maar nog steeds gratis is. Het geld wordt verdiend met ondersteunende Linux-diensten, bijvoorbeeld door partijen als Red Hat.
Zij leveren een compleet Linux-pakket met software en support. Je hebt als bedrijf dan geen gebruikslicenties, maar wel onderhoudscontracten. Die contracten zijn gelieerd aan het aantal installaties van de software in de organisatie, je betaalt per installatie. De belangrijkste taak van een SAM-manager – het in kaart brengen van wat je hebt en wie wat gebruikt – is dus nog steeds relevant in deze situatie. En Red Hat controleert natuurlijk wel of je betaalt waarvoor je moet betalen, net zoals bijvoorbeeld Oracle dat doet voor haar eigen open source producten.
Er zijn vaak verschillende versies
Door overnames zijn er vaak ook verschillende versies van een open source product op de markt. Neem MySQL, Java of Sun OS, die alle drie in handen zijn van Oracle. De oude, originele versie blijft meestal gratis, want dat was nou eenmaal zo afgesproken, maar vanaf een bepaalde nieuwe release zijn de voorwaarden veranderd en moet er gewoon voor de software betaald worden. Daarvan zijn nu twee versies te krijgen – een gratis variant en een betaalde – met ieder hun eigen voorwaarden. Als bedrijf is het uiteraard goed om te weten welke versie je hebt. En als je de gratis variant hebt, is het goed om te beseffen dat deze verder niet ontwikkeld wordt en dat er vaak ook geen support op wordt geboden.
Geen regelloze vrijstaat – gelukkig
Mijn enthousiasme over open source blijft onverminderd groot. Als de open source-variant minimaal zo goed is als een closed source-product, raad ik bedrijven vanuit kostenoogpunt dan ook vaak aan daarvoor te kiezen. Wel benadruk ik daarbij dat er net zo goed verplichtingen en contractuele voorwaarden bij komen kijken. Open source is geen regelloze vrijstaat. Gelukkig maar! Anders zou iedereen zomaar Linux kunnen gaan verkopen en er geld mee kunnen gaan verdienen.
Bovendien staat de keuze voor open source software voor mij los van de discussie over software asset management. Dat blijft namelijk altijd belangrijk voor grote organisaties, of het nu gaat om open source, SaaS of on-premise software. Ten eerste omdat corporates nu eenmaal een complexe infrastructuur hebben, waar die verschillende soorten software allemaal worden gebruikt. Ten tweede omdat je als SAM-manager altijd inzicht wil hebben in het bezit, het gebruik en de kosten van software.
Vragen of opmerkingen? Ik hoor ze graag!
Beste Marc,
Bedankt voor je stuk. Inderdaad, let op welke Open Source licentie “variant” je kiest.
De essentie die je echter in mijn ogen een beetje mist, is dat Open Source software geen zogeheten Verdor Lock-in veroorzaakt. En dat laatste is precies hetgeen waar bedrijven zoals Oracle hun garen bij spinnen.
Wil je bijvoorbeeld afscheid nemen van bijvoorbeeld Red Hat, kun je schakelen naar bijvoorbeeld CentOS. Vervolgens ben je vrij daar zelf een firma bij zoeken die support diensten kan leveren. Je zit dus niet vast (lock-in) aan een bepaalde leverancier.
Het voordeel van software met een Open Source licentie, is dat gebruikers altijd vrij zijn om de ontwikkeling van deze software te continueren in een fork. ( MySQL > MariaDB, Open Office > Libre Office, SugarCRM > SuiteCRM. enz.). Wederom; geen vendor lock-in.
Nog een laatste opmerking; Open Source licenties mogen uiteraard ook commerciële doeleinden gebruikt worden, bijvoorbeeld als bouwstenen in je zakelijke software stack. Verander je de code van de software zelf, dan dien je de code open te houden. Waarschijnlijk bedoel je dat ook, maar zo lees ik het niet helemaal.
Hartelijke groet,
Coen Hamers
Beste Coen,
Dank voor je reactie. Het is inderdaad een voordeel dat er een stuk minder kans is op vendor lock-in. Echter bij de insteek van het stuk heb ik bewust gekozen om alleen naar de licentie kant te kijken. Dit voornamelijk omdat daar mijn kennis ligt en ook om uit discussies omtrent dergelijke voordelen te blijven. Hier over verschillen de meningen nog al, zeker per product/vendor.
Als het gaat om gebruik voor commerciële doeleinden; Het is inderdaad zo dat veel Open Source software producten wel als onderdeel in een andere (commerciële) oplossing gebruikt mogen worden of, vergelijkbaar, in een commerciële omgeving, maar zeker niet alle. Dat hangt af van de overeenkomst en op dit thema bestaan er steeds meer varianten. Wij zullen het klanten niet aanbevelen om er blind van uit te gaan, zonder dit uit de geassocieerde voorwaarden te halen. Het is een kleine moeite die zich vaak snel terug betaald mochten er toch “afwijkende” voorwaarden zijn.
Gegroet, Mark.
Als ook partijen zoals Oracle en Microsoft diverse software in open-source varianten uitbrengen geeft al aan dat het licentietechnisch volwassen is om er toch een verdienmodel mee te kunnen realiseren. Dat laatste is een belangrijke factor in de continuïteit en stabiliteit.
Een herkenbaar verhaal over een onderwerp waar ik een jaartje geleden ook heel intensief mee bezig heb gehouden.
De grootste uitdagingen die ik tegengekomen ben;
– bewustwording creëren bij ontwikkelaars dat de ene open source licentie niet de andere is
– overzicht krijgen wat er nu allemaal gebruikt wordt in je product
– helder krijgen wat per licentie nu de verplichting is
De kosten van open source software zijn dan misschien minder dan die van commerciële/closed source software, maar het (correct) beheren ervan is zeker niet goedkoper.