Mixen van open en gesloten software
De afgelopen jaren is de hoeveelheid software in producten dramatisch toegenomen. Niet alleen bevatten apparaten steeds meer software, ook wordt een steeds groter deel van de functionaliteit met software gerealiseerd. Deze explosieve groei zorgt voor een grote toename van de kosten van software-ontwikkeling. Het op de juiste plek gebruiken van open source kan grote kostenbesparingen en een snellere doorlooptijd opleveren.
Dit vereist wel een zorgvuldig ontwerp van de software-architectuur en een goede samenwerking tussen de betrokken ontwikkelaars en juristen.
Inhoudsopgave
Open Source
Open source is een ontwikkelmodel voor software waarbij de broncode vrijelijk gedeeld wordt. Iedereen krijgt het recht deze aan te passen en de software in gewijzigde vorm te verspreiden. Het is de bedoeling dat wijzigingen teruggegeven worden aan de oorspronkelijke auteurs, al is dit niet verplicht. Bekende voorbeelden van open source zijn het Linux-besturingssysteem, de Firefox webbrowser en de Apache webserver.
Open source licenties
Deze rechten zijn vastgelegd in de open source licenties. Naast rechten leggen deze licenties gebruikers ook bepaalde verplichtingen op. Zo is het vaak verplicht om wijzigingen of verbeteringen ook als open source beschikbaar te stellen. Afhankelijk van de software-architectuur kan dat betekenen dat de gehele stack van een product als open source moet worden gepubliceerd.
Veel bedrijven zien deze eis als een risico en proberen daarom het gebruik van open source zoveel mogelijk te vermijden. Dit is tegenwoordig echter geen realistische optie meer. Het gebruik van open source in commerciële producten wordt steeds populairder. Open source negeren betekent dat een bedrijf zichzelf de toegang ontzegt tot software van hoge kwaliteit zonder licentiekosten. Het gevolg is vertragingen en duurdere producten ten opzichte van de concurrent. Soms is het commercieel simpelweg niet haalbaar om "bij te blijven" bij een open source concurrent voor een zelf ontwikkeld stuk software. De enige optie is dus met de risico's leren omgaan.
Licentievormen
Er zijn ongeveer 40 verschillende open source licenties met elk hun eigen regels en voorwaarden. Deze kunnen worden onderverdeeld in drie categorieën:
- Free-for-all ("vrijheid, blijheid") licenties: deze licenties stellen als enige eis dat de auteur(s) worden genoemd. Verder zijn er geen verplichtingen. Voorbeelden zijn de zogeheten BSD en MIT licenties. De Apache webserver wordt bijvoorbeeld onder een dergelijke licentie uitgebracht.
- Keep-open ("openhouden") licenties: deze licenties eisen dat wijzigingen aan de software ook als open source worden gepubliceerd. Software waarin deze software wordt verwerkt, hoeft daarentegen niet als geheel als open source te worden uitgebracht. Linux-systeembibliotheken en de Firefox webbrowser worden onder dergelijke licenties aangeboden.
- Share-alike ("samen delen") licenties: deze licenties eisen dat zowel wijzigingen als uitbreidingen als open source worden gepubliceerd. Het bekendste voorbeeld is de GPL, die bijvoorbeeld van toepassing is op Linux.
Het lijkt nu voor de hand te liggen om alleen het gebruik van free-for-all open source toe te staan, en de andere twee vormen buiten te sluiten of aan strenge regels te onderwerpen. Echter, op ongeveer 65% van alle open source is de GPL van toepassing, terwijl slechts ongeveer 15 procent onder een free-for-all licentie beschikbaar is. Wie gebruik wil maken van open source, kan dus niet om share-alike en keep-open licenties heen. Goede regels zijn nodig, maar deze moeten gaan over waar en niet of open source mag worden gebruikt.
Waar open source
Vaak is de beslissing om open source te gebruiken puur zwart/wit: een product wordt volledig open source of gebruikt het juist helemaal niet. Het is veel slimmer om alleen voor bepaalde features open source te gebruiken. De overige ("gesloten") features worden dan zelf ontwikkeld of ingekocht bij een derde. Met andere woorden, de klassieke vraag "maken of kopen?" moet worden "maken, kopen of open source?"
Het product moet uiteindelijk natuurlijk de meeste waarde voor de klant bieden. De keuze voor open of gesloten software moet dus afhangen van de vraag wat het meeste waarde oplevert.
Waarde van software
Waarde kan op verschillende manieren worden verkregen. Een stuk software kan een product uniek maken ten opzichte van de concurrent. Ook kan software commercieel worden gelicentieerd, bijvoorbeeld als een bibliotheek of embedded in een chip. Deze software moet dan uiteraard niet als open source worden gepubliceerd. In deze gevallen moet wel worden geïnvesteerd in ontwikkeling en onderhoud van de software.
Software uitbrengen als open source levert waarde op in de besparing van deze kosten. Bovendien is een bedrijf nu niet langer afhankelijk van één enkele leverancier voor de software in kwestie. Zelf ontwikkelde software kan als open source worden uitgebracht, waardoor onderhoud en ontwikkeling niet langer alleen binnen het bedrijf zelf plaatsvindt. Er is nu alleen geen mogelijkheid meer om geld te verdienen door de software te licentiëren, en alle concurrenten kunnen deze software nu ook gebruiken.
Commoditize your complement
De vraag is nu dus hoe de balans op te maken. Hierbij helpt een oude regel uit de economie: commoditize the complement of your product. Veel producten worden pas nuttig in combinatie met een complement. Zo zal een digitale muziekspeler pas interessant worden als muziek digitaal verkrijgbaar is. Door nu te zorgen dat digitale muziek op grote schaal verkrijgbaar wordt, zal de verkoop van digitale spelers toenemen. Het is dus in het belang van fabrikanten van digitale muziekspelers om te zorgen dat zoveel mogelijk digitale muziek te koop is.
Dit geldt niet alleen voor producten als geheel, maar ook voor features van een product. Dit gaat met name op voor features die complementair zijn aan de differentiërende of unique selling points van het het product. De differentiërende features zorgen er voor dat de klant het product wil kopen. De andere, complementaire features zijn nodig om deze differentiërende features te laten werken. Een digitale televisie kan de unieke feature hebben dat het automatisch samenvattingen van 30 seconden kan laten zien van opgenomen televisieprogramma's. Hiervoor is de feature van het kunnen opnemen van digitale programma.s noodzakelijk. Deze feature is dus complementair aan de automatische samenvatter.
Open source voor complementaire features
Open source is in principe geschikt voor complementaire features. Immers, het gemakkelijker en breder beschikbaar komen hiervan is in het belang van de makers van differentiërende features. Zij kunnen dan daarop voortbouwen met hun unieke producten.
Het gaat echter te ver om alle features te classificeren als complementair of differentiërend en daarna alle niet-differentiërende features met open source te implementeren. Sommige features zijn niet differentiërend maar vertegenwoordigen toch waarde omdat ze gesloten zijn. Een standaard software-bibliotheek is niet differentiërend, maar als deze voor geld wordt gelicentieerd aan derden, wordt deze inkomstenstroom stopgezet wanneer de bibliotheek als open source wordt uitgebracht.
Feature-categorieën
Een onderverdeling in differentiërend en niet-differentiërend is dus te grof. Software-features kunnen daarom beter in drie categorieën worden onderverdeeld:
- Differentiator: voegt waarde toe aan het product, biedt een reden om het product te kopen. Ook wel unique selling point of USP.
- Basis: voegt geen waarde toe, maar is wel nodig omdat de koper het verwacht. Niemand koopt een digitale muziekspeler die geen MP3 bestanden kan afspelen. Ondersteuning van MP3 maakt het product niet uniek, maar is wel een noodzaak.
- Commodity: is noodzakelijk om het product te laten werken, maar voegt geen waarde toe en de koper is er niet in geïnteresseerd.
Figuur 1: De maak/koop/open source-beslissing
De klassieke vraag bij elke feature is "maken of kopen?" Zoals hierboven betoogd, moet die vraag eigenlijk zijn "maken, kopen of open source?" Met deze onderverdeling is het mogelijk hier een zinvol antwoord op te geven. Dit wordt grafisch geïllustreerd in figuur 1.
Differentiators
Voor differentiators geldt dat ze het beste binnen het bedrijf zelf kunnen worden ontwikkeld. Dit zijn tenslotte de features waarmee het product zich van de concurrent gaat onderscheiden. Hier kiezen voor "kopen" in plaats van "maken" betekent dat een bedrijf zich voor die cruciale features afhankelijk maakt van een derde. En deze features open source maken betekent dat ze door iedereen overgenomen kunnen worden, zodat ze niet langer differentiërend zijn.
Commodity features
Voor de commodity features geldt precies het omgekeerde. Deze vertegenwoordigen geen waarde, dus deze moeten zo goedkoop en efficiënt mogelijk worden gerealiseerd. Open source is hoge kwaliteit, direct beschikbaar en ook nog eens zonder licentiekosten. Dit is dus de meest logische keuze hier. Vandaar dat steeds meer bedrijven kiezen voor Linux als besturingssysteem in hun apparaten.
Basisfeatures
Daarmee blijven de basisfeatures over als grijs gebied. Hiervoor is geen algemene regel te geven; dit moet van geval tot geval worden beslist. Een dergelijke feature kan bijvoorbeeld zeer nauw verweven zijn met een differentiator. Gebruik van open source kan dan als consequentie hebben dat de differentiator ook als open source uitgebracht moet worden. Wellicht is er geen open source alternatief van dezelfde kwaliteit beschikbaar, of wordt de feature in kwestie ook aan anderen gelicentieerd.
Juridisch ontwerp van software
In theorie klinkt dit mooi, maar de praktijk kan soms tegenvallen. Het bouwen van een software-gebaseerd product is geen kwestie van Lego-blokjes op elkaar stapelen. Code kan op vele manieren worden gecombineerd: kopiëren en plakken, linken, remote procedure calls, object-georienteerde klassen hergebruiken, Web services, het zijn slechts een paar van de mogelijkheden. Dit kan zeer complexe interacties en technische afhankelijkheden tussen de componenten creëren. De juridische implicaties zijn minstens zo complex.
Dit geeft aan waarom het noodzaak is om vanaf het begin juridische specialisten, met name de intellectual property (IP)-juristen, bij het project te betrekken. Technische keuzes kunnen juridische consequenties hebben, bijvoorbeeld dat de gehele software stack alleen als open source kan worden uitgebracht. Het kan erg vervelend zijn als deze consequentie pas duidelijk wordt als het project technisch klaar is. Daarom moeten bij de projectdefinitie niet alleen de technische maar ook de juridische eisen worden geformuleerd.
De ABISS
Een concreet voorbeeld is de Active Block I/O Scheduling System (ABISS) die door Philips aan het Linux-besturingssysteem is bijgedragen. Dit systeem maakt het mogelijk om in real time audio- of video-stromen van een harde schijf te lezen. Dit is uiteraard belangrijk bij het gebruik van Linux in consumentenelektronica.
Wat is ABISS
ABISS garandeert dat een applicatie de datastroom krijgt met de gewenste doorvoersnelheid, of meldt de applicatie dat dit niet mogelijk is.
Het cruciale deel van ABISS is de scheduler. Deze moet alle datastromen beheren en ervoor zorgen dat de doorstroom met de gewenste snelheden blijft doorgaan. De keuze voor het te gebruiken algoritme, of zelfs maar de parameters om het algoritme mee af te stemmen, is van grote invloed op de werking van het systeem. Philips heeft jaren research geïnvesteerd in het vinden van de juiste algoritmen en de beste parameters daarvoor.
Waarom ABISS open source maken
De reden om ABISS open source te maken was om deze technologie tot de facto standaard te verheffen. Door integratie van ABISS in de Linux kernel zou verdere ontwikkeling samen met de kernel-gemeenschap kunnen gebeuren. Zou later bijvoorbeeld de architectuur van de harddisk-drivers wijzigen, dan zou ABISS ook worden aangepast om te blijven werken.
De eenvoudigste manier om dit te doen was door ABISS-code toe te voegen aan de Linux kernel broncode. Omdat de Linux kernel onder de GPL aangeboden is, zou dit als consequentie hebben dat alle ABISS-code ook onder de GPL beschikbaar gesteld moest worden. Dit was niet wenselijk, omdat hiermee ook alle kennis over de meest efficiënte algoritmen en parameters openbaar zou worden. Dit zou ook gelden voor derden die ABISS zouden willen gebruiken in hun eigen apparatuur met eigen algoritmen.
Bovendien zou het nu lastig worden voor derden om hun applicaties gebruik te laten maken van ABISS. Om ABISS de de facto standaard te laten worden, was het noodzakelijk er voor te zorgen dat ook gesloten (proprietary) software hier van gebruik kon maken.
Juridische ontwerpbeslissingen
Op basis van het bovenstaande werden de volgende drie juridische ontwerpbeslissingen gemaakt:
- Elke applicatie, open source of niet, moet zonder verdere verplichtingen van ABISS gebruik kunnen maken.
- Iedereen moet zijn eigen algoritme voor de scheduler aan ABISS toe kunnen voegen zonder dat dit algoritme publiek domein zou moeten worden.
- Veranderingen aan de ABISS code zelf moeten open source worden.
De software-ontwikkelaars werkten samen met de IP-juristen om de ABISS architectuur te laten voldoen aan deze ontwerpbeslissingen. Dit had een aantal fundamentele veranderingen tot gevolg. Het resultaat is te zien in figuur 2.
Figuur 2: De ABISS architectuur
De nieuwe opzet van ABISS
Uiteindelijk is ABISS opgezet als een raamwerk waarin algoritmes en zelfs de parameters daarvoor als aparte componenten konden worden geplaatst. Het raamwerk bestaat uit een aantal wijzigingen aan de Linux kernel. De scheduler zelf wordt gerealiseerd als een Loadable Kernel Module. Dit is een mechanisme om gesloten componenten samen te laten werken met de Linux kernel zelf. Door gebruik te maken van dit mechanisme wordt voldaan aan de tweede juridische ontwerpbeslissing.
Om technische redenen werden de componenten voor het scheduling algoritme en het beheer van de parameters en andere instellingen gescheiden. Het afstellen van het algoritme gebeurt door een "daemon", een achtergrondproces dat via het raamwerk in de kernel communiceert met de scheduler. Instellingen worden gewijzigd door een plug-in toe te voegen aan deze daemon.
Dit gescheiden ontwerp van scheduler en daemon voldoet meteen ook aan de bovengenoemde tweede juridische ontwerpbeslissing. Als licentie voor de daemon is gekozen voor de GNU GPL, waarbij een mededeling is toegevoegd dat plug-ins niet onder de scope van deze licentie vallen. Dit was noodzakelijk vanwege de tweede juridische ontwerpbeslissing.
Een applicatie kan via een systeembibliotheek gebruik maken van de ABISS functionaliteit. Deze systeembibliotheek wordt uitgebracht onder de GNU LGPL, een Keep-open licentie. Wijzigingen aan deze bibliotheek moeten open source worden, maar applicaties die de bibliotheek gebruiken niet. Aan de eerste en derde juridische ontwerpbeslissingen is ook hier dus voldaan.
Het raamwerk zelf is onderdeel van de Linux kernel en kan dus alleen onder de GPL worden uitgebracht. Dit is echter geen enkel probleem, omdat hiermee verbeteringen aan het raamwerk ook als open source beschikbaar zullen komen. Hiermee is dus aan de tweede juridische ontwerpbeslissing voldaan.
ABISS werd uitgebracht in combinatie met een vereenvoudigde versie van de scheduler die als open source beschikbaar werd gesteld. Hiermee werd aangetoond dat ABISS echt werkt. Zou ABISS zonder scheduler zijn uitgebracht, dan zou dat een zeer negatieve indruk hebben opgeroepen.
Conclusie
Veel firma's gaan op een ad-hoc manier om met open source: een programmeur heeft een stukje code nodig om een deadline te halen, men komt toevallig iets tegen op internet, of een leverancier meldt en passant dat gebruik is gemaakt van open source. Als er wel beleid over open source is, komt dat meestal neer op "niet toegestaan, tenzij". Het meer structureel en pro-actief gebruikmaken van open source voor bepaalde onderdelen van producten kan grote voordelen opleveren.
Regels over open source moeten niet gericht zijn op het verbieden daarvan, maar moeten onderdeel zijn van de strategie waarmee het bedrijf effectief gebruik van open source maakt. Cruciaal hierbij is een positieve houding van de bedrijfsjuristen en IP-specialisten, en natuurlijk voldoende kennis van software-ontwikkeling om een zinvolle bijdrage aan het ontwerp te kunnen leveren.
De open source strategie bestaat uit drie stappen. Allereerst moet bij elk product duidelijk zijn welke features differentiërend, baseline of commodity zijn. De volgende stap is op basis hiervan beslissen waar open source gebruikt gaat worden. En als derde stap moeten naast de technische ook de juridische ontwerpbeslissingen worden gemaakt, zodat het systeem op de juiste manier kan worden ontworpen. Het ABISS voorbeeld hierboven laat zien dat een goede samenwerking tussen de ontwikkelaars en de juristen hierbij van groot belang is. Kortom, mix dus niet alleen open en gesloten software, maar ook ontwikkelaars en juristen.
Dit artikel verscheen eerder in Intellectual Asset Magazine aflevering 19, augustus/september 2006.