Open source software inkopen

Open source software

Open source software mag vrij gebruikt, bestudeerd, aangepast en verder verspreid worden. Daarbij gelden de voorwaarden van de open source licentie. Die voorwaarden kunnen zijn dat verbeteringen op de bestaande broncode ook als open source gepubliceerd moeten worden of dat alle auteurs altijd genoemd moeten worden. 

De meeste open source licenties staan niet toe dat gebruikers de vrijheden en verantwoordelijkheden verder inperken. Ze mogen wel worden uitgebreid. Open source licenties sluiten allemaal aansprakelijkheid uit. Omdat iedereen de software vrij mag gebruiken en aanpassen, hebben de auteurs geen controle over hoe anderen de software inzetten. Daarom kunnen zij niet verantwoordelijk worden gehouden voor het gebruik ervan.

De broncode bestuderen, aanpassen of verder verspreiden kan op platforms zoals het Nederlandse code.overheid.nl, het Europese codeberg of Amerikaanse platforms als GitHub of GitLab. Zo blijft de software transparant en betrouwbaar. De software is inzichtelijk en herbruikbaar voor andere organisaties. Dit sluit aan bij de Visie digitale soevereiniteit en autonomie van de overheid en de inspanningsverplichting in de Wet hergebruik overheidsinformatie.

Wettelijke inspanningsverplichting

De Wet open overheid (Woo) heeft als doel om overheden transparanter te maken. Sinds 1 mei 2022 bepaalt de Woo dat belangrijke overheidsinformatie actief openbaar moet worden gemaakt. Ook broncode valt onder de Woo. Soms moet een overheid na een Woo-verzoek de broncode openbaren, zoals bij de broncode van DigiD.

De Wet hergebruik overheidsinformatie (Who) voegt een extra inspanningsverplichting toe. Namelijk dat alle openbare overheidsinformatie, waaronder software, zo makkelijk mogelijk vrij beschikbaar moet zijn. Dat betekent dat de software die de overheid zelf ontwikkelt of laat ontwikkelingen als open source gepubliceerd moet worden. De wet noemt hierbij de European Union Public License als voorkeurslicentie.

Afhankelijkheid en closed source 

Anders dan bij open source software kun je bij closed source (propriëtare) software de broncode niet inzien en aanpassen. Je betaalt voor een gebruikerslicentie en tekent eventueel een geheimhoudingsverklaring. Vaak is onderdeel van de licentie dat de leverancier de software onderhoudt en kwetsbaarheden oplost. Dit kun je echter slechts beperkt controleren. Zolang de leverancier de dienstverlening naar tevredenheid levert, ervaar je een zeker gemak van de software.

De keerzijde van deze software is de afhankelijkheid tot de leverancier. Je hebt namelijk geen (of in beperkte mate) kennis van de werking van de software en van de activiteiten die de leverancier onderneemt. Bij een sterke afhankelijkheid stap je niet zomaar over naar een andere leverancier. Dit kan na verloop van tijd leiden tot een vendor lock-in. Software van een bepaalde leverancier is bijvoorbeeld alleen verenigbaar met andere software van dezelfde leverancier. Ook integratie met andere systemen is lastig. Soms stijgen de licentiekosten, maar is door de belangrijke positie van de software in een organisatie, overstappen naar een andere leverancier zeer kostbaar. Deze afhankelijkheid neemt toe, naar mate je langer bij een leverancier blijft. 

Aandachtspunten inkopen open source  

Kies voor open source software in je ICT-aanbestedingen. Open source draagt immers samen met open standaarden bij aan de rechtmatigheid en digitale autonomie en soevereiniteit van je organisatie. Ook vermindert het de kans op leveranciersafhankelijkheid. Start je een inkooptraject voor de ontwikkeling van open source software? Of bouw je voort op al bestaande open source software? Besteed dan aandacht aan de volgende onderwerpen: 

Open, tenzij beleid

Houd vroeg in het aanbestedingsproces rekening met het 'Open, tenzij'-beleid . 

Wel of niet aanbesteden

Open source software is vrij beschikbaar. Als je de software kosteloos kunt verkrijgen en daar geen tegenprestatie tegenover staat, hoef je voor de software zelf geen aanbesteding te organiseren. Bij de dienstverlening rondom open source software, zoals de integratie ervan, is het afhankelijk van de waarde van de opdracht of je wel of niet moet aanbesteden. Je kunt er ook voor kiezen om de doorontwikkeling, hosting en het beheer in huis met de eigen mensen op te pakken (inbesteden). Lees voor meer informatie over dit onderwerp de pagina Open source software gebruiken zonder aanbesteding: wat mag wel en wat niet?

Eén leverancier of meerdere

Doorontwikkeling en bijbehorende diensten kun je inkopen. Dat kan op verschillende manieren. Je kan, zoals bij veel closed source software, volledig worden ontzorgt door één leverancier. Deze leverancier ontwikkelt de software en verzorgt ook alle dienstverlening eromheen. Of je kan aanbesteden vanuit een open ecoysteem-gedachte waarin je de ontwikkeling en het beheer bewust loskoppelt en opsplitst. Je werkt dan samen met meerdere leveranciers die ook weer met elkaar samenwerken. Dit heeft als voordeel dat leveranciers elkaars werk (tijdelijk) kunnen overnemen mocht er één omvallen en je houdt de marktmacht van leveranciers evenwichtig. Die laatste optie verkleint leveranciersafhankelijkheid aanzienlijk.

