De vraag komt in drie vormen, en de Cyber Resilience Act, Verordening (EU) 2024/2847, beantwoordt elk anders. Een maintainer die een bibliotheek op GitHub publiceert. Een bedrijf waarvan het product op die bibliotheek is gebouwd. Een stichting die de bibliotheek in leven houdt. Slechts een van de drie is fabrikant, en een van de andere heeft een eigen regime.

Geval één: opensourcesoftware die niet te gelde wordt gemaakt

Overweging 18: "alleen vrije en opensourcesoftware die in de handel is gebracht, en dus voor distributie of gebruik in het kader van een commerciële activiteit wordt geleverd, dient binnen de werkingssfeer van deze verordening te vallen." En preciezer: "het aanbieden van producten met digitale elementen die als vrije en opensourcesoftware kwalificeren en die niet door hun fabrikanten te gelde worden gemaakt, dient niet als een commerciële activiteit te worden beschouwd."

Overweging 20 voegt toe dat hosting op een repository, een pakketbeheerder of een samenwerkingsplatform "op zich niet het in de handel brengen vormt", en overweging 18 dat ook de wijze waarop de ontwikkeling is gefinancierd de vraag niet beslist.

Een bibliotheek die onder een open licentie wordt gepubliceerd, zonder betaalde versie, zonder daaraan gekoppelde betaalde ondersteuning of een commerciële regeling rond de levering, valt dus buiten de fabrikantverplichtingen. De auteur hoeft geen CE-markering aan te brengen, heeft geen technisch dossier en geen plicht onder artikel 14. Artikel 15 laat vrijwillig melden van kwetsbaarheden toe; niets vereist het.

Geval twee: een commercieel product gebouwd op opensourcecomponenten

Het bedrijf dat die bibliotheek integreert in een product dat het in de handel brengt, is fabrikant van dat product. De licentie van de component verandert niets. Bijlage I geldt voor het hele product, de SBOM vermeldt de component, en artikel 13, lid 5, verplicht de fabrikant tot zorgvuldigheid bij het integreren van componenten van derden, ook opensource, zodat zij de beveiliging van het product niet in gevaar brengen.

Artikel 32, lid 5, geeft één verlichting: een vrij en opensourceproduct dat in een categorie van bijlage III valt, mag nog steeds de zelfbeoordelingsprocedure gebruiken, mits de technische documentatie openbaar wordt gemaakt bij het in de handel brengen. Dat geldt voor opensourceproducten die zelf commercieel in de handel worden gebracht, niet voor de componenten in een propriëtair product.

Overweging 21 voorziet in vrijwillige beveiligingsattesteringsprogramma's voor opensourcecomponenten, zodat de zorgvuldigheid van een fabrikant ergens op kan steunen. Er is er nog geen ingesteld.

Geval drie: de beheerder van opensourcesoftware

Artikel 3, punt 14, definieert een beheerder als "een rechtspersoon, anders dan een fabrikant, die tot doel of oogmerk heeft systematisch en duurzaam ondersteuning te bieden voor de ontwikkeling van specifieke producten met digitale elementen die als vrije en opensourcesoftware kwalificeren en bestemd zijn voor commerciële activiteiten, en die de levensvatbaarheid van die producten waarborgt". Overweging 19 noemt het soort: bepaalde stichtingen, en entiteiten die in een bedrijfscontext vrije en opensourcesoftware ontwikkelen en publiceren, met inbegrip van entiteiten zonder winstoogmerk.

"Bestemd voor commerciële activiteiten" is de spil. Overweging 19 zegt dat dit integratie in commerciële diensten of te gelde gemaakte producten omvat, en dat het oogmerk bestaat wanneer fabrikanten die de component integreren regelmatig aan de ontwikkeling bijdragen of die regelmatig financieren. Een stichting waarvan het project in commerciële producten door de hele sector is ingebouwd, is een beheerder. Een hobbyproject zonder zo'n relatie niet.

Artikel 24 geeft beheerders een regime dat de verordening zelf licht noemt:

Een cyberbeveiligingsbeleid, verifieerbaar gedocumenteerd (artikel 24, lid 1), dat veilige ontwikkeling en doeltreffend kwetsbaarheidsbeheer door de ontwikkelaars van het project bevordert, inclusief het documenteren, aanpakken en verhelpen van kwetsbaarheden, het delen van informatie over ontdekte kwetsbaarheden binnen de gemeenschap, en het aanmoedigen van vrijwillige melding onder artikel 15.

Samenwerking met markttoezichtautoriteiten op hun verzoek (artikel 24, lid 2), en het verstrekken van dat beleid aan een autoriteit op gemotiveerd verzoek.

Een beperkt artikel 14. Artikel 24, lid 3: de plicht om actief uitgebuite kwetsbaarheden te melden geldt voor beheerders "voor zover zij betrokken zijn bij de ontwikkeling" van het product; de plicht om ernstige incidenten te melden, en gebruikers te informeren, geldt "voor zover ernstige incidenten ... netwerk- en informatiesystemen treffen die de beheerders van opensourcesoftware voor de ontwikkeling van dergelijke producten ter beschikking stellen". De klokken zijn dezelfde 24 en 72 uur, aan hetzelfde CSIRT en ENISA.

Wat een beheerder niet heeft: verplichtingen van bijlage I voor het product, een technisch dossier, een conformiteitsbeoordeling, een CE-markering, een conformiteitsverklaring, een ondersteuningsperiode. Artikel 24 is het geheel. En artikel 64, lid 10, onder b), zegt dat de administratieve boetes van artikel 64 "niet van toepassing zijn op" inbreuken op de verordening door beheerders van opensourcesoftware; de andere corrigerende maatregelen van een markttoezichtautoriteit blijven.

Wat te beslissen, en op te schrijven

Welk geval u bent. Als u opensource publiceert en er niets omheen te gelde maakt, schrijf dat op, met datum, want "niet te gelde gemaakt" is een feit over uw bedrijf dat kan veranderen. Als u een product op opensourcecomponenten levert, zit u in geval twee en gelden de twaalf stappen volledig. Als u een project in stand houdt waarvan commerciële producten afhangen, bent u beheerder: schrijf het beleid van artikel 24, lid 1, benoem de persoon die een autoriteit antwoordt, en beslis hoe u van een actief uitgebuite kwetsbaarheid in het project zou vernemen en die zou melden.

De richtsnoeren van de Commissie van 27 juli 2026 maken van de twee overwegingen zeven toetsen met 22 uitgewerkte voorbeelden: waar een donatielink, een betaald ondersteuningsniveau, een open-core-editie en een stichting elk belanden is het bijbehorende artikel bij dit artikel.

Bronnen

  • Verordening (EU) 2024/2847, artikel 3, punt 14 (geciteerd), artikel 13, lid 5, artikel 15, artikel 24, leden 1 tot en met 3 (geciteerd), artikel 32, lid 5, artikel 64, lid 10, onder b); overwegingen 17 tot en met 21 (geciteerd). Gelezen in de tekst van het Publicatieblad op EUR-Lex op 11 september 2026.

Dit is geen juridisch advies. De overwegingen zijn waar de opensourcegrens wordt getrokken, en ze zijn hierboven geciteerd zodat u ze kunt lezen in plaats van onze lezing over te nemen.