Betalt support til open source gør jer ikke i sig selv til fabrikant efter CRA. Det afgørende er, om adgangen til softwaren eller dens vedligeholdelse kræver betaling, og det kan kun afgøres ved at læse tilbud og aftale klausul for klausul.
Artiklen bygger på Kommissionens vejledning C(2026) 5252, punkt 55-62. Vejledningen er ikke bindende, og dens eksempler erstatter ikke en konkret vurdering (punkt 8). Klausullæsningen nedenfor er vores metode, ikke en regel.
Grundreglen
Udgiveren af et open source-projekt kan sælge rådgivning, undervisning, hjælp til konfiguration og udrulning, dokumentation og andre professionelle ydelser om brugen. Det gør ikke softwaren til et produkt, der bringes i omsætning (punkt 55-56). Kan alle hente og installere softwaren frit, og kan kunderne vælge at købe ydelserne særskilt, er softwaren ikke bragt i omsætning (eksempel 18).
Billedet vender, når adgangen til en bestemt udgave er betinget af betaling, og udgaven giver fordele som teknisk bistand eller ydelsesoptimering. Så er udgaven bragt i omsætning, også selv om der findes en funktionelt tilsvarende udgave, alle kan hente (punkt 57 og eksempel 17). Det gælder betalte udgaver og enterprise-udgaver under kommerciel aftale.
For fysiske personer er der en særregel. Teknisk bistand bundtet med adgang er ikke erhvervsvirksomhed, hvis betalingen kun dækker de faktiske omkostninger, herunder rimelige leveomkostninger (punkt 58 og forordningens betragtning 15). Et selskab kan ikke bruge den regel.
Fem spørgsmål til aftalen
Læsningen kan bygges op om fem spørgsmål, som stilles til hver enkelt klausul i tilbud og aftale.
- Får kunden adgang til noget, alle andre ikke kan hente?
- Er sikkerhedsrettelser eller opdateringer betinget af aftalen, eller kommer de før til kunder med aftale?
- Leveres en særlig build, en binær pakke eller en udgave med ekstra funktioner kun mod betaling?
- Er ydelserne valgfrie, så softwaren kan bruges fuldt ud uden dem?
- Betaler kunden for timer og viden, eller for retten til at bruge softwaren?
Peger svarene mod adgang, rettelser eller udgaver bag betaling, er der grund til at vurdere, om I er fabrikant for den udgave, kunden får.
Klausuler, der vipper
Tabellen viser tænkte klausuler og den retning, de efter vores læsning af vejledningen peger i. De er ikke afgørelser.
- (Leverandøren yder op til 20 timers rådgivning om konfiguration pr. kvartal) · Peger mod valgfri ydelse
- (Kunden får sikkerhedsrettelser, før de lægges i det offentlige repositorium) · Peger mod omsætning af en særlig udgave
- (Kunden får en certificeret build med ydelsesoptimering) · Peger mod omsætning (punkt 57)
- (Leverandøren deltager i kundens udrulning på kundens egen server) · Peger mod ingen omsætning (eksempel 19)
- (Kunden får adgang til langtidssupport af ældre versioner, som ikke offentliggøres) · Peger mod omsætning af de ældre versioner
Den sidste klausul er værd at stoppe ved. Langtidssupport til versioner, der ikke længere vedligeholdes offentligt, kan i praksis betyde, at kunden betaler for adgang til vedligeholdelsen. Det er en tolkning af punkt 56-57.
Donationer og sponsorater
Et donationslink er ikke en hensigt om profit, heller ikke hvis donationerne overstiger omkostningerne (punkt 60). Grænsen går ved det, donoren får. Er adgang, væsentlige funktioner eller opdateringer i praksis betinget af donation, eller giver donationen kontraktlige fordele ud over det, fællesskabet får, kan donationen svare til en pris. Vejledningens eksempel 21 og 22 handler om releases, binære filer og garanterede sikkerhedsrettelser, som kun donorer får.
Sponsoraftaler bør derfor læses med de samme fem spørgsmål som supportaftaler.
Andres projekter
Yder I support til open source, som andre styrer, er det ikke at bringe softwaren i omsætning (punkt 59). Det ændrer sig, hvis I foretager en væsentlig ændring og leverer den ændrede udgave. Den situation er behandlet i artiklen om at installere og tilpasse open source hos kunden.
Aftaler, der ændrer sig undervejs
En supportaftale kan ændre sig mange gange i sin levetid. Der kan komme tillæg, særaftaler med store kunder og nye pakker med andre navne. Hver af dem kan flytte vurderingen, fordi det er det samlede tilbud til kunden, der viser, om adgangen til softwaren reelt kræver betaling.
Det er derfor praksis at knytte vurderingen til hver aftaletype, så den også dækker de kontrakter, der laves senere på samme skabelon. Når salget tilføjer en ny pakke eller et nyt tillæg, går tillægget gennem de samme fem spørgsmål, før det bruges første gang. Resultatet gemmes med dato og navnet på den, der har vurderet det.
Er konklusionen, at en udgave er bragt i omsætning, gælder fabrikantens pligter fra den version, der første gang leveres på de vilkår. Tidligere versioner, der blev udgivet åbent, bliver ikke omfattet af den grund. Det er vores tolkning, bygget på vejledningens regel om forvaltere, der begynder at tjene penge på et projekt (punkt 84).
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen, der kender forordningen, læser standardaftalen og tilbudsskabelonen igennem, og at salget ved, hvilke klausuler der ikke må tilføjes uden en ny vurdering. Når skabelonen først er gennemgået, er den løbende opgave lille.
Uden den læsning kan en enkelt klausul om tidlige sikkerhedsrettelser gøre en enterprise-aftale til omsætning af et produkt. Så mangler der risikovurdering, teknisk dokumentation og overensstemmelsesvurdering for en udgave, ingen troede var et produkt.
Det skal I lade være med
- At lade salget skrive klausuler om rettelser frit · tidlig adgang til rettelser kan ændre rollen.
- At gå ud fra, at ordet support afgør sagen · det er indholdet, der tæller.
- At bruge særreglen for fysiske personer i et selskab · den gælder kun fysiske personer.
Det skal auditten kunne vise
- ☐ Standardaftaler og tilbudsskabeloner for support til egne open source-projekter.
- ☐ En dateret vurdering af hver aftaletype efter vejledningens punkt 55-62.
- ☐ En liste over klausuler, der kræver ny vurdering, før de tilføjes.
- ☐ For udgaver vurderet som bragt i omsætning: fabrikantens dokumentation.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, betragtning 15, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 8, 55-62 og eksempel 17-22, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læg jeres standardaftale for support ved siden af de fem spørgsmål, og markér hver klausul.
Læs også: Fabrikant, forvalter eller ingen af delene? · Hvornår er softwaren bragt i omsætning?
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
