[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:da:gaelder-cra-for-open-source-software":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"da","gaelder-cra-for-open-source-software","Gælder CRA for open source-software? Tre tilfælde, og den lette ordning for forvaltere","Cyber Resilience Act når fri og open source-software kun, når den leveres som led i en kommerciel aktivitet. Et projekt, der ikke monetariseres, er ude. En virksomhed, der leverer et produkt bygget på open source-komponenter, er fabrikant af det produkt. Og fonde og virksomheder, der understøtter open source-produkter til kommerciel brug, er \\\"forvaltere af open source-software\\\" efter artikel 24: en cybersikkerhedspolitik, samarbejde med myndigheder og en indsnævret anmeldelsespligt, uden CE-mærkning og uden teknisk dokumentation. Betragtningerne og artiklen, citeret.","2026-09-11","\nSpørgsmålet kommer i tre former, og Cyber Resilience Act, forordning (EU) 2024\u002F2847, 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.\n\n## Tilfælde ét: open source-software, der ikke monetariseres\n\nBetragtning 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.\"\n\nBetragtning 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.\n\nEt 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.\n\n## Tilfælde to: et kommercielt produkt bygget på open source-komponenter\n\nDen virksomhed, der integrerer det bibliotek i et produkt, den bringer i omsætning, er fabrikant af det produkt. Komponentens licens ændrer intet. [Bilag I](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) gælder for hele produktet, [SBOM'en](\u002Farticles\u002Fdoes-the-cra-require-an-sbom) 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.\n\nArtikel 32, stk. 5, giver én lettelse: Et frit og open source-produkt, der falder i en [kategori i bilag III](\u002Farticles\u002Fis-your-product-important-or-critical-under-the-cyber-resilience-act), 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.\n\nBetragtning 21 forudser frivillige sikkerhedsattesteringsprogrammer for open source-komponenter, så en fabrikants omhu har noget at støtte sig til. Ingen er endnu etableret.\n\n## Tilfælde tre: forvalteren af open source-software\n\nArtikel 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.\n\n\"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.\n\nArtikel 24 giver forvaltere en ordning, som forordningen selv kalder let:\n\n**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.\n\n**Samarbejde med markedsovervågningsmyndigheder** på deres anmodning (artikel 24, stk. 2), og udlevering af politikken til en myndighed på begrundet anmodning.\n\n**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](\u002Farticles\u002Fcra-final-report-clock-does-not-start-when-you-become-aware), til [det samme CSIRT](\u002Farticles\u002Fwhich-csirt-do-you-report-to-under-cra-article-14) og ENISA.\n\nHvad 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.\n\n## Hvad I skal beslutte og skrive ned\n\nHvilket 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](\u002Farticles\u002Fthe-cyber-resilience-act-for-a-small-software-manufacturer-in-twelve-steps) 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.\n\nKommissionens 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](\u002Farticles\u002Fis-your-open-source-project-commercial-under-the-cra-the-commissions-seven-tests), er ledsageartiklen til denne.\n\n## Kilder\n\n- Forordning (EU) 2024\u002F2847, 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.\n\nDette 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.\n",1789383975933]