Author:
Arnoud Engelfriet (arnoud.engelfriet@philips.com) is octrooigemachtigde en IP-raadsman bij Philips Intellectual Property & Standards. Hij is secretaris van de Philips Open Source Advisory Board en coördineert de juridische aspecten van het open-sourcegebruik in Philips-producten.
Reading time: 9 minutes
Het gebruik van open source in een product kan het gevaar opleveren dat bedrijven de volledige software openbaar moeten maken. Veel ondernemingen verbieden daarom het gebruik ervan. Open source kan echter ook grote voordelen opleveren. Arnoud Engelfriet legt uit hoe we de valkuilen kunnen vermijden.
De afgelopen jaren is de hoeveelheid software in producten dramatisch toegenomen. Een steeds groter deel van de functionaliteit verschuift naar de programmatuur. Daardoor stijgen ook de ontwikkelkosten sterk. Het gebruik van open source op de juiste plek kan grote kostenbesparingen en een snellere doorlooptijd opleveren. Dit vereist echter wel een zorgvuldig ontwerp van de softwarearchitectuur en een goede samenwerking tussen de betrokken ontwikkelaars en juristen.
Het open-sourceontwikkelmodel gaat uit van het vrijelijk delen van de broncode: iedereen krijgt het recht de software aan te passen en te verspreiden. Hoewel niet verplicht, is het de bedoeling om wijzigingen terug te geven aan de oorspronkelijke auteurs. Bekende voorbeelden van open source zijn het Linux-besturingssysteem, de Firefox-webbrowser en de Apache-webserver.
De rechten en plichten omtrent open-source software zijn vastgelegd in licenties. Vaak is het verplicht om wijzigingen of verbeteringen ook als open source beschikbaar te stellen. Dit kan uiteenlopende gevolgen hebben, afhankelijk van de softwarearchitectuur. Zo kan het betekenen dat we de broncode van een gehele stack moeten vrijgeven.
Veel bedrijven zien deze eis als een risico en proberen open source daarom zoveel mogelijk te vermijden. Dat betekent echter dat ze zichzelf de toegang ontzeggen tot software van hoge kwaliteit zonder licentiekosten. Dit wordt steeds minder realistisch, en soms is het commercieel simpelweg niet haalbaar om bij te blijven bij een concurrent die wel aan open source doet. De enige optie is dus om met de risico‘s te leren omgaan.
Vrijheid blijheid
Er zijn ongeveer veertig verschillende open-sourcelicenties met elk hun eigen regels en voorwaarden. Deze zijn grofweg onder te verdelen in drie categorieën: free-for-all, keep-open en share-alike. Het minst restrictief zijn de free-for-all-licenties. Deze zijn te karakteriseren als ’vrijheid blijheid‘. De enige eis die ze stellen, is dat de originele auteurs genoemd blijven. Voorbeelden hiervan zijn de zogeheten BSD- en MIT-licenties. De Apache-webserver heeft een dergelijk gebruikersrecht.
Daarnaast zijn er de keep-open-licenties. Deze draaien om het openhouden van de broncode en eisen dat we wijzigingen ook als open source publiceren. Als we deze software in een product verwerken, hoeven we echter niet het gehele programma te openen. Linux-systeembibliotheken en de Firefox-webbrowser hebben een dergelijke licentie.
Het meest verregaand zijn de share-alike-licenties. Deze eisen het vrijgeven van zowel de wijzigingen als de uitbreidingen. Het bekendste voorbeeld is de Gnu General Public License (Gnu GPL), die bijvoorbeeld van toepassing is op Linux.
Voor bedrijven ligt het voor de hand om alleen free-for-all-licenties toe te staan. Toch maakt slechts 15 procent van alle open-source software hier gebruik van. 65 procent valt onder de GPL. Wie open source wil gebruiken, kan eigenlijk niet om keep-open- en share-alike-licenties heen. Goede regels zijn dus nodig. Deze moeten echter gaan over waar en niet of we open source mogen gebruiken.
Het is niet altijd nodig om de broncode van een product volledig vrij te geven. Vaak is het is slimmer om open source alleen voor specifieke features te gebruiken en de overige onderdelen zelf te ontwikkelen of in te kopen. Met andere woorden, de klassieke vraag ’Maken of kopen?‘ moet zijn: ’Maken, kopen of open source?‘ Het antwoord hangt af van de vraag wat de meeste waarde oplevert.
Differentieerder
Het gebruik van open source kan de waarde van een product op verschillende manieren beïnvloeden. Als een stuk software het artikel onderscheidt van de concurrent, vermindert het openen van de broncode de waarde. Dit geldt ook als de opbrengsten komen uit het commercieel in licentie geven van de programmatuur. Dit betekent wel dat de eigenaar moet investeren in de ontwikkeling en het onderhoud van de code. Bij open source is dit in mindere mate het geval. Bij het gebruik van open-source software van een derde partij zijn we niet langer afhankelijk van één enkele leverancier.
De vraag is dus hoe de balans op te maken. Hierbij helpt ons een oude regel uit de economie: zorg ervoor dat het complement van je product algemeen beschikbaar is. Een digitale audiospeler is bijvoorbeeld pas interessant als er muziek voor te krijgen is. Voor fabrikanten van dit soort spelers loont het dus de moeite om digitale muziek algemeen beschikbaar te maken.
Een soortgelijke wetmatigheid geldt voor features van een product: unieke eigenschappen bestaan bij de gratie van hun complementen. Een digitale televisie kan bijvoorbeeld automatisch samenvattingen van dertig seconden laten zien van opgenomen televisieprogramma‘s. Daarvoor moet het apparaat wel programma‘s digitaal kunnen opnemen. Deze feature is dus complementair aan de automatische samenvatter. Open source is in principe geschikt voor deze complementen.
Deze indeling is echter niet zaligmakend, omdat sommige niet-differentiërende eigenschappen toch waarde kunnen hebben als ze gesloten zijn. Een standaard softwarebibliotheek is bijvoorbeeld niet differentiërend, maar is wel voor geld in licentie te geven aan derden. Daarom kunnen we de eigenschappen beter in drie categorieën opdelen. De differentieerder, ook wel het unique selling point (USP), voegt waarde toe aan het product en biedt een reden om het te kopen. De basisfeatures voegen geen waarde toe maar zijn wel nodig omdat de koper ze verwacht. Niemand koopt een digitale muziekspeler die geen MP3-bestanden kan afspelen. De commodity-features zijn noodzakelijk om het product te laten werken maar voegen geen waarde toe en de koper is er niet in geïnteresseerd.
IP-juristen
Deze onderverdeling geeft een zinvol antwoord op de vraag: ’Maken, kopen of open source?‘ (zie Figuur 1). Voor differentieerders geldt dat we ze het beste zelf kunnen ontwikkelen. Dit zijn tenslotte de eigenschappen waarmee het product zich van de concurrentie onderscheidt. Kopen is een minder goede optie, want dat maakt afhankelijk van een derde partij. Open source zou betekenen dat iedereen ze kan overnemen, zodat ze niet langer differentiërend zijn.
Voor de commodity-features geldt precies het omgekeerde. Deze vertegenwoordigen geen waarde, dus de realisatie ervan moet zo goedkoop en efficiënt mogelijk zijn. Open source is van hoge kwaliteit, direct beschikbaar en ook nog eens zonder licentiekosten. Dat is dus de meest logische keuze hier. Vandaar dat steeds meer bedrijven kiezen voor Linux als besturingssysteem in hun apparaten.
Daarmee blijven de basisfeatures over als grijs gebied. De keuze voor maken, kopen of open source verschilt per geval. Hiervoor is geen algemene regel te geven. Een dergelijke feature kan bijvoorbeeld zeer nauw verweven zijn met een differentieerder. Gebruik van open source kan dan de consequentie hebben dat we deze ook als open source moeten uitbrengen. Wellicht is er geen open-source alternatief van dezelfde kwaliteit beschikbaar of hebben anderen ook een licentie op de feature.
Natuurlijk is deze verdeling in de praktijk niet altijd even helder. Het bouwen van een softwaregebaseerd product is geen kwestie van Lego-blokjes op elkaar stapelen. Code is op vele manieren te combineren: kopiëren, linken, remote procedure calls, gebruiken van objecten, webservices, het zijn slechts een paar van de mogelijkheden. Dit kan zeer ingewikkelde interacties en technische afhankelijkheden tussen de componenten creëren.
De juridische implicaties zijn minstens zo complex. Om deze te kunnen beheersen, is het een absolute noodzaak om vanaf het begin juridische specialisten bij het project te betrekken, met name IP-juristen. Het kan erg vervelend zijn als een consequentie pas aan het licht komt als het project technisch klaar is. Dan zouden we bijvoorbeeld de gehele softwarestack moeten openen. Daarom moeten we niet alleen de technische maar ook de juridische eisen formuleren bij de projectdefinitie.
Daemon
Een concreet voorbeeld is het Active Block I/O Scheduling System (Abiss). Philips heeft deze bijgedragen aan de Linux-kernel. Het systeem maakt het mogelijk om in realtime audio- of videostromen van een harde schijf te lezen. Dit is uiteraard belangrijk bij het gebruik van Linux in consumentenelektronica. Abiss garandeert dat een applicatie de datastroom krijgt met de gewenste doorvoersnelheid of vertelt de toepassing dat dit niet mogelijk is.
Het cruciale deel van Abiss is de scheduler. Die moet alle datastromen beheren en ervoor zorgen dat deze met de gewenste snelheden blijven doorgaan. De werking van het systeem is sterk afhankelijk van het gebruikte algoritme en de parameters. De reden om Abiss open-source te maken was om deze technologie tot de de facto standaard te verheffen. Integratie in Linux zou verdere ontwikkeling samen met de kernel-gemeenschap mogelijk maken. Als bijvoorbeeld de architectuur van de harddiskdrivers wijzigt, dan wordt ook Abiss aangepast.
De eenvoudigste manier om het systeem vrij te geven was door Abiss-code toe te voegen aan de broncode van de Linux-kernel. Omdat deze onder de GPL valt, zou dit de consequentie hebben dat Abiss ook onder deze licentie beschikbaar moest komen. Dit was niet wenselijk, omdat dit ook alle kennis over de meest efficiënte algoritmes en parameters openbaar zou maken. Philips heeft jaren research geïnvesteerd in het vinden hiervan. Ook anderen die Abiss willen voorzien van eigen algoritmes zouden deze moeten vrijgeven.
Om van Abiss de de facto standaard te maken was het noodzakelijk dat deze ook gesloten te gebruiken is. Daarom maakte Philips de volgende drie juridische ontwerpbeslissingen:
Elke applicatie, open-source of niet, moet Abiss zonder verdere verplichtingen kunnen gebruiken.
Iedereen moet zijn eigen algoritme voor de scheduler aan Abiss kunnen toevoegen zonder deze openbaar te hoeven maken.
Veranderingen aan de Abiss-code zelf moeten open-source worden.
De softwareontwikkelaars werkten samen met de IP-juristen om de Abiss-architectuur te laten voldoen aan deze beslissingen. Dat resulteerde in een aantal fundamentele veranderingen (zie Figuur 2). Binnen Abiss zijn de algoritmes en de parameters nu als aparte componenten te plaatsen. Het raamwerk bestaat uit een aantal wijzigingen aan de kernel. De scheduler zelf hebben we geïmplementeerd als laadbare module, een systeem waarmee gesloten componenten kunnen samenwerken met de kernel zelf.
Om technische redenen hebben we de componenten voor het schedulingalgoritme 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. Het wijzigen van instellingen gaat via een plug-in van deze daemon. Dit gescheiden ontwerp voldoet meteen aan het tweede juridische criterium. De daemon heeft de GPL als licentie, waarbij we de mededeling hebben toegevoegd dat plug-ins niet onder de scope van deze licentie vallen.
Een applicatie kan Abiss via een systeembibliotheek gebruiken. Deze valt onder de Gnu Lesser General Public License (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 hebben we ook hier dus voldaan. Het raamwerk zelf is onderdeel van de Linux-kernel en valt daarmee onder de GPL. Dit is echter geen enkel probleem, omdat verbeteringen aan het raamwerk zo ook als open source beschikbaar komen. Hiermee hebben we dus aan de derde ontwerpbeslissing voldaan.
Om aan te tonen dat Abiss echt werkt, hebben we het systeem uitgebracht met een vereenvoudigde open-sourceversie van de scheduler. Anders zou het een zeer negatieve indruk hebben opgeroepen.
Bedrijfsjuristen
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 en komt toevallig iets tegen op internet, of een leverancier meldt en passant dat hij open source heeft gebruikt. Als er wel beleid over open source is, komt dat meestal neer op ’niet toegestaan, tenzij‘. Een structureel en proactief gebruik van open source voor specifieke onderdelen kan echter grote voordelen opleveren.
Regels over het gebruik ervan moeten niet gericht zijn op het verbieden, maar onderdeel zijn van de strategie waarmee het bedrijf er effectief gebruik van maakt. Cruciaal hierbij is een positieve houding van de bedrijfsjuristen en IP-specialisten. En natuurlijk voldoende kennis van softwareontwikkeling om een zinvolle bijdrage aan het ontwerp te kunnen leveren.
De open-sourcestrategie beslaat drie stappen. Allereerst moet bij elk product duidelijk zijn of features binnen de categorie differentiërend, basis of commodity vallen. De volgende stap is om op basis hiervan te beslissen waar we open source gebruiken. De laatste stap is het maken van de technische én juridische ontwerpbeslissingen, zodat we het systeem op de juiste manier kunnen ontwerpen. Het Abiss-voorbeeld hierboven laat zien dat een goede samenwerking tussen ontwikkelaars en juristen van groot belang is. Kortom, mix dus niet alleen open en gesloten software, maar ook ontwikkelaars en juristen.