Functioneel beschrijven

Specificeer de software functioneel. Besteed ruim aandacht aan taken die worden uitgevoerd door anderen. Denk bijvoorbeeld aan het implementeren, beschikbaar houden (hosting) en het onderhouden van de software. Omdat meerdere partijen inzicht hebben in de broncode is het mogelijk om bepaalde taken te verdelen tussen leveranciers. Je kunt onderscheid maken in taken. Bijvoorbeeld een scheiding in: 

• functionele wensen gerelateerd aan de basisdistributie van de software en
• functionele wensen gerelateerd aan maatwerkfunctionaliteit

Doe dit in overleg met (of in competitie tussen) leveranciers. Laat daarbij leveranciers duidelijk aangeven hoe en tegen welke prijs zij de maatwerkfunctionaliteit onderhouden wanneer de basisdistributie wijzigt.

Bedenk daarbij goed welke functionaliteit je direct nodig hebt en welke op termijn. Doordat open source software vrij aanpasbaar is, kunnen aanvullende functionaliteiten altijd worden toegevoegd. Door hier een duidelijk groeipad in aan te brengen wordt een aanbesteding voor leveranciers toegankelijker. Ze hoeven immers niet direct een complete oplossing met alle gewenste functies te kunnen overleggen, maar kunnen in samenwerking met de opdrachtgever aanvullende functionaliteiten toevoegen. Gezien het open source karakter zijn deze nieuwe functies tegelijk te gebruiken voor andere gebruikers van diezelfde oplossing. 

Juridische aandachtspunten

Het werken met open source broncode brengt juridische aandachtspunten met zich mee. 

Beleid en regels

De belangrijkste zitten naast de Wet open overheid en de Wet hergebruik overheidsinformatie ook in de Auteurswet en de Wet Markt en Overheid. Lees voor meer informatie over dit onderwerp verder op de pagina Beleidsinstrumenten. Deze pagina van het ministerie van Volksgezondheid, Welzijn en Sport bevat instrumenten die ideze juridische aandachtspunten behandelen.

Inspraak

Dat open source software vrij te gebruiken en aan te passen is, betekent niet dat iedereen zomaar aanpassingen mag doen aan jouw versie van die software. Je beslist als gebruiker zelf welke versie van de software je gebruikt. Ook kun je zelf bepalen of je die versie ongewijzigd gebruikt, of dat je er aanpassingen inmaakt of laat maken door een leverancier.

In de meeste gevallen gebruik je een versie die door anderen is gemaakt en wordt onderhouden. Het kan gebeuren dat de ontwikkeling van die versie niet meer past bij wat je wilt. Dan kun je ervoor kiezen om een eigen versie van de software te maken en die verder te ontwikkelen. Dit heet ‘forken’.

Aansprakelijkheid

Maak net als bij closed source heldere afspraken over aansprakelijkheid. Zorg dat je de afspraken op 2 plekken regelt:

• Je legt de aansprakelijkheid vast in afspraken met de leverancier die de open source software ontwikkelt. Dat is de aansprakelijkheid die de opdrachtnemer heeft vanuit de opdracht.
• Je zorgt er met een open source licentie voor dat de opdrachtnemer en opdrachtgever niet aansprakelijkheid zijn wanneer derden gebruik maken van de broncode.

Service Level Agreement

Leg net als bij closed source in de Service Level Agreement vast welke activiteiten nodig zijn om het gewenste resultaat te bereiken, bijvoorbeeld het uitvoeren van back-ups. Richt je minder op resultaten waaraan malusregelingen zijn gekoppeld (bijvoorbeeld: beschikbaarheid). Belangrijk is ook om inzicht te hebben in de activiteiten en procedures die een leverancier onderneemt om een resultaat (zoals de upload-time van een applicatie) te garanderen. Hierdoor zijn deze activiteiten over te dragen aan anderen.

Licentievoorwaarden

Houd bij het gebruik en de doorontwikkeling van bestaande open source software rekening met de licentievoorwaarden. Betrek hierbij juridische expertise of lees je goed in. Dit geldt ook wanneer niet jijzelf maar een leverancier voor je werkt aan open source software. Als je voortbouwt op bestaande open source software of onderdelen uit bestaande broncode hergebruikt, is het belangrijk om te weten onder welke licenties deze software of code is uitgegeven.

Intellectueel eigendom

In standaard inkoopvoorwaarden, zoals de ARBIT, ARVODI of GIBIT wordt het intellectueel eigendom (IE) bij maatwerk overgedragen aan de opdrachtgever. Deze wordt dan juridisch eigenaar van de ontwikkelde software en een leverancier kan de doorontwikkeling niet beperken. Vaak blijft de broncode onbenut, omdat er geen beleid is om een broncode nog te publiceren of omdat openheid van de broncode niet op voorhand in het ontwerp is meegenomen.

In de laatste versie van de GIBIT (2025) is er daarom voor gekozen om naast die IE-recht overdracht in bepaalde gevallen ook een open source publicatie door leverancier te vereisen.

Community Opensourcewerken

Meer weten? Meer informatie over open source inkopen vind je in de community Opensourcewerken.