Licenser för öppen källkodsprogramvara enligt nederländsk och EU-lagstiftning

Nästan varje kommersiell mjukvaruprodukt innehåller komponenter med öppen källkod, vanligtvis hundratals, som valts ut av utvecklare snarare än jurister. Det blir ett problem när ingen kan säga vilka licenser som gäller, vad de kräver och om produkten uppfyller kraven. Den här artikeln förklarar hur licenser med öppen källkod fungerar enligt nederländsk och EU-lagstiftning, var risken ligger och vad man ska ha på plats.

Vad en öppen källkodslicens är, juridiskt sett

En öppen källkodslicens är en upphovsrättslicens som beviljas med vissa villkor. Det är inte ett avstående, inte ett engagemang för det allmänna, inte ett avstående från rättigheter, och i det avseendet fungerar den som vilken annan programvarulicens som helst enligt nederländsk lag . Upphovsmannen behåller upphovsrätten enligt artikel 1 Aw och artikel 10 Aw, som skyddar datorprogram som verk, och licensen tillåter handlingar som annars skulle kränka de exklusiva rättigheterna enligt artikel 12 Aw och artikel 13 Aw.

Konsekvensen är viktigare än definitionen. Följ upphovsrätten, så är din kopiering och distribution laglig. Underlåter du att följa upphovsrätten, så täcker inte tillståndet vad du gjorde: din användning är ett upphovsrättsintrång, inte ett kontraktsbrott. De flesta copyright-licenser förstärker detta genom att upphöra automatiskt vid brott – GPLv2 utan någon åtgärdsperiod, medan GPLv3 och AGPLv3 återställer rättigheterna om brottet åtgärdas inom ett definierat fönster efter meddelande.

Holländska domstolar tillämpar detta resonemang. I Rb. Amsterdam 22 september 2020, ECLI:NL:RBAMS:2020:4717, en distributör som tog bort licenstexten och upphovsrättsmeddelandet från en förgrenad kodbas ansågs ha förlorat sitt tillstånd och gjort intrång. Att lägga till en stor mängd ny kod skapade inte ett självständigt verk: originalet förblev igenkännbart närvarande, så skyldigheterna följde med det.

De två familjerna: permissiva och upphovsrättsfamiljerna

Tillåtande licenser — MIT, BSD-licenserna, Apache 2.0 — tillåter användning, modifiering och omdistribution, inklusive inuti produkter med sluten källkod, förutsatt att du behåller upphovsrättsmeddelanden och licenstext.

Copyleft-licenser kräver att när du distribuerar programvaran, eller något som bygger på den, gör du det under samma licens och gör motsvarande källa tillgänglig. De skiljer sig åt i räckvidd.

Copyleft-utlösaren och länkningsfrågan

Upphovsrättsskyldigheter påverkar distributionen, inte användningen. Ett företag som kör GPL-programvara internt, hur kraftigt modifierad den än är, distribuerar ingenting och är inte skyldigt något. "Har vi distribuerat?" är alltid den första frågan, och det är därför containrar, apparater, firmware och SDK:er är viktigare än interna verktyg.

Den andra frågan är svårare. GPL talar om ett "verk baserat på programmet" och lånar det amerikanska konceptet för ett härlett verk. Nederländsk lag har ingen sådan term: analysen går igenom reproduktions- och anpassningsrättigheterna och frågar sig om skyddat uttryck från originalet har reproducerats.

Det praktiska fallet är länkning. Huruvida länkning av en proprietär modul till ett GPL-bibliotek skapar ett verk som omfattas av upphovsrätt har aldrig avgjorts av en nederländsk domstol, och det finns ingen bindande EU-myndighet. Free Software Foundations uppfattning att länkning skapar ett kombinerat verk är licensförvaltarens tolkning, inte lag, och den motsatta uppfattningen är lika oprövad. Internets favoritsvar – dynamisk länkning säker, statisk länkning inte – har ingen grund i nederländsk upphovsrättslag, som inte frågar hur en kompilator beter sig. En mer försvarbar analys frågar hur intimt komponenterna är kombinerade: delar de ett adressutrymme och datastrukturer, levereras kombinationen som en produkt, kan den antingen fungera ensam, reproducerar den proprietära sidan rubriker, makron eller inline-kod från upphovsrättssidan? Dessa frågor löser vanligtvis risken. Där de inte gör det, isolera komponenten bakom en processgräns, ersätt den eller ta en kommersiell licens.

AGPL och nätverksanvändning

AGPL existerar eftersom upphovsrätt utlöses av distribution och SaaS-leverantörer inte distribuerar. Dess nätverksklausul kräver att om du modifierar programvaran och gör den tillgänglig för användare som interagerar med den på distans, erbjuder du dem motsvarande källa till din modifierade version.

