Spørgsmålet kommer i tre former, og Cyber Resilience Act, forordning (EU) 2024/2847, besvarer hver af dem forskelligt. En maintainer, der udgiver et bibliotek på GitHub. En virksomhed, hvis produkt er bygget på det bibliotek. En fond, der holder biblioteket i live. Kun én af de tre er fabrikant, og én af de andre har sin egen ordning.

Tilfælde ét: open source-software, der ikke monetariseres

Betragtning 18: "Kun fri og open source-software, der gøres tilgængelig på markedet og dermed leveres til distribution eller anvendelse som led i en kommerciel aktivitet, bør være omfattet af denne forordning." Og mere præcist: "Levering af produkter med digitale elementer, der betragtes som fri og open source-software, og som ikke monetariseres af deres fabrikanter, bør ikke betragtes som en kommerciel aktivitet."

Betragtning 20 tilføjer, at hosting i et arkiv, en pakkehåndtering eller på en samarbejdsplatform "ikke i sig selv udgør tilgængeliggørelse på markedet", og betragtning 18, at heller ikke finansieringen af udviklingen afgør spørgsmålet.

Et bibliotek udgivet under en åben licens, uden betalt version, uden betalt support knyttet til det eller en kommerciel aftale omkring leveringen, ligger altså uden for fabrikantforpligtelserne. Dets ophavsmand har intet CE-mærke at anbringe, ingen teknisk dokumentation, ingen pligt efter artikel 14. Artikel 15 lader vedkommende indberette sårbarheder frivilligt; intet kræver det.

Tilfælde to: et kommercielt produkt bygget på open source-komponenter

Den virksomhed, der integrerer det bibliotek i et produkt, den bringer i omsætning, er fabrikant af det produkt. Komponentens licens ændrer intet. Bilag I gælder for hele produktet, SBOM'en opfører komponenten, og artikel 13, stk. 5, kræver, at fabrikanten udviser rettidig omhu ved integration af komponenter fra tredjeparter, herunder open source, så de ikke kompromitterer produktets sikkerhed.

Artikel 32, stk. 5, giver én lettelse: Et frit og open source-produkt, der falder i en kategori i bilag III, kan stadig bruge selvvurderingsproceduren, forudsat at dets tekniske dokumentation gøres offentlig, når produktet bringes i omsætning. Det gælder open source-produkter, der selv bringes kommercielt i omsætning, ikke komponenterne inde i et proprietært produkt.

Betragtning 21 forudser frivillige sikkerhedsattesteringsprogrammer for open source-komponenter, så en fabrikants omhu har noget at støtte sig til. Ingen er endnu etableret.

Tilfælde tre: forvalteren af open source-software

Artikel 3, nr. 14, definerer en forvalter som "en juridisk person, bortset fra en fabrikant, som har til formål eller mål systematisk at yde vedvarende støtte til udviklingen af specifikke produkter med digitale elementer, der betragtes som fri og open source-software og er beregnet til kommercielle aktiviteter, og som sikrer disse produkters levedygtighed". Betragtning 19 nævner typen: visse fonde og enheder, der udvikler og udgiver fri og open source-software i en forretningsmæssig sammenhæng, herunder nonprofitenheder.

"Beregnet til kommercielle aktiviteter" er omdrejningspunktet. Betragtning 19 siger, at det omfatter integration i kommercielle tjenester eller monetariserede produkter, og at hensigten foreligger, hvor fabrikanter, der integrerer komponenten, regelmæssigt bidrager til dens udvikling eller regelmæssigt finansierer den. En fond, hvis projekt er indlejret i kommercielle produkter på tværs af branchen, er forvalter. Et hobbyprojekt uden en sådan relation er det ikke.

Artikel 24 giver forvaltere en ordning, som forordningen selv kalder let:

En cybersikkerhedspolitik, dokumenteret på verificerbar vis (artikel 24, stk. 1), der fremmer sikker udvikling og effektiv håndtering af sårbarheder hos projektets udviklere, herunder dokumentation, håndtering og afhjælpning af sårbarheder, deling af oplysninger om opdagede sårbarheder i fællesskabet og tilskyndelse til frivillig indberetning efter artikel 15.

Samarbejde med markedsovervågningsmyndigheder på deres anmodning (artikel 24, stk. 2), og udlevering af politikken til en myndighed på begrundet anmodning.

En indsnævret artikel 14. Artikel 24, stk. 3: Pligten til at anmelde aktivt udnyttede sårbarheder gælder for forvaltere, "i det omfang de er involveret i udviklingen" af produktet; pligten til at anmelde alvorlige hændelser og informere brugerne gælder, "i det omfang alvorlige hændelser ... påvirker net- og informationssystemer, som forvalterne af open source-software stiller til rådighed for udviklingen af sådanne produkter". Urene er de samme 24 og 72 timer, til det samme CSIRT og ENISA.

Hvad en forvalter ikke har: forpligtelser efter bilag I for produktet, en teknisk dokumentation, en overensstemmelsesvurdering, en CE-mærkning, en overensstemmelseserklæring, en supportperiode. Artikel 24 er det hele. Og artikel 64, stk. 10, litra b, siger, at artikel 64's administrative bøder "ikke finder anvendelse på" forvaltere af open source-softwares overtrædelser af forordningen; en markedsovervågningsmyndigheds øvrige afhjælpende foranstaltninger består.

Hvad I skal beslutte og skrive ned

Hvilket tilfælde I er. Udgiver I open source og monetariserer intet omkring det, så skriv det ned med dato, for "ikke monetariseret" er en kendsgerning om jeres forretning, der kan ændre sig. Leverer I et produkt på open source-komponenter, er I i tilfælde to, og de tolv trin gælder fuldt ud. Understøtter I et projekt, som kommercielle produkter afhænger af, er I forvalter: Skriv politikken efter artikel 24, stk. 1, navngiv den person, der svarer en myndighed, og beslut, hvordan I ville få kendskab til og anmelde en aktivt udnyttet sårbarhed i projektet.

Kommissionens vejledning af 27. juli 2026 gør de to betragtninger til syv tests med 22 gennemregnede eksempler: hvor et donationslink, et betalt supportniveau, en open core-udgave og en fond hver især lander, er ledsageartiklen til denne.

Kilder

  • Forordning (EU) 2024/2847, artikel 3, nr. 14 (citeret), artikel 13, stk. 5, artikel 15, artikel 24, stk. 1 til 3 (citeret), artikel 32, stk. 5, artikel 64, stk. 10, litra b; betragtning 17 til 21 (citeret). Læst i EU-Tidende-teksten på EUR-Lex den 11. september 2026.

Dette er ikke juridisk rådgivning. Betragtningerne er der, hvor open source-grænsen trækkes, og de er citeret ovenfor, så I kan læse dem i stedet for at tage vores læsning for gode varer.