Open source software inkopen

Closed source en afhankelijkheid

Bij closed source software kunt u de broncode niet inzien of aanpassen. De software is een soort black box. Bij het inkooptraject vraagt u in essentie een werkende softwareoplossing van de leverancier, met een bepaalde dienstverlening (zodat het blijft functioneren). Vaak is onderdeel van de licentie dat de software wordt onderhouden en kwetsbaarheden worden opgelost. U delegeert als het ware de verantwoordelijkheid dat de software goed blijft werken, zodat u daar niet over na hoeft te denken maar dit ook slechts beperkt kan controleren. 

Zolang de relatie voortduurt en de leverancier de dienstverlening in alle opzichten naar tevredenheid levert, ervaart u een zeker gemak. Aan de andere kant is er een bepaalde afhankelijkheid. U heeft namelijk geen (of in beperkte mate) kennis van de werking van de software en van de activiteiten die de leverancier onderneemt. Dit kan na verloop van tijd leiden tot een vendor lock-in en dit kan leiden tot extra kosten. Ook kan een vendor lock-in leiden tot een situatie waarin de software een cruciale en onwenselijke positie krijgt in de processen binnen uw organisatie.

Open source en overdraagbaarheid

Bij open source software is de broncode wel te lezen of aan te passen. Hierdoor is de software geen black box; bij open source krijgt u zicht in hoe de software werkt en kunt u de verschillende ICT-softwareonderdelen (laten) bekijken. U kijkt als het ware ‘onder de motorkap’. Hier is uiteraard wel deskundigheid voor nodig. Bij open source is er geen of nauwelijks sprake van (juridische) beperkingen op het gebied van onderhoud of andere dienstverleningen. De code is open.

Overdraagbaarheid is hierbij het kernbegrip. Er is vrijheid om de code over te dragen. De rechten op de software scheppen daardoor geen afhankelijkheid. De kan geen beperkingen opleggen wanneer u iemand anders het onderhoud laat uitvoeren of inhuurt voor andere dienstverlening.

Het inkopen van open source

Start u een inkooptraject voor de ontwikkeling van open source software? Of gaat u voortbouwen op basis van reeds bestaande open source software? Houd dan in het aanbestedingsproces al rekening met aspecten die het u later mogelijk maakt de software te delen. Er zijn een aantal aandachtspunten:

Uitgangspunt bepalen

Welke functionele eisen heeft u bij de software, en heeft u daarnaast ook eisen of wensen rondom de rechten? Wilt u bijvoorbeeld meerdere leveranciers aan de software kunnen laten werken? Of wilt u andere overheden inzicht kunnen geven in de software, zodat zij makkelijker kunnen koppelen? Ga vervolgens na in welke gradatie u met open source aan de slag wilt gaan: wilt u als open source een compleet framework inkopen (bijvoorbeeld een volledig softwarepakket voor administratieve taken)? Of begint u met enkele losse componenten (bijvoorbeeld een generator voor formulieren, een module om betalingen te verwerken of een standaard voor gegevensuitwisseling). Analyseer tevens de markt: zijn er bedrijven bekend met de componenten of het framework?

Functioneel beschrijven

Wanneer u de software gaat specificeren, beschrijf het functioneel. Besteed ruim aandacht aan taken die als specifieke dienstverlening kunnen worden uitgevoerd door anderen. Denk bij specifieke dienstverlening bijvoorbeeld aan het implementeren, beschikbaar houden (hosting) en het onderhouden van de software. Het voordeel van open source is immers dat meerdere partijen inzicht hebben in de code. Hierdoor is het mogelijk om bepaalde taken over te dragen aan anderen. Een onderscheid in taken kunt u aanbrengen door in overleg met (of in competitie tussen) leveranciers een scheiding te maken: tussen enerzijds functionele wensen gerelateerd aan de basisdistributie van de software, en anderzijds functionele wensen gerelateerd aan maatwerkfunctionaliteit. Laat daarbij leveranciers duidelijk aangeven hoe en tegen welke prijs de maatwerkfunctionaliteit wordt onderhouden wanneer de basisdistributie wijzigt. Op deze manier kunt u ook een beeld verkrijgen over eventuele toekomstige ontwikkelingen, bijvoorbeeld wanneer de wens bestaat om de software later uit te breiden.

