Bruger du open source? Her er, hvad CRA kræver af dig

Forestil dig, at din virksomheds platform bygger på 30 open source-biblioteker. En af jeres udviklere bidrager lejlighedsvis med patches til to af dem. I sælger produktet kommercielt til erhvervskunder i hele EU.

Hvad kræver CRA så af jer – og præcis hvilket ansvar har I?

Indtil nu har det været svært at få et klart svar på netop det spørgsmål. Ikke fordi CRA ikke forholder sig til free and open-source software (FOSS), men fordi open source-verdenens uformelle strukturer ikke passer direkte ind i forordningens juridiske kategorier.

I kan bidrage med kode uden at eje projektet. I kan publicere software uden at sælge den. Og I kan vedligeholde et bibliotek, som andre tjener penge på, uden selv at have en kommerciel interesse i det.

Kommissionens nye FOSS-vejledning præciserer, hvordan CRA skal anvendes i disse forskellige situationer. Forpligtelserne er i mange tilfælde mindre omfattende end frygtet, men det afhænger af, hvilken rolle I har, hvor meget kontrol I udøver, og om softwaren indgår i en kommerciel aktivitet.

Udgangspunktet: CRA gælder ikke FOSS i sig selv

Det første, du skal vide, er, at CRA ikke er skrevet som en regulering af open source som teknologi. Forordningen regulerer produkter med digitale elementer, der markedsføres som led i en kommerciel aktivitet – det er det afgørende kriterium.

FOSS, der publiceres åbent og frit uden kommerciel aktivitet, er som udgangspunkt ikke omfattet. Det betyder, at langt den overvejende del af det open source-software, der eksisterer, falder uden for CRA's rækkevidde – for nu.

Men "som udgangspunkt" er et centralt forbehold. For det afgørende er ikke softwaren i sig selv. Det afgørende er, hvad du gør med den, og under hvilke betingelser.

Hvem er du i FOSS-landskabet?

For at finde ud af, om CRA gælder for dig, skal du starte med at stille dig selv et enkelt spørgsmål: Hvilken rolle spiller du i relation til den konkrete FOSS?

Vejledningen opererer reelt med fire scenarier.

Contributor. Du bidrager med kode til et projekt, men kontrollerer ikke releases, roadmap eller governance. FOSS'en er ikke under dit ansvar, og CRA gælder ikke for dig i den sammenhæng.
Privatperson, der publicerer. Publicerer du som privatperson et FOSS-projekt åbent og frit uden at monetisere det kommercielt, har du som udgangspunkt ingen forpligtelser under CRA. Vejledningen behandler det ikke som en reguleret rolle, men som en fritagelsessituation. Accepterer du kun frivillige donationer, ændrer det ikke på situationen, så længe donationerne ikke de facto fungerer som en pris for adgangen til softwaren.
Steward. Steward-rollen er en nyskabelse i CRA og gælder udelukkende for juridiske personer, det vil sige enheder som virksomheder, fonde og organisationer – og altså ikke hvad vi normalt forstår som personer. En steward er en enhed, der systematisk og vedvarende støtter udviklingen af FOSS beregnet til kommercielle aktiviteter og sikrer softwarens levedygtighed, men som ikke selv placerer den på markedet. Klassiske eksempler er open source-fonde og virksomheder, der publicerer og vedligeholder et bibliotek, de selv bruger i egne produkter, uden at sælge biblioteket separat.
Producent. Er du den, der publicerer FOSS og gør det som led i en kommerciel aktivitet, er du producent med det fulde compliance-ansvar. Det gælder uanset, om du formelt kalder dig nonprofit, fond, stiftelse eller noget andet. Det afgørende er, om du placerer softwaren på markedet.

Hvornår er FOSS "under dit ansvar"?

Contributor-rollen forudsætter, at FOSS'en ikke er under dit ansvar. Men hvad afgør det konkret?

Svaret afhænger af, om du kontrollerer projektet, og omfanget af dine bidrag er i den sammenhæng underordnet. FOSS er under dit ansvar, hvis du publicerer det og udøver primær kontrol over dets udvikling, releases og distributionsbeslutninger. Det er altså ikke hvad du bidrager med, men hvem der i sidste ende beslutter projektets retning.

I praksis betyder det, at den, der sender pull requests og får dem merget af andre, er en contributor. Den, der beslutter, om de overhovedet skal merges, er maintainer.

Det skel er afgørende under CRA.

Det har en vigtig praktisk konsekvens: commit-adgang til et repository gør dig ikke ansvarlig for projektet under CRA. Mange virksomheder har ansatte, der bidrager til open source-projekter som en del af deres arbejde. Det giver ikke automatisk forpligtelser under CRA, medmindre de pågældende medarbejdere eller virksomheden de facto kontrollerer projektet.

Steward: Hvad kræves der af dig?

Falder din virksomhed inden for steward-definitionen, er den underlagt de lettere forpligtelser i artikel 24 og ikke det fulde producentansvar. En steward skal ikke igennem den fulde conformity assessment-procedure, CE-mærkning eller teknisk dokumentation. Men forpligtelserne er stadig reelle og varierer afhængigt af, hvilken type støtte den konkret yder.