Tre punkter missas ofta. Skyldigheten gäller för användarna av tjänsten, vilket i en produkt med öppen registrering inte är till någon större trygghet. Den utlöses av modifiering, så en omodifierad komponent aktiverar den inte, men en patchad version kan göra det. Och den väcker samma fråga om kombinerat arbete som GPL för resten av din stack – vilket är anledningen till att många företag förbjuder AGPL i produktionskod.

Licenskompatibilitet

Kompatibilitet är problemet med att kombinera komponenter vars licenser medför skyldigheter som inte båda kan uppfyllas i en distribution: permissiva licenser är kompatibla med nästan allt, medan copyright-licenser endast är kompatibla med vad deras egna villkor tillåter. Standardfallet är Apache 2.0 och GPLv2. Apache Software Foundation och Free Software Foundation är överens om att kombinationen inte är tillåten, eftersom Apache 2.0:s bestämmelser om patentuppsägning och gottgörelse är ytterligare begränsningar som GPLv2 inte tillåter. GPLv3 utarbetades för att acceptera dem. Kompatibilitet är också riktad: Apache-kod kan absorberas i ett GPLv3-projekt, men inte tvärtom. En GPL-komponent på fel plats kan tvinga fram ett val mellan omlicensiering, omkonstruering eller borttagning – mycket billigare före lansering än efter.

Tillskrivnings- och meddelandeskyldigheter

De vanligaste brotten mot skyldigheterna är de minst dramatiska: reproduktion av upphovsrättsmeddelanden, licenstexter, ansvarsfriskrivningar och, under Apache 2.0, NOTICE-innehåll i materialet som medföljer distributionen. Varje familj inför dem, inklusive MIT och BSD. De bryts eftersom ingen äger dem, och är enklast att åtgärda – vanligtvis en genererad attributionsfil som medföljer produkten. Det holländska fallet ovan handlade om just detta fel.

Patentbeviljande och patentrepressalier

MIT och BSD säger ingenting om patent, och huruvida en patentlicens kan vara underförstådd är oklart. Apache 2.0 lade till en uttrycklig, royaltyfri patentlicens från varje bidragsgivare, i kombination med en repressalieklausul: väcka patenttvister där man påstår att verket gör intrång och din patentlicens upphör. GPLv3 innehåller ett jämförbart beviljande och sina egna patentbestämmelser.

Två konsekvenser för företag med patentportföljer. Om dina ingenjörer bidrar till Apache- eller GPLv3-licensierade projekt, beviljar du licenser under dina egna patent. Och om du någonsin gör patentanspråk mot ett företag som är beroende av samma Apache-licensierade komponenter som du använder, kan vedergällning kosta dig en licens du förlitar dig på.

EUPL och den nederländska offentliga sektorn

Europeiska unionens offentliga licens version 1.2, godkänd av Europeiska kommissionen genom genomförandebeslut i maj 2017, är en OSI-godkänd upphovsrättslicens med tre utmärkande egenskaper.

• Språk. Den finns på de officiella EU-språken, där alla godkända versioner har identiskt värde, så en nederländsk myndighet kan ingå avtal på nederländska.
• Kompatibilitet. En bilaga listar kompatibla licenser — bland annat GPLv2 och v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL och CeCILL — och tillåter att ett härlett verk som kombinerar EUPL-kod med kod under en listad licens distribueras under den licensen istället.
• Nå. Dess definition av distribution omfattar att göra verket tillgängligt online eller offline eller ge tillgång till dess väsentliga funktioner, och artikel 5 i EUPL överför upphovsrättsskyldigheten till fjärrinteraktion där samma funktionalitet erbjuds. Den når därför programvara som levereras som en tjänst, på ett sätt som GPL inte gör.

En nederländsk offentlig kund kan kräva EUPL som en policy snarare än lagstadgad. Interoperable Europe Act, förordning (EU) 2024/903, ålägger offentliga myndigheter att prioritera interoperabilitetslösningar utan restriktiva licensvillkor, såsom öppen källkod, där det är motsvarande; nationellt vilar principen om öppen källkod, tenzij, på regeringsbeslut och policylinjer, inte på lagstadgad: Wet digitale voorziening underlättar den digitala identitetsinfrastrukturen men medför ingen verkställbar skyldighet att publicera all källkod. Läs anbudsdokumenten: ett EUPL-krav binder din leverans och kan vara oförenligt med proprietär kod som du avsåg att återanvända.

Tillämpning i praktiken

Vem kan stämma? Rättighetsinnehavaren — enskilda bidragsgivare, eller stiftelsen eller företaget som innehar tilldelad upphovsrätt. Fragmenterat upphovsrätt är den praktiska bromsen: en kärande måste bevisa äganderätten till den aktuella koden. Detta ogillade det mest kända europeiska GPL-fallet, där en kärnutvecklares talan mot en virtualiseringsleverantör ogillades på grund av brist på bevis på upphovsrätt (LG Hamburg 8 juli 2016, 310 O 89/15; bifallet OLG Hamburg 28 februari 2019, 5 U 146/16).

