Open source bij de overheid en de EUPL

Open, tenzij is een beleidslijn, geen wet. Digitale Overheid, het kennisplatform van het Rijk, omschrijft het zo:

De overheid volgt het beleid ‘Open, tenzij’: software van de overheid moet zoveel mogelijk open source zijn, behalve als er goede redenen zijn om de software niet beschikbaar te maken.

Bron: Digitale Overheid, pagina Beleid Opensourcewerken (laatst gewijzigd 6 augustus 2026). De beleidslijn komt uit de Kamerbrief Vrijgeven van de broncode van overheidssoftware van 17 april 2020:

"Het uitgangspunt van deze brief is dan ook: «open, tenzij». Mijn oproep aan overheden is om de broncode vrij te geven, tenzij er gegronde redenen zijn om het niet te doen, bijvoorbeeld als de belangen van nationale of openbare veiligheid zich daartegen verzetten of de benodigde vertrouwelijke werkwijze van de overheid, denk aan opsporing en toezicht, worden geschaad."

Bron: Kamerstuk 26 643, nr. 676, brief van de staatssecretaris van BZK, 17 april 2020, gelezen op 11 oktober 2026. Dezelfde brief vraagt organisaties per geval in te schatten of de maatschappelijke baten van openstelling ten minste opwegen tegen de kosten.

Drie punten zijn voor een gemeente van belang. Het beleid richt zich op software die de overheid zelf laat ontwikkelen; het gaat dus niet over elk pakket dat zij koopt. "Beschikbaar maken" is ook iets anders dan "een community onderhouden". Digitale Overheid onderscheidt drie niveaus: de code beschikbaar maken, feedback verwerken en actief samenwerken met een community, en adviseert klein te beginnen en later uit te bouwen. Ten slotte is het een oproep, geen afdwingbare norm: de brief spreekt van een "oproep aan overheden".

Voor inkopers is de praktische kant belangrijker dan de beleidstekst. Open source verkleint de afhankelijkheid van één leverancier, maar alleen als documentatie, licentie en onderhoud goed geregeld zijn. Hoe u die afhankelijkheid contractueel afdekt, staat op de pagina vendor lock-in en exitstrategie.

De European Union Public Licence (EUPL) is een open source-licentie die de Europese Commissie heeft ontwikkeld voor software van overheden. Versie 1.2 bestaat in 23 officiële taalversies, waaronder het Nederlands; alle goedgekeurde taalversies hebben volgens artikel 13 dezelfde waarde. Het ontwikkelaarsportaal van de Nederlandse overheid schrijft:

De EUPL is binnen veel overheidsinstellingen beleidsmatig de standaardkeuze voor werken die geproduceerd zijn met publiek geld.

Bron: developer.overheid.nl, tutorial Een licentie kiezen. De EUPL is een copyleft-licentie. Volgens artikel 5 moet wie kopieën van het oorspronkelijke werk of van een afgeleid werk verspreidt of mededeelt, dat doen onder dezelfde licentie of een latere versie, tenzij het origineel uitdrukkelijk alleen onder 1.2 wordt verspreid. Daar staat een compatibiliteitsclausule tegenover: een afgeleid werk dat ook op een werk onder een "compatibele licentie" is gebaseerd, mag onder die andere licentie worden verspreid. De lijst met compatibele licenties staat in het aanhangsel.

Een licentie met permissieve voorwaarden, zoals MIT of BSD, staat niet in dit aanhangsel. Dat betekent niet dat u zulke bibliotheken niet kunt gebruiken; het betekent dat u per afhankelijkheid moet beoordelen onder welke voorwaarden het geheel gedistribueerd mag worden. Laat dat bij een publicatie door een jurist of een open source-deskundige toetsen.

De Gemeentelijke Inkoopvoorwaarden bij IT (GIBIT) 2025 van de VNG hebben een eigen hoofdstuk IV, Open Source, met artikel 40 tot en met 46. De definitie in artikel 1.35 noemt open source-programmatuur software waarvan de broncode openbaar beschikbaar is en die wordt verspreid onder een licentie die het recht geeft de software te gebruiken, te bestuderen, te wijzigen en te distribueren, zonder dat daarvoor licentiekosten verschuldigd zijn.

• Rechten (artikel 41). De leverancier stelt de broncode ter beschikking en de intellectuele eigendomsrechten berusten bij de opdrachtgever. Beide gebeuren op het moment van publicatie in de repository. De leverancier garandeert dat er geen derdenprogrammatuur is gebruikt die de verplichtingen uit het hoofdstuk in de weg staat.
• Repository (artikel 42). De broncode wordt gepubliceerd op een Git-ondersteunend platform of een andere openbaar toegankelijke repository.
• Licentie (artikel 43). De opdrachtgever stelt de broncode kosteloos beschikbaar aan het algemene publiek onder de EUPL versie 1.2 of hoger. Is een afhankelijkheid onverenigbaar met de EUPL, dan maken partijen aanvullende afspraken en meldt de leverancier dat risico in zijn aanbod.

Dit geeft een gemeente die maatwerk laat bouwen een standaardroute: de code komt in een openbare repository, onder de EUPL, met de rechten bij de gemeente. Zie voor de bredere afweging maatwerk of standaard software en maatwerk software. Dit hoofdstuk geldt aanvullend als (delen van) de prestatie als open source-programmatuur wordt opgeleverd.

