Næsten alle kommercielle softwareprodukter indeholder open source-komponenter, normalt hundredvis, valgt af udviklere i stedet for advokater. Det bliver et problem, når ingen kan sige, hvilke licenser der gælder, hvad de kræver, og om produktet overholder reglerne. Denne artikel forklarer, hvordan open source-licenser fungerer under hollandsk og EU-lovgivning, hvor risikoen ligger, og hvad der skal være på plads.
Hvad en open source-licens er, juridisk set
En open source-licens er en ophavsretslicens, der gives underlagt betingelser. Det er ikke et afkald på ophavsretten, ikke en dedikation til det offentlige domæne, ikke en opgivelse af rettigheder, og i den henseende fungerer den som enhver anden softwarelicens i henhold til hollandsk lov . Ophavsmanden bevarer ophavsretten i henhold til artikel 1 i lov om rettigheder og artikel 10 i lov om rettigheder, som beskytter computerprogrammer som værker, og licensen tillader handlinger, der ellers ville krænke de eksklusive rettigheder i henhold til artikel 12 i lov om rettigheder og artikel 13 i lov om rettigheder.
Konsekvensen betyder mere end definitionen. Overhold rettighederne, og din kopiering og distribution er lovlig. Overholder du ikke rettighederne, dækker tilladelsen ikke det, du gjorde: din brug er en krænkelse af ophavsretten, ikke et kontraktbrud. De fleste ophavsretslicenser forstærker dette ved automatisk at ophøre ved brud – GPLv2 uden nogen afhjælpningsperiode, mens GPLv3 og AGPLv3 genopretter rettighederne, hvis bruddet afhjælpes inden for et defineret vindue efter varsel.
Hollandske domstole anvender denne argumentation. I Rb. Amsterdam 22. september 2020, ECLI:NL:RBAMS:2020:4717, blev en distributør, der fjernede licensteksten og copyright-meddelelsen fra en forgrenet kodebase, anset for at have mistet sin tilladelse og for at krænke ophavsretten. Tilføjelse af en stor mængde ny kode skabte ikke et uafhængigt værk: originalen forblev genkendeligt til stede, så forpligtelserne fulgte med.
De to familier: permissive og copyright
Tilladte licenser — MIT, BSD-licenserne, Apache 2.0 — tillader brug, ændring og videredistribution, herunder i produkter med lukket kildekode, forudsat at du bevarer copyright-meddelelser og licenstekst.
Ophavsretslicenser kræver, at når du distribuerer softwaren eller noget, der er bygget på den, gør du det under den samme licens og stiller den tilsvarende kilde til rådighed. De har forskellig rækkevidde.
| Familie | Typiske licenser | Kerneforpligtelse | Udløst af | Proprietær kombination |
|---|---|---|---|---|
| Tilladende | MIT, BSD-2/3, Apache 2.0 | Bevar meddelelser, licenstekst, ansvarsfraskrivelser; Apache tilføjer ændringsmeddelelser | Distribution i kilde- eller binær form | Ja |
| Svag ophavsret | MPL 2.0, LGPL 2.1/3, EPL 2.0 | Kilde til de dækkede filer eller bibliotek; LGPL tilføjer udskiftelighed | Distribution af de dækkede filer eller bibliotek | Ja, med omhu for grænsen |
| Stærk ophavsret | GPLv2, GPLv3, EUPL 1.2 | Samme licens for hele det samlede værk; komplet tilsvarende kilde | Distribution; EUPL har også adgang til vigtige funktioner | Nej, medmindre det er fuldstændig adskilt |
| Netværks copyright | AGPLv3 | Som GPLv3, plus kildekode til eksterne brugere over et netværk | Distribution eller kørsel af en modificeret version som en tjeneste | Ingen |
Copyleft-triggeren og linkspørgsmålet
Ophavsretsforpligtelser påvirker distribution, ikke brug. En virksomhed, der kører GPL-software internt, uanset hvor kraftigt modificeret den er, distribuerer ingenting og skylder ingenting. "Har vi distribueret?" er altid det første spørgsmål, og det er derfor, containere, apparater, firmware og SDK'er er vigtigere end interne værktøjer.
Det andet spørgsmål er vanskeligere. GPL taler om et "værk baseret på programmet" og låner det amerikanske koncept om et afledt værk. Hollandsk lov har ikke et sådant udtryk: analysen går gennem reproduktions- og tilpasningsrettighederne og spørger, om beskyttet udtryk fra originalen er blevet reproduceret.
Det praktiske tilfælde er linkning. Hvorvidt linkning af et proprietært modul til et GPL-bibliotek skaber ét værk, der er underlagt copyright, er aldrig blevet afgjort af en hollandsk domstol, og der er ingen bindende EU-myndighed. Free Software Foundations synspunkt om, at linkning skaber et kombineret værk, er licensforvalterens fortolkning, ikke lov, og det modsatte synspunkt er ligeledes uprøvet. Internettets foretrukne svar - dynamisk linkning sikker, statisk linkning ikke - har intet grundlag i hollandsk ophavsretslovgivning, som ikke spørger, hvordan en compiler opfører sig. En mere forsvarlig analyse spørger, hvor tæt komponenterne er kombineret: deler de et adresserum og datastrukturer, leveres kombinationen som ét produkt, kan den enten fungere alene, reproducerer den proprietære side headere, makroer eller inline-kode fra copyleft-siden? Disse spørgsmål løser normalt risikoen. Hvor de ikke gør det, isoleres komponenten bag en procesgrænse, erstattes den eller tages en kommerciel licens.
AGPL og netværksbrug
AGPL eksisterer, fordi copyleft udløses af distribution, og SaaS-udbydere ikke distribuerer. Dens netværksklausul kræver, at hvis du ændrer softwaren og gør den tilgængelig for brugere, der interagerer med den eksternt, tilbyder du dem den tilsvarende kilde til din ændrede version.
Tre punkter overses ofte. Forpligtelsen gælder for brugerne af tjenesten, hvilket i et produkt med åben tilmelding ikke er en stor tryghed. Den udløses af en ændring, så en umodificeret komponent aktiverer den ikke, men en opdateret version kan. Og det rejser det samme spørgsmål om kombineret arbejde som GPL for resten af din stak - hvilket er grunden til, at mange virksomheder forbyder AGPL i produktionskode.
Licenskompatibilitet
Kompatibilitet er problemet med at kombinere komponenter, hvis licenser pålægger forpligtelser, der ikke begge kan opfyldes i én distribution: permissive licenser er kompatible med næsten alt, mens copyleft-licenser kun er kompatible med, hvad deres egne vilkår tillader. Standardtilfældet er Apache 2.0 og GPLv2. Apache Software Foundation og Free Software Foundation er enige om, at kombinationen ikke er tilladt, fordi Apache 2.0's bestemmelser om patentophør og skadesløsholdelse er yderligere begrænsninger, som GPLv2 ikke tillader. GPLv3 blev udarbejdet for at acceptere dem. Kompatibilitet er også retningsbestemt: Apache-kode kan absorberes i et GPLv3-projekt, men ikke omvendt. Én GPL-komponent på det forkerte sted kan tvinge et valg mellem genlicensering, reengineering eller fjernelse - langt billigere før udgivelsen end efter.
Krediterings- og meddelelsesforpligtelser
De hyppigst overtrådte forpligtelser er de mindst dramatiske: gengivelse af copyright-meddelelser, licenstekster, ansvarsfraskrivelser og, under Apache 2.0, NOTICE-indhold i de materialer, der følger med distributionen. Alle familier pålægger dem, inklusive MIT og BSD. De overtrædes, fordi ingen ejer dem, og de er nemmest at reparere - normalt en genereret attributionsfil, der følger med produktet. Den hollandske sag ovenfor drejede sig om præcis denne fejl.
Patentbevillinger og patentgengældelse
MIT og BSD siger intet om patenter, og hvorvidt en patentlicens kan være implicit er uafklaret. Apache 2.0 tilføjede en udtrykkelig, royaltyfri patentlicens fra hver bidragyder, parret med en gengældelsesklausul: anlægger patentsager med påstand om, at værket krænker patentet, og din patentlicens ophører. GPLv3 indeholder en sammenlignelig tilladelse og sine egne patentbestemmelser.
To implikationer for virksomheder med patentporteføljer. Hvis dine ingeniører bidrager til Apache- eller GPLv3-licenserede projekter, udsteder du licenser under dine egne patenter. Og hvis du nogensinde gør patenter gældende mod en virksomhed, der er afhængig af de samme Apache-licenserede komponenter, som du bruger, kan gengældelse koste dig en licens, du er afhængig af.
EUPL og den hollandske offentlige sektor
Den Europæiske Unions Offentlige Licens version 1.2, godkendt af Europa-Kommissionen ved en gennemførelsesafgørelse i maj 2017, er en OSI-godkendt ophavsretslicens med tre særlige kendetegn.
- Sprog. Den findes på de officielle EU-sprog, hvor alle godkendte versioner har samme værdi, så en hollandsk myndighed kan indgå kontrakter på hollandsk.
- Kompatibilitet. Et bilag indeholder en liste over kompatible licenser — blandt andet GPLv2 og v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL og CeCILL — og tillader i stedet at distribuere et afledt værk, der kombinerer EUPL-kode med kode under en angivet licens, under denne licens.
- Nå. Definitionen af distribution dækker tilgængeliggørelse af værket online eller offline eller giver adgang til dens væsentlige funktioner, og artikel 5 i EUPL viderefører ophavsretsforpligtelsen til fjerninteraktion, hvor den samme funktionalitet tilbydes. Den omfatter derfor software leveret som en tjeneste, på en måde som GPL ikke gør.
En hollandsk offentlig kunde kan kræve EUPL som et politisk anliggende snarere end lovmæssigt. Interoperable Europe Act, forordning (EU) 2024/903, pålægger offentlige organer at prioritere interoperabilitetsløsninger uden restriktive licensvilkår, såsom open source, hvor det er tilsvarende; nationalt hviler princippet om open source, tenzij, på kabinetsbeslutninger og politiske linjer, ikke på lovbestemmelser: Wet digitale voorziening fremmer den digitale identitetsinfrastruktur, men pålægger ingen håndhævbar forpligtelse til at offentliggøre al kildekode. Læs udbudsmaterialet: et EUPL-krav binder din leverance og kan være uforenelig med proprietær kode, du havde til hensigt at genbruge.
Håndhævelse i praksis
Hvem kan sagsøge? Rettighedshaveren — individuelle bidragydere, eller fonden eller virksomheden, der besidder tildelt ophavsret. Fragmenteret forfatterskab er den praktiske bremse: en sagsøger skal bevise ejerskab af den omhandlede kode. Dette afviste den mest kendte europæiske GPL-sag, hvor en kerneudviklers krav mod en virtualiseringsleverandør mislykkedes på grund af manglende bevis for forfatterskab (LG Hamburg 8. juli 2016, 310 O 89/15; stadfæstet OLG Hamburg 28. februar 2019, 5 U 146/16).
Hvad retspraksis fastslår. Tyske domstole har gentagne gange accepteret, at open source-licenser er gyldige, og at brud gør distribution ulovlig, startende med det første GPL-påbud (LG München I 19. maj 2004, 21 O 6123/04). Den amerikanske kredsret nåede frem til samme konklusion i Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): licensvilkår er betingelser for tildelingens omfang, ikke blot klausuler, så brud understøtter et ophavsretskrav og et påbud. Amerikanske retssager undersøger, om en downstream-modtager kan håndhæve GPL som tredjepartsbegunstiget. Det er det centrale spørgsmål i Software Freedom Conservancy v Vizio for Superior Court of California: om forbrugere, som tredjepartsbegunstigede, kan kræve frigivelse af kildekoden under GPLv2. Den 23. december 2025 afgjorde retten ét punkt i den summariske afgørelse og fastslog, at GPLv2 og LGPLv2.1 kræver en kildekode, der kan indhentes og omarbejdes til brug andetsteds, snarere end en kildekode, der kan geninstalleres på enheden med dens funktionalitet intakt. Spørgsmålet om tredjepartsbegunstiget blev i sig selv udsat til den ordinære retssag, som er blevet udsat mere end én gang. Det er under alle omstændigheder et californisk kontraktsretligt spørgsmål, så det er ikke bindende i Holland; det, det ville ændre, er antallet af personer, der kan klage.
Hvordan en hollandsk domstol ville gribe det an. Som krænkelse af ophavsretten i henhold til Auteurswet: Sagsøgeren beviser ejerskab og reproduktion eller overføring; sagsøgte påberåber sig licensen; sagsøgeren svarer, at betingelserne ikke var opfyldt, hvorfor forsvaret mislykkes. Kontraktlige retsmidler i henhold til art. 6:265 i BW løber parallelt, men ophavsret er den stærkere vej.
Retsmidler. Et påbud i henhold til art. 3:296 i BW, typisk med en tvangsbøde og tilgængeligt i en summarisk retssag; erstatning i henhold til art. 27 i Aw og en opgørelse over fortjeneste i henhold til art. 27a i Aw; tilbagekaldelse, overdragelse eller destruktion i henhold til art. 28 i Aw; og fuld godtgørelse af rimelige og forholdsmæssige sagsomkostninger i henhold til art. 1019h Rv. Hvor software blev distribueret gratis, er tabet svært at kvantificere, og en tysk appeldomstol afviste at tilkende erstatning, men stadfæstede påbuddet (OLG Hamm 13. juni 2017, 4 U 72/16). Det, der bider, er sjældent erstatning: det er påbuddet, tilbagekaldelsen, omkostningskendelsen og at skulle offentliggøre en kilde, man aldrig havde til hensigt at offentliggøre.
Når du opdager et compliance-problem
Opdagelse kommer normalt fra en kundes sikkerhedsspørgeskema, en scanning under due diligence eller et brev fra en rettighedshaver. Afhjælpning foregår derefter som følger. Stop distributionen af det berørte build, hvis eksponeringen er alvorlig. Fastlæg hvilken komponent, hvilken version, hvilken licens, hvilke produkter og udgivelser, over hvilken periode. Find ud af, hvad licensen rent faktisk kræver - ofte en krediteringsfil i stedet for en kildekode-frigivelse. Forbered artefakterne: meddelelser, licenstekster, udfyld den tilsvarende kildekode inklusive build-scripts og et skriftligt tilbud, hvor det er brugt. Send en kompatibel frigivelse, og fortæl derefter rettighedshaveren, hvad du har gjort, i stedet for at diskutere, om du var nødt til det.
Under GPLv3 og AGPLv3 giver afhjælpningsvinduet hastighed juridisk værdi; under GPLv2 er der ingen afhjælpningsret, hvilket er grunden til, at de fleste håndhævelser ender i en forhandlet compliance-forpligtelse. Bemærk også, at privilegiet er knyttet til rådgivning fra din advokat, ikke til en intern ingeniørrapport.
Open source inden for fusioner og opkøb og due diligence
I forbindelse med softwareopkøb er open source en standard diligence-proces, og en ikke-offentliggjort copyleft-komponent i kerneproduktet er en af de få resultater, der reelt ændrer en handel: Hvis produktet ikke kan distribueres uden at frigive kildekoden, erhverver køberen et andet aktiv end det, der er prissat.
Forvent en kodebasescanning, en komponentopgørelse med licenser og spørgsmål om aftaler mellem bidragydere og leverandører. Typiske resultater er en specifik skadesløsholdelse, en tilbageholdelse i afventning af afhjælpning, en forudgående betingelse, der kræver fjernelse, eller en skræddersyet open source-garanti. Sælgere bør scanne først: resultater, du oplyser, er en forhandling, resultater, som købers rådgiver foretager, er en form for løftestangseffekt. Købere bør ikke søge "at virksomheden ejer sin IP", men en erklæring om, at intet produkt inkorporerer open source, der kræver offentliggørelse af proprietær kildekode.
Materialefortegnelsen, scanning og Cyber Resilience Act
En softwareliste er en opgørelse over et produkts komponenter med versioner og licenser. Indtil for nylig er den udelukkende kontraktlig, men nu også lovgivningsmæssig.
Cybermodstandsdygtighedsloven, forordning (EU) 2024/2847, trådte i kraft den 10. december 2024 og indfases. Den står sideløbende med den hollandske cybersikkerhedslov , som omhandler organisationen snarere end produktet. Rapporteringsforpligtelserne for aktivt udnyttede sårbarheder og alvorlige hændelser i artikel 14 i CRA gælder fra den 11. september 2026; bestemmelserne om notifikation af overensstemmelsesvurderingsorganer fra den 11. juni 2026; forordningen i sin helhed fra den 11. december 2027 (artikel 71 i CRA). Bilag I i CRA kræver, at producenter identificerer og dokumenterer komponenterne i produktet, herunder ved at udarbejde en softwareliste i et almindeligt anvendt og maskinlæsbart format, der som minimum dækker de øverste afhængigheder. Den behøver ikke at blive offentliggjort; markedsovervågningsmyndighederne kan anmode om den.
Gratis og open source-software leveret uden for en kommerciel aktivitet falder uden for CRA. Forordningen introducerer open source-softwareforvalteren - en juridisk person, der yder vedvarende støtte til udvikling af open source-software beregnet til kommercielle aktiviteter - med lettere forpligtelser i henhold til artikel 24 i CRA: en dokumenteret cybersikkerhedspolitik, samarbejde med markedsovervågningsmyndigheder og rapportering. Hvis du kommercialiserer open source eller finansierer et projekt, som andre kommercialiserer, skal du fastslå, hvilken rolle du har. Kommissionen vedtog sin første vejledning den 27. juli 2026: Kommissionens vejledning om anvendelsen af Cyber Resilience Act (CRA), der er knyttet som bilag til meddelelse C(2026) 5252, som blandt andet omhandler, hvornår gratis og open source-software falder ind under anvendelsesområdet. Der er ikke vedtaget nogen gennemførelsesretsakt, der foreskriver et format for softwarens stykliste, så forordningens egen standard - et almindeligt anvendt, maskinlæsbart format - forbliver foranstaltningen for øjeblikket.
Analyse af softwaresammensætning, der køres i CI, genererer den inventarliste, der betjener compliance, licensgennemgang og diligence på én gang. Sådanne værktøjer overser leverandørkode, identificerer projekter med dobbeltlicens fejlagtigt og kan ikke læse en licens' betingelser: Behandl outputtet som starten på gennemgangen, ikke selve gennemgangen.
Hvis du udgiver din egen kode: CLA'er og DCO'en
En virksomhed, der udgiver kode og accepterer eksterne bidrag, skal vide, at den har rettighederne til det, den fletter. En bidragyderlicensaftale er en kontrakt mellem projekt og bidragyder, der typisk giver en bred ophavsretslicens og en udtrykkelig patentlicens med garantier for originalitet og autoritet. Det er det, der giver en virksomhed mulighed for at genlicensere sit projekt senere eller tilbyde kommercielle licenser sammen med en open source-licens. Omkostningerne er friktion.
Udviklercertifikatet (Developer Certificate of Origin) , som bruges af Linux-kernen og mange andre projekter, er ikke en licensbevilling, men en letvægtsbekræftelse, tilføjet som en godkendelseslinje til hver commit, om at bidragyderen kan indsende koden under projektets licens. Mindre byrdefuldt og mindre beskyttende: ingen patentlicens, ingen genlicensering.
Hvis dobbeltlicensering eller en fremtidig genlicensering er mulig, skal du bruge en CLA; hvis projektet er et ægte commons, er DCO'en normalt tilstrækkelig. Uanset hvad, sørg for, at dine ansættelses- og leverandøraftaler tildeler ophavsret til den kode, dine folk skriver.
En praktisk tjekliste til politikker
- Generer en komponentbeholdning pr. produkt og frigiv den i build-pipelinen, ikke manuelt.
- Offentliggør en intern politik: en liste over tilladte varer, en liste over forbudte varer og en godkendelsesrute for alt andet.
- Definer skriftligt, hvad der tæller som distribution — lokale installationer, enheder, containere, SDK'er, mobilapps, firmware.
- Send en genereret attributionsfil med hvert produkt.
- Godkend licensvalg på designtidspunktet, når en komponent er valgt, ikke ved udgivelsen.
- Beslut, om bidrag til eksterne projekter skal godkendes, givet de involverede patentbevillinger, og vælg en CLA eller en DCO før det første eksterne bidrag.
- Tilpas IP-garantier, skadesløsholdelser og escrow-vilkår med den open source, der faktisk er inkluderet i produktet.
- Kør gennemgangen før en fundraising- eller salgsproces, ikke under en.
Law & More rådgiver softwarevirksomheder og deres investorer Eindhoven og Amsterdam om overholdelse af regler for open source, licensgennemgang, bidragyderaftaler og open source-arbejdsgangen i en transaktion.
Betyder brugen af open source-software, at vi skal udgive vores egen kildekode?
Kun hvis en ophavsretslicens gælder, og du aktiverer den. Tilladte licenser kræver det aldrig. Ophavsretslicenser kræver det, når du distribuerer et værk, der indeholder ophavsretskode, og AGPL udvider dette til at omfatte modificeret software, der tilbydes som netværkstjeneste. Intern brug uden distribution skaber ingen forpligtelse.
Kan en licens som MIT-licensen håndhæves i Holland uden en underskrift?
Ja. Det er en ikke-eksklusiv ophavsretslicens, så kravet om handling i artikel 2 i Aw finder ikke anvendelse, og accept gennem adfærd er tilstrækkeligt. En hollandsk domstol ville behandle manglende overholdelse af betingelserne som at føre brugen uden for den givne tilladelse, hvilket gør det til en krænkelse af ophavsretten.
Undgår dynamisk linking GPL?
Der findes ingen pålidelig autoritet, der påstår det. Ingen hollandsk eller EU-domstol har afgjort spørgsmålet, og sondringen mellem statisk og dynamisk har intet grundlag i hollandsk ophavsretslovgivning, som spørger, om et beskyttet udtryk er blevet reproduceret. Den mere sikre analyse ser på, hvor tæt komponenterne er kombineret; hvor det er uklart, isoleres eller erstattes komponenten.
Vi er en SaaS-virksomhed: kan vi ignorere ophavsret?
Ikke helt. De fleste GPL-distributionsforpligtelser bortfalder, fordi hosting ikke er distribution. Men AGPL gælder for modificeret software, der stilles til rådighed for eksterne brugere, EUPL's definition af kommunikation omfatter adgang til et værks væsentlige funktioner, og enhver lokal agent eller downloadbar klient er en distribution.
Hvad sker der, hvis vi opdager, at vi har været imod reglerne i årevis?
Ret det, og dokumenter rettelsen. Under GPLv3 og AGPLv3 genopretter et afhjælpningsvindue efter meddelelse rettighederne. Under GPLv2 afhænger genoprettelsen af rettighedshaveren, men de fleste håndhævelser afsluttes med en compliance-forpligtelse. Den relevante eksponering er et påbud, en tilbagekaldelse i henhold til art. 28 i Aw og en omkostningskendelse i henhold til art. 1019h Rv, normalt ikke erstatning.
Kræver Cyber Resilience Act, at vi offentliggør vores SBOM?
Nej. Bilag I i CRA kræver en software-materialeliste i et almindeligt anvendt, maskinlæsbart format, der mindst dækker afhængigheder på øverste niveau, og markedsovervågningsmyndighederne kan anmode om den. Der er ingen forpligtelse til at offentliggøre den. Forordningen gælder fuldt ud fra den 11. december 2027; rapporteringsforpligtelserne i artikel 14 i CRA fra den 11. september 2026.
Hvordan Law & More kan hjælpe dig med dette, er forklaret på vores IT-advokat .
