Har I en community-udgave uden licensbetaling og en betalt udgave bygget på samme kode, ser CRA dem som to forskellige produkter. Den betalte udgave gør jer til fabrikant, og community-udgaven gør jer som juridisk person til open source software-forvalter.
Sådan læser Kommissionen reglerne i vejledningen C(2026) 5252, punkt 52 og 53, som ikke er bindende. Fabrikantens og forvalterens pligter gælder fra 11. december 2027. Meldepligten i artikel 14 om aktivt udnyttede sårbarheder og alvorlige hændelser har derimod været gældende siden 11. september 2026 for den betalte udgave, hvis den er bragt i omsætning.
Samme kodebase, to produkter
Vejledningen tager stilling til den situation, mange softwarehuse står i. En udgave uden betaling og en betalt udgave med næsten samme kodebase er forskellige produkter. Den betalte er bragt i omsætning og udløser fabrikantens pligter. Community-udgaven er ikke bragt i omsætning.
Det gælder også open core, hvor den betalte udgave bygger videre på den åbne eller indlejrer den.
Hvem udgiver community-udgaven? Er det en juridisk person, gælder forvalterens pligter i artikel 24 for den. Er udgiveren en fysisk person, er community-udgaven helt uden for forordningen (vejledningens punkt 53, 72 og 76). For et dansk softwarehus organiseret som selskab vil det første normalt være tilfældet.
To sæt krav
Kravene er af forskellig art. Som fabrikant af den betalte udgave skal I bl.a. lave en cybersikkerhedsrisikovurdering (artikel 13, stk. 2), opfylde bilag I, del II, om håndtering af sårbarheder, udarbejde teknisk dokumentation efter bilag VII og gennemføre en overensstemmelsesvurdering, før produktet bringes i omsætning.
Som forvalter af community-udgaven skal I have en cybersikkerhedspolitik, der er skrevet ned, så andre kan efterprøve den (artikel 24, stk. 1). Politikken skal navnlig dække dokumentation, håndtering og afhjælpning af sårbarheder og fremme udveksling af oplysninger om sårbarheder i open source-samfundet. Hertil kommer samarbejde med markedsovervågningsmyndigheden efter stk. 2.
Forvalteren må ikke sætte CE-mærkning på de produkter, den støtter (betragtning 19). CE-mærket hører kun til den betalte udgave.
Én proces, to spor
Hvordan dokumentation og sårbarhedshåndtering holdes adskilt uden at blive to processer, står ikke i nogen af kilderne. Det, der følger her, er praksis og vores forslag til en ordning.
Den fælles kerne er stedet, hvor de fleste sårbarheder opstår. En melding om en fejl i kernen rammer begge udgaver. Det er derfor almindeligt at have én indgang for meldinger og ét register, hvor hver sag markeres med de udgaver, den berører.
For den betalte udgave skal sagen håndteres efter bilag I, del II, med de krav om dokumentation, afhjælpning og offentliggørelse, der følger deraf. For community-udgaven er det forvalterens politik, der bestemmer, hvordan sagen behandles. I praksis kan rettelsen være den samme kode, men sporet efter den skal kunne aflæses for hvert produkt.
Den tekniske dokumentation for den betalte udgave beskriver hele produktet, også den fælles kerne. Softwarekomponentlisten indgår i dokumentationen efter bilag VII, nr. 2. Community-udgaven får ikke en teknisk dokumentation efter bilag VII, fordi den ikke er et produkt, I bringer i omsætning.
Pas på de skjulte overgange
Grænsen kan flytte sig uden en bevidst beslutning. Vejledningen siger, at adgang til en bestemt udgave med fordele som teknisk bistand eller ydelsesoptimering er at bringe i omsætning, når adgangen kræver betaling (punkt 57). Begynder community-udgaven at få sikkerhedsrettelser senere end den betalte, eller kun mod betaling, kan rollen være ændret. Det er en tolkning af punkt 57 og vejledningens eksempler om donationer, og den skal vurderes konkret.
Et andet faresignal er, når salgsmateriale beskriver community-udgaven som en prøveversion af det betalte produkt. Så bør det undersøges, om den i virkeligheden er en del af det kommercielle tilbud.
Hvad det kræver, og hvad det koster at lade være
Det kræver en klar beskrivelse af, hvad der hører til hvilken udgave, og et sårbarhedsregister, der kan vise begge spor. De fleste softwarehuse har allerede et register, så arbejdet ligger i markeringen og i at holde forvalterpolitikken ajour.
Uden adskillelsen bliver det svært at svare en myndighed, der spørger til den betalte udgave. Blandes sporene, kan forvalterens lettere ordning også komme til at hvile på en udgave, der i realiteten er kommerciel.
Det skal I lade være med
- At sætte CE-mærket på community-udgaven · forvaltere må ikke anbringe CE-mærkning.
- At bygge to sårbarhedsprocesser · én indgang med markering pr. udgave er nok til at vise begge spor.
- At lade rettelser til community-udgaven følge betalingen · det kan ændre udgavens rolle.
Det skal auditten kunne vise
- ☐ En beskrivelse af, hvilke dele af kodebasen der hører til hver udgave.
- ☐ Teknisk dokumentation for den betalte udgave, der også dækker den fælles kerne.
- ☐ En dokumenteret cybersikkerhedspolitik for community-udgaven efter artikel 24, stk. 1.
- ☐ Et sårbarhedsregister, hvor hver sag er markeret med de udgaver, den berører.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 2, artikel 24, stk. 1-2, bilag I, del II, bilag VII og betragtning 19, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 52-53, 57, 72 og 76, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag de seneste ti sårbarhedssager, og se, om det fremgår, hvilke udgaver hver sag berørte.
Læs også: Fabrikant, forvalter eller ingen af delene? · Alle sårbarheder skal håndteres, ikke alle skal rettes
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