publiccode.yml is een metadatastandaard voor repositories met software van of voor de overheid, bedoeld om die software vindbaar en herbruikbaar te maken. Het bestand staat in de root van de repository. Volgens de standaard is het verplicht voor alle publieke software in Italië en wordt het ook gebruikt door het Duitse register opencode.de; de huidige versie is 0.7.0. Het ontwikkelaarsportaal beschrijft het als machineleesbaar bestand waarmee open source-catalogi uw project kunnen vinden.

Onderstaand voorbeeld is een fictief project. Valideer een echt bestand vóór publicatie, met de controle-tool van het ontwikkelaarsportaal of tegen het JSON Schema van publiccode.yml in SchemaStore.

publiccodeYmlVersion: "0.7.0"
name: Voorbeeld kaartviewer
url: "https://code.example.nl/gemeente/kaartviewer.git"
softwareType: "standalone/web"
developmentStatus: beta
platforms:
  - web
categories:
  - geographic-information-systems
legal:
  license: EUPL-1.2
  repoOwner: Gemeente Voorbeeld
maintenance:
  type: internal
  contacts:
    - name: Team Geo-informatie
      email: geo@voorbeeld.example
description:
  nl:
    shortDescription: Kaartviewer voor beleidsmedewerkers
    longDescription: >
      Fictief voorbeeld van een kaartviewer die gemeentelijke geodata toont
      via open standaarden.
    features:
      - Kaartlagen tonen via WMTS en OGC API Features
localisation:
  localisationReady: true
  availableLanguages:
    - nl

Het portaal raadt aan het bestand toe te voegen, te valideren met de don-checker en de validatie in de CI-pipeline op te nemen. Deze velden zijn op dit moment de moeite waard om zorgvuldig in te vullen: de licentie (EUPL-1.2), de onderhoudsstatus en het contactpunt. Ze bepalen of een andere gemeente de code durft te hergebruiken.

Er zijn drie voorzieningen om te kennen. De eerste is code.overheid.nl, het codeplatform voor de Nederlandse overheid, dat volgens eigen informatie kosteloos is voor alle overheidsorganisaties, op Nederlandse overheidsinfrastructuur draait en Forgejo gebruikt. Digitale Overheid meldt het platform op 26 april 2026 als online. De tweede is het Open Source Register op oss.developer.overheid.nl, een register van repositories van overheden, waar u een repository kunt laten opnemen. De derde is de Standaard voor Publieke Code van de Foundation for Public Code, een set van 16 criteria voor codebases van overheden, zoals het openbaar houden van de code, het documenteren van doelen en maturiteit en het welkom heten van bijdragers.

Een Open Source Program Office (OSPO) is een functie in een organisatie die open source werken intern aanjaagt: beleid, licenties, contact met communities en kennisdeling. Over de OSPO-functie schrijft Digitale Overheid: "Deze functionaris is verantwoordelijk voor het bevorderen van opensourcewerken."

Op 1 oktober 2026 ondertekenden de Rijksoverheid, provincies, gemeenten en SURF tijdens de Leiderschapstop OpenSource een intentieverklaring om structureler met open source te werken. Digitale Overheid meldde dat op 2 oktober 2026. Daarin zetten de partijen onder meer in op een OSPO-functie bij elke deelnemende organisatie en een nationaal netwerk om kennis en ervaringen te delen, waarbij andere organisaties later kunnen aansluiten. Of uw gemeente een eigen OSPO nodig heeft, hangt af van de omvang van uw ontwikkelwerk; voor een kleine gemeente kan het volstaan om de verantwoordelijkheid bij een bestaande functie te beleggen en aan te sluiten op het netwerk.

Voor geo-informatie is de combinatie met open data en open standaarden de logische start: kaartcomponenten, viewers en scripts zijn goed te publiceren omdat ze weinig bedrijfsgevoelige logica bevatten. Zie ook GIS-viewer kiezen en ArcGIS naar open source, en de achtergrond bij Common Ground.

Een organisatie die zelf software laat ontwikkelen heeft andere keuzes dan een organisatie die vooral pakketten gebruikt. Wie maatwerk laat bouwen, regelt in het contract dat de code onder de EUPL in een repository komt (GIBIT hoofdstuk IV) en dat een publiccode.yml wordt meegeleverd. Wie een open source-pakket gebruikt, let op de licentie van het pakket, op wie het onderhoudt en op wat er gebeurt als die partij stopt. Wie een eigen component deelt, zoals een kaartwidget, kiest de lichtste vorm van open source werken en maakt de code beschikbaar zonder meteen een community op te zetten.

Bij elke publicatie hoort een controle op wat niet openbaar mag: wachtwoorden, sleutels, interne adressen en persoonsgegevens in testdata. Vooral oude commits blijven zichtbaar. Een geslaagde publicatie begint daarom met een schone repository.

Belangenverklaring: TechinFlow bouwt zelf software met de focus op overheden en kan dus belang hebben bij het gebruik van open source in opdrachten. Deze pagina is geen juridisch advies; laat licentie-, aansprakelijkheids- en inkoopvragen door een jurist toetsen. De hulp bij een keuze staat bij technologie- en softwareadvies; de sectorcontext staat op gemeenten.