Vad rättspraxis fastställer. Tyska domstolar har upprepade gånger accepterat att licenser för öppen källkod är giltiga och att brott mot licensen gör distribution olaglig, med början i och med det första GPL-föreläggandet (LG München I 19 maj 2004, 21 O 6123/04). Den amerikanska federala domstolen kom fram till samma slutsats i Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): licensvillkor är villkor för beviljandets omfattning, inte bara avtal, så brottet stöder ett upphovsrättsanspråk och ett förbudsföreläggande. Amerikanska tvister undersöker huruvida en mottagare nedströms kan göra gällande GPL som tredjepartsförmånstagare. Det är den centrala frågan i Software Freedom Conservancy v Vizio inför Superior Court of California: huruvida konsumenter, som tredjepartsförmånstagare, kan kräva att källkoden släpps enligt GPLv2. Den 23 december 2025 avgjorde domstolen en punkt i den summariska domen och slog fast att GPLv2 och LGPLv2.1 kräver källkod som kan erhållas och omarbetas för användning någon annanstans snarare än källkod som kan ominstalleras på enheten med intakt funktionalitet. Själva frågan om tredjepartsförmånstagare lämnades över till domstolsprövningen, som har skjutits upp mer än en gång. Det är i vilket fall som helst en kalifornisk avtalsrättsfråga, så den är inte bindande i Nederländerna; vad den skulle ändra är antalet personer som kan klaga.

Hur en nederländsk domstol skulle hantera det. Som upphovsrättsintrång enligt Auteurswet: käranden bevisar äganderätt och reproduktion eller överföring; svaranden åberopar licensen; käranden svarar att dess villkor inte var uppfyllda, så försvaret misslyckas. Avtalsrättsliga åtgärder enligt artikel 6:265 BW löper parallellt, men upphovsrätt är den starkare vägen.

Rättsmedel. Ett förbud enligt artikel 3:296 i BW, vanligtvis med vite och tillgängligt i summariska förfaranden; skadestånd enligt artikel 27 i lagen om tillämpning av ...

När du upptäcker ett efterlevnadsproblem

Upptäckt kommer vanligtvis från en kunds säkerhetsfrågeformulär, en skanning under due diligence eller ett brev från en rättighetshavare. Åtgärden går sedan till enligt följande. Stoppa distributionen av den berörda builden om exponeringen är allvarlig. Fastställ vilken komponent, vilken version, vilken licens, vilka produkter och utgåvor, under vilken period. Ta reda på vad licensen faktiskt kräver – ofta en attributionsfil snarare än en källkodsrelease. Förbered artefakterna: meddelanden, licenstexter, komplettera motsvarande källkod inklusive byggskript och ett skriftligt erbjudande där det använts. Skicka en kompatibel release och berätta sedan för rättighetshavaren vad du har gjort istället för att argumentera om du var tvungen att göra det.

Enligt GPLv3 och AGPLv3 ger åtgärdsfönstret rättsligt värde för snabbhet; enligt GPLv2 finns det ingen rätt till åtgärd, vilket är anledningen till att de flesta verkställighetsåtgärder slutar i ett förhandlat efterlevnadsåtagande. Observera också att sekretessen gäller råd från din advokat, inte en intern teknisk rapport.

Öppen källkod inom fusioner och förvärv och due diligence

Vid mjukvaruförvärv är öppen källkod ett standardmässigt arbetsflöde för noggrannhetstester, och en icke avslöjad copyright-komponent i kärnprodukten är ett av få fynd som verkligen påverkar en affär: om produkten inte kan distribueras utan att källan släpps, förvärvar köparen en annan tillgång än den som prissatts.

Förvänta dig en kodbasskanning, en komponentinventering med licenser och frågor om bidragsgivares och entreprenörsavtal. Typiska resultat är en specifik ersättning, en kvarhållning i avvaktan på åtgärd, ett villkor som kräver borttagning eller en skräddarsydd garanti för öppen källkod. Säljare bör först skanna: resultat som du redovisar är en förhandling, resultat som köparens rådgivare gör är hävstångseffekt. Köpare bör inte söka "att företaget äger sin IP" utan en representation av att ingen produkt innehåller öppen källkod som kräver avslöjande av proprietär källkod.

Materialförteckning, skanning och lagen om cybermotståndskraft

En materiallista för programvara är en inventering av en produkts komponenter, med versioner och licenser. Fram tills nyligen är den rent avtalsenlig, nu är den även regulatorisk.

