Cyber Resilience Act, forordning (EU) 2024/2847, gælder kun for fri og open source-software, når den "gøres tilgængelig på markedet", det vil sige leveres "som led i en kommerciel aktivitet". De tre tilfælde, et projekt, der ikke tjener penge, et produkt bygget på open source-komponenter og forvalteren af open source-software, kommer fra forordningen selv. Det, forordningen ikke gør, er at sige, hvornår et projekt, der tager imod penge, tilbyder support, kører et betalt niveau eller finansieres af en virksomhed, krydser linjen. Betragtning 15 og 18 giver retningen; Kommissionens vejledning af 27. juli 2026, C(2026) 5252, afsnit 3, punkt 42 til 89, giver testene og 22 gennemregnede eksempler nummereret 13 til 34.

Denne artikel er det afsnit. Den er skrevet til de tre, der spørger: maintaineren med et donationslink, virksomheden med en community-udgave og en enterprise-udgave, og fonden.

Først: hvad der overhovedet tæller som open source

Artikel 3(48) definerer fri og open source-software som "software, hvis kildekode deles åbent, og som stilles til rådighed under en fri og open source-licens, der giver alle rettigheder til at gøre den frit tilgængelig, anvendelig, ændringsbar og videredistribuerbar". Punkt 44 læser det som to kumulative betingelser: en licens, der giver det fulde sæt rettigheder, og kildekode, der deles åbent. Punkt 46 drager konsekvensen for source available- og kun-kunder-modeller: Software, "hvis kildekode kun deles (eller må deles) med betalende kunder eller en begrænset gruppe brugere, skal ikke anses for FOSS". Vejledningen nævner ingen licenser. Den nævner de to betingelser.

Hvem der er ansvarlig: maintainere, ikke bidragydere

Før man spørger, om et projekt er kommercielt, spørger punkt 48, om I er den, der leverer det. Punkt 49: Open source-software er "under ansvar" af de personer, "der udgiver den og udøver den primære kontrol over dens udvikling, udgivelser og distributionsbeslutninger (ofte kaldet 'maintainere')". Bidragydere, der "bidrager med kildekode, men ikke kontrollerer udgivelser, køreplaner eller styringsbeslutninger", er ikke ansvarlige, "selv om de har bidraget med kode", og "den blotte eksistens af tekniske tilladelser, såsom commit-adgang, er ikke tilstrækkelig". Eksempel 13 er pull requesten: Den person, der indsender en rettelse, som maintainere gennemgår og merger, "er en 'bidragyder' og er ikke omfattet af CRA".

Punkt 86 og 87 lukker cirklen for virksomheder: En fabrikant, der integrerer en komponent og bidrager til dens vedligeholdelse, bliver ikke ansvarlig for den komponent, og integration af en komponent i et produkt, der tjener penge, "har ingen indvirkning på den FOSS-komponents status under CRA". Om forordningen gælder for en komponent, "afhænger alene af, om den fysiske eller juridiske person, der udgiver den, bringer den i omsætning".

De syv tests

1. At tage en pris for softwaren. Punkt 51: At tage betaling for selve softwaren, "f.eks. ved at tage en pris for de forudkompilerede binære filer", er at bringe den i omsætning, og den, der tager prisen, er fabrikant.

2. En betalt udgave ved siden af en gratis, herunder open core. Punkt 52 behandler dem som to produkter. Den betalte version bringes i omsætning; "den version, der leveres gratis (eller community-versionen), tjenes der ikke penge på, og den anses derfor ikke for bragt i omsætning". Det gælder, "hvor den betalte version er en 'udvidet' kommerciel version, der udvider kodebasen for den gratis version eller indarbejder den version i et bredere produkt (f.eks. som i 'open core'-modellen)". Punkt 53 tilføjer fælden for virksomheder: En juridisk person, der leverer community-versionen, er forvalter af den; en fysisk person står uden for forordningen for den.

3. At tjene penge på andre tjenester gennem softwaren, eller at kræve personoplysninger. Punkt 54: Et projekt er bragt i omsætning, hvor udgiveren gennem det "tjener penge på andre produkter med digitale elementer eller tjenester", eller "som betingelse for brug kræver behandling af personoplysninger af andre grunde end udelukkende at forbedre softwarens sikkerhed, kompatibilitet eller interoperabilitet". Eksempel 14 er en gratis markedspladsapp, der tjener provision eller reklamer; eksempel 15 en gratis VPN-klient, der sælger adgang til flere servere; eksempel 16 en gratis fitnessapp, hvis brug er betinget af databehandling til målrettet reklame. Alle tre er på markedet.

4. Supporttjenester. Punkt 55 til 57 trækker den linje, de fleste open source-virksomheder lever på. At tilbyde betalt support gør "ikke i sig selv" softwaren kommerciel: "Den afgørende faktor er, om adgangen til selve FOSS'en, herunder dens vedligeholdelse, er betinget af betaling, snarere end det blotte tilbud om professionelle tjenester omkring et frit tilgængeligt produkt". Eksempel 18, et frit downloadbart kommandolinjeværktøj med valgfri betalt rådgivning, er ikke på markedet. Eksempel 17, et operativsystem med en betalt version, "der omfatter supporttjenester såsom teknisk bistand eller ydelsesoptimering", er, og punkt 57 siger det "uanset om funktionelt tilsvarende software også er tilgængelig gratis". For enkeltpersoner tilføjer punkt 58 omkostningsdækningsreglen fra betragtning 15: At bundte bistand med adgang er stadig ikke kommercielt, "hvis den opkrævede pris alene tjener til dækning af faktiske omkostninger", som "omfatter personens rimelige leveomkostninger".

