Open source software inkopen

Bij open source software is de broncode door iedereen in te zien. Hierdoor kan de software door anderen hergebruikt, aangepast of verder verspreid worden. Als je open source software inkoopt, dan staat het begrip ‘overdraagbaarheid’ en ‘onafhankelijkheid’ voornamelijk centraal.

Open source software

Bij software met een open source licentie kan iedereen de broncode controleren, aanpassen of verspreiden. Dit kan op platforms zoals GitHub of GitLab. Zo blijft de software transparant en betrouwbaar. De software is inzichtelijk en herbruikbaar voor andere organisaties. Dit sluit aan bij het Nederlandse 'Open, tenzij'-beleid.

Wettelijke inspanningsverplichting open source

Het 'Open, tenzij'-beleid is vastgelegd in wetten en regels. Zo heeft de Wet open overheid (Woo) 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) schrijft voor dat alle openbare overheidsinformatie, waaronder software, zo makkelijk mogelijk beschikbaar moet zijn voor burgers, bedrijven en onderzoeksinstellingen. Overheden moeten zich inspannen (inspanningsverplichting) om software die zij zelf maakt of laat ontwikkelen geschikt te maken voor hergebruik. Bij voorkeur gebeurt dit met Europees veelgebruikte opensourcelicenties, zoals de EUPL.

Closed source en afhankelijkheid

Anders dan bij open source software kun je bij closed source, oftewel 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.

Aan de andere kant is er een afhankelijkheid. 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 is.

Aandachtspunten inkopen open source

Start je een inkooptraject voor de ontwikkeling van open source software? Of bouw je voort op al bestaande open source software? Houd dan vroeg in het aanbestedingsproces rekening met het 'Open, tenzij'-beleid.

Er zijn een aantal aandachtspunten:

Gratis gebruiken

Haal als aanbestedende dienst gratis open source software binnen. De doorontwikkeling en dienstverlening van deze software kun je aanbesteden.

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.

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.

Licentievoorwaarden

Houd bij het gebruik en de doorontwikkeling van bestaande open source software rekening met de licentievoorwaarden. Betrek hierbij juridische expertise. Dit geldt ook wanneer niet jijzelf maar een leverancier voor je werkt aan open source software. Als je doorbouwt 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.

Drie soorten licenties

Er zijn 3 verschillende soorten open source licenties te onderscheiden:

Permissieve (toegefelijke) licenties
Deze licenties leggen minimale restricties op aan het hergebruik van de broncode. Gebruikers mogen de software vrij kopiëren, wijzigen, verspreiden en zelfs opnemen in closed source software. Bekende voorbeelden zijn de MIT-licentie, de Apache-licentie en de BSD-licenties.
Weak copyleft (zwak-wederkerige) licenties
Deze licenties vereisen dat wijzigingen aan de gelicenseerde software worden vrijgegeven onder dezelfde licentie. De licenties stellen minder strenge eisen aan software die met de gelicenseerde code wordt gecombineerd of gelinkt. Hierdoor zijn combinaties met closed source code mogelijk. Voorbeelden zijn de LGPL (Lesser General Public License) en de MPL (Mozilla Public License).
Strongly copyleft (sterk-wederkerige) licenties
Deze licenties verplichten dat alle afgeleide werken van de gelicenseerde software onder dezelfde licentie worden vrijgegeven. Dit betekent dat elke software die gebruik maakt van of gelinkt wordt aan de originele code ook open source moet zijn. De GPL (General Public License) is het bekendste voorbeeld.

Je kunt verschillende online tool gebruiken om geschikte licenties te kiezen. Voorbeelden zijn: Lijst goedgekeurde open source licenties Open Source Initiative (OSI), Licentiewijzer Europese Unie, Licentiewijzer MinBZK en Licentiewijzer GitHub.

Intellectuele eigendomsrechten

Zorg dat het vrijgeven van de open source software niet in strijd is met intellectuele eigendomsrechten en de auteursrechten. Zorg 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.

In standaard inkoopvoorwaarden, zoals de ARBIT, ARVODI of GIBIT wordt het intellectueel eigendom 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.

Het open source aanbesteden biedt een win-win situatie. De opdrachtgever kan onbeperkt doorontwikkelen en opdrachtnemers kunnen de ontwikkelde open source broncode in andere (commerciële) contexten hergebruiken.

Aansprakelijkheid

Maak 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 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.

Relevante documenten

Een aantal documenten die je kunnen helpen bij het inkopen van open source software:

Community Opensourcewerken

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