Alle stewards skal have en politik for håndtering af sårbarheder, som blandt andet skal fremme videndeling om sårbarheder i open source-fællesskabet. Derudover skal de samarbejde med markedsovervågningsmyndighederne, hvis disse anmoder om det. Stewards, der stiller IT-infrastruktur til rådighed for projektet som hosting af koderepositories eller signing keys, skal desuden indberette alvorlige hændelser til ENISA og de nationale CSIRT'er.

Og stewards, der bidrager med egentlige engineering-ressourcer som ansatte udviklere, kodegennemgang og release management, skal indberette aktivt udnyttede sårbarheder, de bliver opmærksomme på.

Bemærk, at en virksomhed sagtens kan være steward for ét FOSS-projekt og producent for et andet. Rollerne er projektspecifikke, ikke virksomhedsspecifikke.

Hvornår bliver du producent?

Spørgsmålet om, hvornår du bliver producent, er faktisk enklere, end det lyder. Alt drejer sig om ét kriterium: om du publicerer FOSS som led i en kommerciel aktivitet og dermed placerer det på markedet i CRA's forstand. Det er et spørgsmål om, hvad du gør med softwaren og hvad du får ud af det.

Opkræver du betaling for softwaren, er du producent. Det gælder også, hvis du kun opkræver for pre-compiled binaries, mens kildekoden er gratis – det er stadig en pris for produktet.
Monetariserer du på andre måder, fx ved at indsamle og sælge persondata via softwaren, sælge kommerciel support som del af distributionen eller via betalte SaaS-tjenester, der er direkte afhængige af FOSS-produktet, betragtes du ligeledes som producent.
Publicerer du en gratis community-version og en betalt enterprise-version af det samme FOSS, er du steward for den gratis version og producent for den betalte. De to roller kan altså eksistere parallelt for det samme produkt.
Der er dog en vigtig undtagelse, det er værd at være opmærksom på: væsentlig modification. Modificerer du et FOSS-produkt, der allerede er placeret på markedet, og placerer den modificerede version på markedet selv, betragtes du som producent af den modificerede version. Det må ikke forveksles med integration, da det er to fundamentalt forskellige situationer.

Integration af andres FOSS: Ikke producentansvar, men…

Mange er bekymrede for at bare det at integrere en FOSS-komponent i dit produkt, gør dig til "producent" af den komponent.

Det gør det ikke.

Vejledningen er meget klar: Integrerer du FOSS i dit eget produkt, er du producent af dit produkt – og du har det fulde CRA-ansvar for det. Men FOSS-komponentens CRA-status ændrer sig ikke som følge af din integration. Dens status afhænger udelukkende af, om den person eller organisation, der publicerer komponenten, placerer den på markedet.

Hvad du har som integrator, er en due diligence-forpligtelse under artikel 13(5). Det indebærer, at du skal sikre dig, at de FOSS-komponenter, du integrerer, er tilstrækkeligt veldokumenterede, opfylder de relevante krav, og at du har et overblik over din software bill of materials (SBOM).

Derudover følger der af artikel 13(6) en forpligtelse til at rapportere opdagede sårbarheder i dine integrerede komponenter upstream, altså til dem, der vedligeholder dem. Du er også forpligtet til at dele eventuelle sikkerhedsrettelser, du selv udvikler, til brug for disse komponenter. Det understreges i vejledningen som en direkte handlingspligt.

Sådan håndterer du Open Source

Uanset om din virksomhed bruger, udgiver eller bidrager til open source, er der tre ting, du bør gøre nu:

Kortlæg jeres FOSS-roller. Hvem i organisationen har commit-adgang til eksterne projekter? Udgiver I selv FOSS, og sker det med eller uden monetarisering? Er I afhængige af FOSS-komponenter i jeres egne produkter? Svarene afgør, hvilke forpligtelser der gælder.
Lav en SBOM over de FOSS-komponenter, I integrerer. Artikel 13(5)'s due diligence-krav forudsætter, at I ved, hvad I bruger. En opdateret software bill of materials er ikke kun god praksis – det er fundamentet for at overholde CRA i det hele taget.
Etabler en sårbarhedshåndteringsproces, der inkluderer upstream-rapportering. Det er ikke nok at håndtere sårbarheder internt. Opdager I en sårbarhed i en komponent, I bruger, er I forpligtet til at melde den videre. Sørg for, at I ved, hvem der vedligeholder de komponenter, I er afhængige af, og at I har en kanal til at kontakte dem.

Open source har gjort softwareudvikling hurtigere, bedre og mere åben. CRA ændrer ikke på det grundlæggende. Men det kræver, at I ved, hvad I er – contributor, steward eller producent – og handler derefter.

Få afklaret jeres CRA-ansvar for open source

Uanset om I bruger, udgiver eller bidrager til open source, afgør jeres rolle, hvilke forpligtelser I har. NorthGRCs konsulenter kan hjælpe jer med at kortlægge jeres FOSS-roller, identificere compliance-huller og etablere de nødvendige processer og den rette dokumentation.

Tal med en af vores konsulenter