Geen regels

Open source betekent niet dat er geen regels zijn. Houd bij het gebruik en de doorontwikkeling van bestaande open source software rekening met de licentievoorwaarden en betrek hierbij juridische expertise. Dit geldt ook wanneer niet uzelf maar een leverancier voor u gaat werken aan open source software. Als er wordt verder gebouwd op bestaande open source software of onderdelen uit bestaande broncode worden hergebruikt, dan is het belangrijk om te weten onder welke licenties deze software of code is uitgegeven. Sommige open source licenties stellen bijvoorbeeld dat u alles met de software en broncode mag doen, inclusief aanpassen en verder verspreiden, onder voorbehoud dat u hetzelfde recht dan ook doorgeeft aan anderen. Op die manier is er later geen mogelijkheid om de software als closed source te hanteren wanneer bepaalde onderdelen van de broncode daarin vallen.

3 soorten licenties

In de praktijk zijn er verschillende soorten open source licenties te onderscheiden. Deze licenties zijn in algemene zin in 3 categorieën onder te brengen:

• Categorie A: De enige verplichting die rust op vervolggebruikers is om de oorspronkelijke auteurs te noemen.
• Categorie B: Deze licenties stellen als eis dat wijzigingen aan de software ook als open software wordt gepubliceerd. Software waarin deze software wordt verwerkt, hoeft daarentegen niet als geheel als open source te worden uitgebracht.
• Categorie C: Deze licenties eisen dat zowel wijzigingen als uitbreidingen als open source worden gepubliceerd (copyleft).

Intellectuele eigendomsrechten

Zorg dat het vrijgeven van de open source software niet in strijd is met intellectuele eigendomsrechten en de auteursrechten die op de software rusten. Zorg dan ook dat de intellectuele eigendomsrechten en de auteursrechten van ontwikkelde software bij de aanbestedende dienst liggen en niet bij externe partijen of personen die bij de ontwikkeling betrokken zijn.

Aansprakelijkheid

Maak heldere afspraken over aansprakelijkheid, ook ten aanzien van aansprakelijkheid tegenover derden die de open source software later gaan gebruiken. Zorg dat u de afspraken op 2 plekken regelt. In de eerste plaats legt u de aansprakelijkheid vast in afspraken met de leverancier die de open source software ontwikkelt. En in de tweede plaats legt u in de licentievoorwaarden vast wat de aansprakelijkheid is die gelden voor gebruikers van de open source software.

Service Level Agreement

In de Service Level Agreement voor open source software besteed u aandacht aan de uit te voeren activiteiten (om een resultaat te bewerkstelligen), bijvoorbeeld het uitvoeren van back-ups. Bij open source draait het tenslotte om overdraagbaarheid. Focus minder op resultaten waaraan malusregelingen zijn gekoppeld (bijvoorbeeld: beschikbaarheid). Krijg daarom inzicht in de activiteiten en procedures die een leverancier onderneemt om een resultaat (zoals de upload-time van een applicatie) zeker te stellen. Zodat vervolgens deze activiteiten overdraagbaar zijn en iemand die kan uitvoeren. Bijvoorbeeld activiteiten zoals het maken van een backup. Net als de procedure van het regelmatig oefenen op het terugzetten van de backup.

Beschikbaar stellen

Stel de open source software beschikbaar voor derden. Dit kan bijvoorbeeld op platforms (‘source code repository’, zoals JoinUp of Github). Maak een keuze over hoe betrokken u wilt blijven bij de doorontwikkeling van de software door derden. Kies hier een passende licentie bij; zie de 3 categorieën hierboven. Zelf licentievoorwaarden voor open source software generen kan via choosealicense.com.

Handreiking

In de handreiking ‘delen en hergebruik van overheidssoftware’ vindt u nog meer informatie en uitleg over een aantal juridische aspecten, zoals aansprakelijkheid bij open source.

Pleio

Meer informatie over open source is te vinden op de samenwerkingsomgeving in Pleio.

Praktijkvoorbeelden

Er zijn enkele praktijkvoorbeelden beschreven van succesvolle open source trajecten bij publieke organisaties.