Cyberresilienslagen, förordning (EU) 2024/2847, trädde i kraft den 10 december 2024 och fasas in. Den står i kraft vid sidan av den nederländska cybersäkerhetslagen , som avser organisationen snarare än produkten. Rapporteringsskyldigheterna för aktivt utnyttjade sårbarheter och allvarliga incidenter i artikel 14 i CRA gäller från och med den 11 september 2026; bestämmelserna om anmälan av organ för bedömning av överensstämmelse från och med den 11 juni 2026; förordningen i sin helhet från och med den 11 december 2027 (artikel 71 i CRA). Bilaga I till CRA kräver att tillverkare identifierar och dokumenterar komponenterna i produkten, bland annat genom att upprätta en materialförteckning för programvaran i ett vanligt förekommande och maskinläsbart format som åtminstone omfattar de övergripande beroendena. Den behöver inte offentliggöras; marknadsövervakningsmyndigheterna kan begära det.

Fri och öppen källkodsprogramvara som levereras utanför en kommersiell verksamhet faller utanför kreditvärderingsförordningen. Förordningen introducerar förvaltaren av öppen källkodsprogramvara – en juridisk person som ger varaktigt stöd till utvecklingen av programvara med öppen källkod avsedd för kommersiell verksamhet – med lindrigare skyldigheter i artikel 24 i kreditvärderingsförordningen: en dokumenterad cybersäkerhetspolicy, samarbete med marknadsövervakningsmyndigheter och rapportering. Om du kommersialiserar öppen källkod, eller finansierar ett projekt som andra kommersialiserar, fastställ vilken roll du innehar. Kommissionen antog sin första vägledning den 27 juli 2026: kommissionens vägledning om tillämpningen av lagen om cybermotståndskraft (CRA), bifogad till meddelande C(2026) 5252, som bland annat behandlar när fri och öppen källkodsprogramvara faller inom tillämpningsområdet. Ingen genomförandeakt som föreskriver ett format för programvarans materialförteckning har antagits, så förordningens egen standard – ett vanligt använt, maskinläsbart format – förblir åtgärden för närvarande.

Analys av programvarukomposition som körs i CI genererar inventeringen som hanterar efterlevnad, licensgranskning och noggrannhet samtidigt. Sådana verktyg missar leverantörskod, identifierar projekt med dubbellicenser felaktigt och kan inte läsa en licens villkor: behandla utdata som början på granskningen, inte granskningen.

Om du publicerar din egen kod: CLA:er och DCO:n

Ett företag som släpper kod och accepterar externa bidrag måste veta att det har rättigheterna till det som sammanfogas. Ett bidragslicensavtal är ett kontrakt mellan projekt och bidragsgivare, som vanligtvis beviljar en bred upphovsrättslicens och en uttrycklig patentlicens, med garantier för originalitet och auktoritet. Det är det som låter ett företag omlicensiera sitt projekt senare, eller erbjuda kommersiella licenser vid sidan av öppen källkod. Kostnaden är friktion.

Utvecklarcertifikatet (Developer Certificate of Origin) , som används av Linuxkärnan och många andra projekt, är inte ett licensbeviljande utan en lättviktig bekräftelse, som läggs till som en signeringsrad till varje commit, om att bidragsgivaren får skicka in koden under projektets licens. Mindre betungande och mindre skyddande: ingen patentlicens, ingen omlicensiering.

Om dubbellicensiering eller en framtida omlicensiering är rimlig, använd ett CLA; om projektet är ett genuint commons räcker det vanligtvis med ett DCO. Hur som helst, se till att dina anställnings- och entreprenörsavtal tilldelar upphovsrätt till den kod som dina anställda skriver.

En praktisk checklista för policyer

• Generera ett komponentlager per produkt och släpp i byggpipelinen, inte manuellt.
• Publicera en intern policy: en lista över tillåtna ämnen, en lista över förbjudna ämnen och en godkännandeväg för allt annat.
• Definiera skriftligen vad som räknas som distribution – lokala installationer, apparater, containrar, SDK:er, mobilappar, firmware.
• Skicka en genererad attributionsfil med varje produkt.
• Godkänn licensval vid designtillfället, när en komponent väljs, inte vid lansering.
• Bestäm om bidrag till externa projekt behöver godkännande, med tanke på de berörda patentbidragen, och välj ett CLA eller ett DCO före det första externa bidraget.
• Anpassa garantier, ersättningar och escrow-villkor för immateriella rättigheter med den öppna källkod som faktiskt finns i produkten.
• Gör granskningen före en insamlings- eller försäljningsprocess, inte under en sådan.

Law & More ger råd till mjukvaruföretag och deras investerare Eindhoven och Amsterdam om efterlevnad av öppen källkod, licensgranskning, bidragsarrangemang och arbetsflödet för öppen källkod i en transaktion.