Open-source licentie compliance bij soevereine software-inkoop is het geheel van juridische, technische en organisatorische maatregelen waarmee een organisatie waarborgt dat alle open-source componenten in haar digitale werkplek worden gebruikt conform de auteursrechtelijke voorwaarden die de rechthebbenden hebben gesteld. Voor overheids- en gereguleerde sectoren is dit geen abstracte formaliteit: een licentieovertreding kan de juridische grondslag voor het gebruik van bedrijfskritische software ondermijnen.
Waarom licentie compliance centraal staat bij soevereine inkoop
Soevereine werkplekken, gebaseerd op open-source software, bieden een alternatief voor cloudplatformen die jurisdictionele risico’s meebrengen via Amerikaanse wetgeving zoals de CLOUD Act. Maar open-source is niet per definitie rechtenvrij. Elke open-source component wordt uitgebracht onder een specifieke licentie die bepaalt wat een gebruiker, aanpasser of aanbieder mag en moet doen.
Voor compliance officers in de publieke sector, de juridische wereld en gereguleerde branches is het beheersen van deze risico’s onderdeel van de bredere NIS-2- en GDPR-verplichtingen. Wie de eigen softwarestack niet kent, kan ook kwetsbaarheden niet systematisch adresseren.
De belangrijkste licentietypes en hun verplichtingen
Niet alle open-source licenties zijn gelijkwaardig. De juridische impact op uw organisatie hangt af van het licentietype en de manier waarop u de software inzet.
| Licentie | Copyleft-niveau | Broncode-verplichting bij SaaS-gebruik | Compatibel met propriëtaire software |
|---|---|---|---|
| MIT | Geen | Nee | Ja |
| Apache 2.0 | Geen | Nee | Ja |
| GPL v2/v3 | Sterk (bij distributie) | Nee (tenzij gekoppeld aan netwerk) | Nee |
| AGPL-3.0 | Sterk (inclusief netwerk) | Ja | Nee |
| EUPL v1.2 | Sterk (met compatibiliteitslijst) | Ja | Beperkt, via compatibiliteitslijst |
De AGPL-3.0 en het SaaS-vraagstuk
De AGPL-3.0 sluit de zogenoemde “SaaS-loophole” van de gewone GPL. Wie AGPL-gelicenseerde software over een netwerk aanbiedt aan gebruikers, ook zonder de software te distribueren in traditionele zin, is verplicht de volledige corresponderende broncode beschikbaar te stellen. Nextcloud wordt uitgebracht onder de AGPL, wat betekent dat elke organisatie of leverancier die Nextcloud als managed dienst aanbiedt de broncode actief toegankelijk moet maken. Wie dit nalaat, overtreedt het auteursrecht van de rechthebbenden en riskeert ontbinding van de licentie, met alle operationele en juridische gevolgen van dien.
De EUPL: een licentie voor Europees bestuur
De European Union Public Licence v1.2 (EUPL) is door de Europese Commissie ontwikkeld als de enige open-source licentie die juridisch geldig is in alle EU-lidstaten en is opgesteld in alle officiële EU-talen. Waar Amerikaanse licenties zoals Apache 2.0 en GPL zijn gebaseerd op Amerikaans auteursrecht en juridische begrippen, sluit de EUPL aan op Europese rechtsstelsels, inclusief civielrechtelijke tradities.
De Europese Commissie stelt via het Joinup-platform: “The EUPL is the only licence that has been drafted by legal experts in all EU official languages, making it the only open-source licence fully adapted to European contract and copyright law.” Dit maakt de EUPL bijzonder geschikt voor overheidssoftware die in meerdere lidstaten wordt ingezet of gedeeld.
De EUPL v1.2 is bovendien expliciet compatibel verklaard met een lijst van andere copyleft-licenties, waaronder GPL v2, GPL v3, LGPL en AGPL-3.0. Dit maakt het mogelijk om EUPL-code te combineren met componenten onder die licenties zonder directe juridische conflicten, mits de copyleft-verplichtingen van de ontvangende licentie worden gevolgd.
De Cyber Resilience Act en licentietransparantie
De Cyber Resilience Act (CRA), in 2024 gepubliceerd in het EU-publicatieblad, introduceert voor fabrikanten van producten met digitale elementen verplichtingen op het gebied van softwaretransparantie. Artikel 13 van de CRA verplicht fabrikanten een Software Bill of Materials (SBOM) beschikbaar te stellen voor hun producten. De toepassing van deze bepalingen is voorzien vanaf 2027.
Dit heeft directe gevolgen voor inkopers in gereguleerde sectoren: wie een managed dienst of softwareproduct afneemt, mag van leveranciers verlangen dat zij CRA-conform een SBOM aanleveren als onderdeel van het inkoopcontract.
De SBOM als handhavingsinstrument voor compliance officers
Een Software Bill of Materials is een gestructureerde inventarislijst van alle softwarecomponenten, hun versies, herkomst en bijbehorende licenties. De CISA (Cybersecurity and Infrastructure Security Agency) heeft in 2021 de zogenoemde “Minimum Elements for a Software Bill of Materials” gepubliceerd, bekend als de CISA 2026 Minimum Elements SBOM. Deze specificatie beschrijft zeven basisvelden: naam van de leverancier, naam van de component, versie, unieke identificator, afhankelijkheidsrelaties, auteur van de SBOM-data en tijdstempel.
CISA stelt hierover: “Software transparency is not optional. Organizations that cannot demonstrate what is in their software supply chain will find themselves unable to meet regulatory requirements and unable to maintain trust with their customers.”
Voor de technische uitwisseling van SBOM-gegevens is het SPDX-formaat (Software Package Data Exchange) van de Linux Foundation de meest gehanteerde standaard. SPDX wordt ook door de CRA en internationale normen erkend als geschikt formaat voor licentie-identificatie. SPDX-bestanden bevatten per component een SPDX-licentiecode, zoals “AGPL-3.0-only” of “Apache-2.0”, wat machine-leesbare verificatie mogelijk maakt.
Volgens een inventarisatie van de Linux Foundation uit 2022 had slechts 49% van de organisaties een volledig gedocumenteerde inventaris van hun open-source componenten. Dit gat is voor compliance officers een concreet risico: wie de eigen stack niet kent, kan bij een audit of incident niet aantonen dat licenties zijn nageleefd.
Hoe een compliance officer de inkoopcyclus inricht
In de praktijk betekent licentie compliance in de inkoopcyclus het volgende. Bij aanbesteding of contractering moeten leveranciers verplicht worden een actuele SBOM aan te leveren in SPDX- of CycloneDX-formaat. Het contract dient een licentiegarantieclausule te bevatten, waarbij de leverancier garandeert dat geen componenten worden gebruikt die in strijd zijn met de toepasselijke licentievoorwaarden. Bij elke materiële softwarewijziging moet een bijgewerkte SBOM worden aangeleverd.
Intern dient de compliance officer een register bij te houden van alle open-source componenten die de eigen organisatie direct inzet. Bij gebruik van AGPL-gelicenseerde software, zoals Nextcloud, moet worden gedocumenteerd hoe de broncode-verplichting wordt nageleefd: ofwel door zelf de broncode te publiceren, ofwel door te verwijzen naar de upstream-repository van de rechthebbende, mits geen aanpassingen zijn gemaakt.
Juridische risico’s bij niet-naleving van de AGPL
Wanneer een organisatie AGPL-gelicenseerde software inzet als netwerkdienst zonder de broncode beschikbaar te stellen, zijn de juridische consequenties concreet. De licentie vervalt automatisch bij schending, waardoor het gebruik onrechtmatig wordt op basis van het auteursrecht van de rechthebbende. Auteursrechthouders kunnen een stakingsvordering instellen bij de bevoegde rechter en schadevergoeding vorderen. In de Europese context is hierover in Duitsland, Nederland en Frankrijk jurisprudentie ontwikkeld, met name rond GPL-schendingen, waarbij rechters meerdere malen inbreukverboden hebben opgelegd.
Voor overheidsorganisaties en gereguleerde sectoren is reputatieschade een bijkomend risico: een auteursrechtschending op open-source software is publiekelijk traceerbaar en kan de geloofwaardigheid van de organisatie in het kader van NIS-2-naleving ondermijnen.
Praktische stappen voor een licentie-compliante soevereine werkplek
De overstap van een Big Tech-cloudplatform naar een soevereine open-source werkplek vereist dat licentie compliance structureel wordt ingebouwd, niet achteraf getoetst. Dat begint bij de selectie van software: kies componenten waarvan de licentie past bij het gebruik. Voor een intern gehoste Nextcloud-omgeving waarbij geen aanpassingen aan de broncode worden gemaakt, is de AGPL-3.0 in de meeste gevallen geen belemmering, mits de vereiste verwijzing naar de broncode intact blijft.
Vervolgens is automatisering van SBOM-generatie de meest effectieve maatregel. In een CI/CD-pipeline kunnen tools als Syft of SPDX-tools automatisch een SBOM genereren bij elke build of deployment, zodat de inventaris altijd actueel is. Dit maakt aantonen bij audits, onder NIS-2 of de CRA, aanzienlijk eenvoudiger.
Tot slot is bewustwording bij interne ontwikkelteams en leveranciersbeheerders essentieel. Licentieconflicten ontstaan het vaakst doordat ontwikkelaars onbewust een component toevoegen zonder de licentie te controleren. Een verplichte licentiescan als onderdeel van het acceptatieproces bij iedere softwarewijziging sluit dit gat structureel.
FAQ: open-source licentie compliance bij soevereine inkoop
Wat is het verschil tussen een AGPL-3.0 en een Apache 2.0 licentie voor een overheidsorganisatie?
AGPL-3.0 verplicht organisaties die software over een netwerk aanbieden de volledige broncode beschikbaar te stellen, ook als ze de software zelf niet distribueren. Apache 2.0 kent deze verplichting niet en staat gebruik in propriëtaire systemen toe zonder broncode-openbaarmaking. Dit geeft organisaties meer inrichtingsvrijheid, maar biedt minder juridische bescherming voor de open-source gemeenschap.
Is de EUPL v1.2 compatibel met de GPL?
Ja, de EUPL v1.2 is door de Europese Commissie expliciet compatibel verklaard met de GNU GPL v2 en v3, de LGPL en de AGPL. Dit maakt het combineren van EUPL-code met GPL-componenten juridisch mogelijk, mits de copyleft-verplichtingen van de ontvangende licentie worden nageleefd.
Wanneer is een SBOM juridisch verplicht onder de Cyber Resilience Act?
De Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen op grond van artikel 13 een SBOM beschikbaar te stellen. De toepassingsdatum is voorzien in 2027. Open-source projecten zonder commercieel oogmerk vallen buiten deze directe verplichting, maar commerciële inkopers die die componenten integreren zijn zelf verantwoordelijk voor de keten-inventarisatie.
Wat zijn de risico’s als een leverancier verzuimt AGPL-broncode beschikbaar te stellen?
Auteursrechthouders kunnen bij schending de licentie ontbinden, waardoor de inzet van de software onrechtmatig wordt. Dit kan leiden tot stakingsvorderingen, schadeclaims en reputatieschade. Inkopers die het nalaten van een leverancier niet detecteren, lopen mede juridisch risico als zij de software inzetten of doorleveren.
Hoe vaak moet een organisatie haar SBOM bijwerken?
Er is geen universeel wettelijk interval, maar de CISA Minimum Elements guidance schrijft voor dat een SBOM wordt bijgewerkt bij elke materiële wijziging van de software. In de praktijk hanteren gereguleerde organisaties een continuous-integration-aanpak waarbij de SBOM automatisch wordt gegenereerd bij iedere build, zodat de inventaris altijd de actuele staat van de software weerspiegelt.