5. Donationer. Punkt 61, fra betragtning 15: "At modtage donationer uden hensigt om at opnå fortjeneste bør ikke anses for en kommerciel aktivitet", og et donationslink er ikke en hensigt om fortjeneste, "selv hvor det beløb, der indsamles via donationer, overstiger de blotte omkostninger", rimelig aflønning af bidragydere og leveomkostninger inklusive. "En FOSS, der alene understøttes gennem donationer, anses derfor sandsynligvis ikke for bragt i omsætning." Punkt 62 giver undtagelsen: donationer, der "de facto svarer til at tage en pris", hvor "adgangen til FOSS'en, til væsentlige funktioner eller til opdateringer i praksis er betinget af en donation". Eksempel 21 leverer udgivelser og sikkerhedsopdateringer kun til donorer: på markedet. Eksempel 22 udgiver kildekoden, men giver "forudkompilerede binære filer, regelmæssige opdateringer og garanterede sikkerhedsrettelser kun til donorer": på markedet.

6. Sponsorering og finansieret udvikling. Punkt 63 til 65: Tilskud, bug bounties, sponsorater og betalt funktionsarbejde "bør ikke tages i betragtning ved afgørelsen af, om aktiviteten er kommerciel". Eksempel 23 er en virksomhed, der betaler en individuel maintainer for at tilføje en funktion, som derefter deles åbent; maintaineren har ikke bragt noget i omsætning, og virksomheden skylder fornøden omhu efter artikel 13(5), når den integrerer resultatet.

7. Almennyttige udgivere. Punkt 66: En juridisk person, "der er indrettet således, at alle indtægter efter omkostninger anvendes til at opnå almennyttige mål", bringer ikke sin software i omsætning, selv hvor der tjenes penge direkte på den. Eksempel 24 er en browser, "der direkte tjener penge via søgemaskinepartnerskaber", og hvis indtægter efter omkostninger går til almennyttige mål: ikke på markedet, og udgiveren er forvalter.

Punkt 67 tilføjer det tilfælde, hele forvalterordningen findes for: Software, "der er beregnet til integration af andre fabrikanter i deres egne produkter", bringes ikke i omsætning, medmindre udgiveren også tjener penge på den; den juridiske person, der udgiver den, er forvalter, hvis den yder vedvarende støtte. Eksempel 25 og 26 er et UI-bibliotek og referenceimplementeringer, som en virksomhed udgiver uden betaling.

Hvor hver af de tre lander

De illustrative scenarier i afsnit 3.5 lægger testene ned over virkelige former, og tre af dem dækker de fleste læsere.

Den individuelle maintainer med et donationslink (eksempel 27 og 34): ikke på markedet, ingen forpligtelser efter forordningen, uanset hvor mange virksomheder der afhænger af projektet, og hvor meget de donerer. De virksomheder, der integrerer det, skylder fornøden omhu efter artikel 13(5) og skylder efter artikel 13(6) maintaineren indberetning af sårbarheder, de finder, og de rettelser, de skriver.

Virksomheden med en community-udgave og en betalt udgave (eksempel 29 og 30): fabrikant for den betalte udgave, med hele forordningen hæftet på, og forvalter for community-udgaven, den leverer gratis, med artikel 24's lettere pligter hæftet på den. Punkt 72 til 74 siger udtrykkeligt, at én juridisk person kan være begge dele på én gang, projekt for projekt, og skal afgøre "for hver enkelt FOSS, den udgiver", hvilken den er.

Fonden (eksempel 28, 32 og 33): forvalter, uanset om den finansieres af offentlige tilskud, donationer, partnerskabsprojekter eller medlemskontingenter, forudsat at den er indrettet, så indtægter efter omkostninger tjener almennyttige mål, og at den holder softwaren i live. Dens medlemmer og finansieringskilder er ikke ansvarlige for softwarens overensstemmelse; fabrikanter, der bygger på den, skylder fornøden omhu.

Hvad I skriver ned

For hvert projekt, I udgiver, én side: om det opfylder de to betingelser i artikel 3(48); hvem der udøver den primære kontrol over udgivelser; hvilken af de syv tests det i givet fald opfylder, med nummeret på det eksempel, det ligner; og den rolle, der følger, fabrikant, forvalter eller ingen af delene. En virksomhed, der udgiver flere projekter, skriver den side flere gange, fordi punkt 74 siger, at svaret gælder pr. projekt. En fabrikant, der integrerer open source-komponenter, skriver den ikke for dem; den noterer i stedet den fornødne omhu efter artikel 13(5) og indberetningerne opstrøms efter artikel 13(6), hvor de tolv trin placerer dem.

Kilder

  • Forordning (EU) 2024/2847, artikel 3(14) og (48), artikel 13(5) og (6), artikel 24, betragtning 15, 18 og 19.
  • Europa-Kommissionen, Kommissionens vejledning om anvendelsen af forordning (EU) 2024/2847, C(2026) 5252 final af 27. juli 2026, bilag, afsnit 3, punkt 42 til 89 og eksempel 13 til 34.

Dette er ikke juridisk rådgivning. Afsnit 3 er fjorten sider, og de 22 eksempler er den del, man skal læse; de fleste projekter vil genkende sig selv i et af dem.