U bevindt zich in
OpenSource
Dwarsligger
HoofdstukkenMenu terugOpenSource Volgens Pagina's startBindendheid van LicentiesGevaar of KansJuridische StatusKennisnetwerk OpenSourceMixen Open en GeslotenOnderzoek OSS voor OverheidOpenSource PraktijkgidsOpen source licentieproblematiekOverheid en OpenSourceWelke Licentie
Mixen Open en Gesloten

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 OpenSource 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 OpenSource
OpenSource 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 OpenSource zijn het Linux-besturingssysteem, de Firefox webbrowser en de Apache webserver.

OpenSource licenties
Deze rechten zijn vastgelegd in de OpenSource licenties.
Naast rechten leggen deze licenties gebruikers ook bepaalde verplichtingen op.
Zo is het vaak verplicht om wijzigingen of verbeteringen ook als OpenSource beschikbaar te stellen.
Afhankelijk van de software-architectuur kan dat betekenen dat de gehele stack van een product als OpenSource moet worden gepubliceerd.

Veel bedrijven zien deze eis als een risico en proberen daarom het gebruik van OpenSource zoveel mogelijk te vermijden.
Dit is tegenwoordig echter geen realistische optie meer.
Het gebruik van OpenSource in commerciële producten wordt steeds populairder.
OpenSource 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 OpenSource concurrent voor een zelf ontwikkeld stuk software.
De enige optie is dus met de risico's leren omgaan.

Licentievormen
Er zijn ongeveer 40 verschillende OpenSource licenties met elk hun eigen regels en voorwaarden.
Deze kunnen worden onderverdeeld in drie categorieën: Het lijkt nu voor de hand te liggen om alleen het gebruik van free-for-all OpenSource toe te staan, en de andere twee vormen buiten te sluiten of aan strenge regels te onderwerpen.
Echter, op ongeveer 65% van alle OpenSource is de GPL van toepassing, terwijl slechts ongeveer 15 procent onder een free-for-all licentie beschikbaar is.
Wie gebruik wil maken van OpenSource, kan dus niet om share-alike en keep-open licenties heen.
Goede regels zijn nodig, maar deze moeten gaan over waar en niet of OpenSource mag worden gebruikt.

Waar OpenSource
Vaak is de beslissing om OpenSource te gebruiken puur zwart/wit: een product wordt volledig OpenSource of gebruikt het juist helemaal niet.
Het is veel slimmer om alleen voor bepaalde features OpenSource 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 OpenSource?"

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 OpenSource worden gepubliceerd.
In deze gevallen moet wel worden geïnvesteerd in ontwikkeling en onderhoud van de software.

Software uitbrengen als OpenSource 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 OpenSource 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.

OpenSource voor complementaire features
OpenSource 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 OpenSource 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 OpenSource 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: De klassieke vraag bij elke feature is "maken of kopen?".
Zoals hierboven betoogd, moet die vraag eigenlijk zijn "maken, kopen of OpenSource?".
Met deze onderverdeling is het mogelijk hier een zinvol antwoord op te geven.

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 OpenSource 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.
OpenSource 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 OpenSource kan dan als consequentie hebben dat de differentiator ook als OpenSource uitgebracht moet worden.
Wellicht is er geen OpenSource 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 OpenSource 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
Zie ook Introduction to ABISS (PDF, Engelstalig).
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 OpenSource maken
De reden om ABISS OpenSource 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:

  1. Elke applicatie, OpenSource of niet, moet zonder verdere verplichtingen van ABISS gebruik kunnen maken.
  2. Iedereen moet zijn eigen algoritme voor de scheduler aan ABISS toe kunnen voegen zonder dat dit algoritme publiek domein zou moeten worden.
  3. Veranderingen aan de ABISS code zelf moeten OpenSource 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.

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 OpenSource 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 OpenSource 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 OpenSource 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 OpenSource: 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 OpenSource.
Als er wel beleid over OpenSource is, komt dat meestal neer op "niet toegestaan, tenzij".
Het meer structureel en pro-actief gebruikmaken van OpenSource voor bepaalde onderdelen van producten kan grote voordelen opleveren.

Regels over OpenSource moeten niet gericht zijn op het verbieden daarvan, maar moeten onderdeel zijn van de strategie waarmee het bedrijf effectief gebruik van OpenSource 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 OpenSource 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 OpenSource 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.

Bron: Iusmentis op 8 mei 2019 door Arnoud Engelfriet.
Valid HTML 5.0 Valid CSS
Een link is een pagina,
een link is een hoofdstuk,
een link is in een externe website,
een link is een download.
© Dwarsligger.org, overname met bronvermelding toegestaan,
tenzij anders aangegeven.
Ron's CMS versie 190612a
Samengesteld in
Inhoud grootte
Aangemaakt op
Aangepast    op
22724 µsec.
25474 bytes
Onbekend
20 aug 2019