Cyber Resilience

Open source i jeres forretning: fabrikant, forvalter eller ingen af delene?

Open source i jeres forretning: fabrikant, forvalter eller ingen af delene?

Om jeres virksomhed har pligter efter CRA for et open source-projekt, afgøres projekt for projekt med tre spørgsmål i fast rækkefølge. Svaret kan være fabrikant, open source software-forvalter eller ingen rolle, og samme virksomhed kan have alle tre roller på én gang.

Rækkefølgen stammer fra Kommissionens vejledning C(2026) 5252 fra juli 2026. Den binder ingen, men den giver det mest udførlige bud på, hvordan open source skal behandles efter forordning (EU) 2024/2847. Pligterne for både fabrikanter og forvaltere gælder fra 11. december 2027.

Først: er det open source i forordningens forstand?

Begrebet er defineret i artikel 3, nr. 48. Kildekoden skal deles åbent, og licensen skal give alle rettigheder til at bruge, ændre og videregive softwaren frit. Vejledningen læser det som to betingelser, der begge skal være opfyldt. En kodebase under en åben licens, som kun betalende kunder kan se, falder derfor uden for definitionen. Vejledningen peger ikke på bestemte licenser.

Står et projekt uden for definitionen, er reglerne om forvaltere ikke i spil. Så er spørgsmålet alene, om softwaren er et produkt, I bringer i omsætning.

Spørgsmål 1: er projektet under jeres ansvar?

Ansvaret ligger hos den, der udgiver softwaren og har den primære kontrol over udvikling, releases og distribution. Vejledningen kalder dem vedligeholdere. Den, der sender kode ind uden at styre releases, køreplan eller beslutninger, har intet ansvar for projektet. Adgang til at committe flytter ikke ansvaret (vejledningens punkt 47-49 og eksempel 13).

Betragtning 18 siger det samme fra den anden side. Forordningen omfatter ikke personer, der bidrager med kildekode til open source, som de ikke selv er ansvarlige for.

For et softwarehus betyder det, at udviklere, der sender rettelser til andres projekter, ikke gør virksomheden ansvarlig for dem. Bygger virksomheden komponenten ind i sit eget produkt, er det i stedet pligten til at udvise omhu, når komponenter fra tredjeparter integreres, der gælder (artikel 13, stk. 5).

Spørgsmål 2: bringer I softwaren i omsætning?

Er projektet jeres, er næste spørgsmål, om det leveres som led i erhvervsvirksomhed. Betragtning 15 nævner kendetegn som en pris for produktet, en pris for teknisk support ud over de reelle omkostninger, indtjening via andre tjenester og krav om personoplysninger til andre formål end sikkerhed og kompatibilitet. Betragtning 18 tilføjer, at regelmæssige udgivelser ikke i sig selv er erhvervsvirksomhed, og at open source, som udgiveren ikke tjener penge på, heller ikke er det.

Er svaret ja, er virksomheden fabrikant for netop det projekt og har pligterne efter artikel 13 og 14.

Spørgsmål 3: yder I vedvarende støtte som juridisk person?

Er svaret nej, kommer det sidste spørgsmål. En juridisk person, der systematisk og vedvarende støtter open source beregnet til kommercielle aktiviteter og sikrer projektets levedygtighed, er forvalter (artikel 3, nr. 14). Forvalteren har de lettere pligter i artikel 24. Kun juridiske personer kan have rollen. En privatperson, der passer et projekt i sin fritid, er uden for begrebet.

Er heller ikke dette opfyldt, har virksomheden ingen pligter efter forordningen for projektet.

Sponsorater flytter ikke rollen

Mange projekter lever af sponsorer. Vejledningen siger, at finansiering ikke i sig selv afgør, om softwaren er bragt i omsætning (punkt 63-65). Den virksomhed, der betaler for et projekt og bygger det ind i sit eget produkt, bliver ikke fabrikant af projektet. Den skal vise omhu efter artikel 13, stk. 5, når komponenten tages ind.

Opgørelsen pr. projekt

Rollen hører til projektet. Vejledningen siger udtrykkeligt, at samme juridiske person kan være fabrikant for ét projekt og forvalter for et andet (punkt 72-74). Det er derfor almindelig praksis at føre en opgørelse over alle projekter, virksomheden udgiver eller styrer. Forordningen kræver ikke listen, men den er den letteste måde at vise, at rollen er vurderet.

En opgørelse kan have disse felter. Indholdet i parentes er tænkte eksempler.

  • Projekt · (internt UI-bibliotek, lagt i et offentligt repositorium)
  • Licens og kildekode · (åben licens, koden delt offentligt)
  • Hvem styrer releases · (to ansatte udviklere)
  • Indtægt knyttet til projektet · (ingen, bruges i egen betalt app)
  • Vurderet rolle · (forvalter)
  • Begrundelse og dato · (vejledningens rækkefølge, vurderet i marts 2027)

Opgørelsen bør følge forretningsmodellen. Begynder virksomheden at tage betaling for et projekt, skifter rollen fra den dag.

Hvad det kræver, og hvad det koster at lade være

Det kræver en gennemgang af alle offentlige repositorier og en ejer, der kan svare på, hvem der styrer releases, og hvor pengene kommer fra. For de fleste softwarehuse er det et overskueligt stykke arbejde.

Uden opgørelsen kan et projekt blive behandlet som en sidegevinst, mens en markedsovervågningsmyndighed ser en fabrikant uden teknisk dokumentation. Det modsatte kan også ske. Så bruges kræfterne på fabrikantpligter for kode, hvor forvalterens lettere krav havde været nok.

Det skal I lade være med

  • At give hele virksomheden én rolle · vurderingen gælder projekt for projekt.
  • At regne commit-adgang som ansvar · kontrollen med releases er det afgørende.
  • At kalde kode open source, når kun kunder kan se den · begge betingelser i artikel 3, nr. 48, skal være opfyldt.

Det skal auditten kunne vise

  • ☐ En liste over de projekter, virksomheden udgiver eller styrer.
  • ☐ For hvert projekt: licens, om koden er offentlig, og hvem der styrer releases.
  • ☐ En dateret vurdering af rollen efter vejledningens tre spørgsmål.
  • ☐ En markering af de projekter, der indgår i egne betalte produkter.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find alle offentlige repositorier, virksomheden står som udgiver af, og skriv rollen for hvert enkelt ned.

Læs også: Community-udgave og betalt udgave · Et bibliotek, I udgiver uden at tjene på det

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.