Programvarelisenser med åpen kildekode under nederlandsk og EU-lovgivning

Nesten alle kommersielle programvareprodukter inneholder komponenter med åpen kildekode, vanligvis hundrevis, valgt av utviklere i stedet for advokater. Det blir et problem når ingen kan si hvilke lisenser som gjelder, hva de krever og om produktet overholder regelverket. Denne artikkelen forklarer hvordan lisenser med åpen kildekode fungerer under nederlandsk og EU-lovgivning, hvor risikoen ligger og hva man bør ha på plass.

Hva en åpen kildekode-lisens er, juridisk sett

En åpen kildekode-lisens er en opphavsrettslisens som gis underlagt betingelser. Det er ikke en fraskrivelse, ikke en dedikasjon til det offentlige domene, ikke en oppgivelse av rettigheter, og i så måte fungerer den som enhver annen programvarelisens under nederlandsk lov . Opphavsmannen beholder opphavsretten i henhold til art. 1 Aw og art. 10 Aw, som beskytter dataprogrammer som verk, og lisensen tillater handlinger som ellers ville krenke de eksklusive rettighetene i henhold til art. 12 Aw og art. 13 Aw.

Konsekvensen er viktigere enn definisjonen. Overhold opphavsretten, og kopieringen og distribusjonen din er lovlig. Unnlatelse av å overholde opphavsretten, og tillatelsen dekker ikke det du gjorde: bruken din er brudd på opphavsretten, ikke kontraktsbrudd. De fleste opphavsrettslisenser forsterker dette ved å opphøre automatisk ved brudd – GPLv2 uten noen rettelsesperiode, mens GPLv3 og AGPLv3 gjenoppretter rettighetene hvis bruddet rettes innen et definert vindu etter varsel.

Nederlandske domstoler anvender denne begrunnelsen. I Rb. Amsterdam 22. september 2020, ECLI:NL:RBAMS:2020:4717, ble en distributør som fjernet lisensteksten og opphavsrettserklæringen fra en forgrenet kodebase, ansett for å ha mistet sin tillatelse og for å være i ferd med å krenke opphavsretten. Å legge til en stor mengde ny kode skapte ikke et uavhengig verk: originalen forble gjenkjennelig tilstede, så forpliktelsene fulgte med.

De to familiene: permissiv og opphavsrettslig

Tillatende lisenser – MIT, BSD-lisensene, Apache 2.0 – tillater bruk, modifisering og videredistribusjon, inkludert i lukkede kildekode-produkter, forutsatt at du bevarer opphavsrettserklæringer og lisenstekst.

Opphavsrettslisenser krever at når du distribuerer programvaren, eller noe som er bygget på den, gjør du det under samme lisens og gjør tilsvarende kilde tilgjengelig. De har ulik rekkevidde.

Copyleft-utløseren og lenkespørsmålet

Opphavsrettslige forpliktelser påvirker distribusjon, ikke bruk. Et selskap som kjører GPL-programvare internt, uansett hvor kraftig modifisert det er, distribuerer ingenting og skylder ingenting. «Har vi distribuert?» er alltid det første spørsmålet, og det er derfor containere, apparater, firmware og SDK-er er viktigere enn interne verktøy.

Det andre spørsmålet er vanskeligere. GPL snakker om et «verk basert på programmet», og låner det amerikanske konseptet om et avledet verk. Nederlandsk lov har ikke noe slikt begrep: analysen går gjennom reproduksjons- og tilpasningsrettighetene, og spør om beskyttet uttrykk fra originalen har blitt reprodusert.

Det praktiske tilfellet er lenking. Hvorvidt det å lenke en proprietær modul til et GPL-bibliotek skaper ett verk som er underlagt opphavsrett, har aldri blitt avgjort av en nederlandsk domstol, og det finnes ingen bindende EU-myndighet. Free Software Foundations syn om at lenking skaper et kombinert verk er lisensforvalterens tolkning, ikke lov, og det motsatte synet er like uprøvd. Internetts favorittsvar – dynamisk lenking er trygg, statisk lenking ikke – har ingen basis i nederlandsk opphavsrettslovgivning, som ikke spør hvordan en kompilator oppfører seg. En mer forsvarlig analyse spør hvor tett komponentene er kombinert: deler de et adresserom og datastrukturer, sendes kombinasjonen som ett produkt, kan den enten fungere alene, reproduserer den proprietære siden overskrifter, makroer eller innebygd kode fra opphavsrettssiden? Disse spørsmålene løser vanligvis risikoen. Der de ikke gjør det, isolerer du komponenten bak en prosessgrense, erstatter den eller tar en kommersiell lisens.

AGPL og nettverksbruk

AGPL eksisterer fordi opphavsretten utløses av distribusjon, og SaaS-leverandører distribuerer ikke. Nettverksklausulen krever at hvis du endrer programvaren og gjør den tilgjengelig for brukere som samhandler med den eksternt, tilbyr du dem den tilsvarende kilden til din modifiserte versjon.

Tre punkter blir ofte oversett. Forpliktelsen gjelder for brukerne av tjenesten, noe som i et produkt med åpen registrering er lite trygt. Den utløses av modifikasjon, så en umodifisert komponent aktiverer den ikke, men en oppdatert versjon kan gjøre det. Og den reiser det samme spørsmålet om kombinert arbeid som GPL for resten av stacken din – og det er derfor mange selskaper forbyr AGPL i produksjonskode.

Lisenskompatibilitet

Kompatibilitet er problemet med å kombinere komponenter med lisenser som pålegger forpliktelser som ikke begge kan oppfylles i én distribusjon: permissive lisenser er kompatible med nesten alt, mens opphavsrettslisenser bare er kompatible med det deres egne vilkår tillater. Standardtilfellet er Apache 2.0 og GPLv2. Apache Software Foundation og Free Software Foundation er enige om at kombinasjonen ikke er tillatt, fordi Apache 2.0s bestemmelser om patentoppsigelse og skadesløsholdelse er tilleggsbegrensninger som GPLv2 ikke tillater. GPLv3 ble utarbeidet for å akseptere dem. Kompatibilitet er også retningsbestemt: Apache-kode kan absorberes i et GPLv3-prosjekt, men ikke omvendt. Én GPL-komponent på feil sted kan tvinge frem et valg mellom ny lisensiering, nyutvikling eller fjerning – mye billigere før utgivelse enn etter.

Krediterings- og varslingsplikter

De hyppigst bruddene på forpliktelsene er de minst dramatiske: reproduksjon av opphavsrettserklæringer, lisenstekster, ansvarsfraskrivelser og, under Apache 2.0, NOTICE-innhold i materialene som følger med distribusjonen. Alle familier pålegger dem, inkludert MIT og BSD. De brytes fordi ingen eier dem, og er enklest å fikse – vanligvis en generert attribusjonsfil som følger med produktet. Den nederlandske saken ovenfor dreide seg om nettopp denne feilen.

Patentbevilgninger og patentgjengjeldelse

MIT og BSD sier ingenting om patenter, og hvorvidt en patentlisens kan være underforstått er uavklart. Apache 2.0 la til en uttrykkelig, royaltyfri patentlisens fra hver bidragsyter, kombinert med en gjengjeldelsesklausul: anlegg patentsøksmål der du hevder at verket krenker, og patentlisensen din opphører. GPLv3 inneholder en sammenlignbar bevilgning og egne patentbestemmelser.

To implikasjoner for selskaper med patentporteføljer. Hvis ingeniørene dine bidrar til Apache- eller GPLv3-lisensierte prosjekter, gir du lisenser under dine egne patenter. Og hvis du noen gang hevder patenter mot et selskap som er avhengig av de samme Apache-lisensierte komponentene som du bruker, kan gjengjeldelse koste deg en lisens du er avhengig av.

EUPL og den nederlandske offentlige sektoren

Den europeiske unions offentlige lisens versjon 1.2, godkjent av EU-kommisjonen ved implementeringsbeslutning i mai 2017, er en OSI-godkjent opphavsrettslisens med tre særtrekk.

• Språk. Den finnes på de offisielle EU-språkene, og alle godkjente versjoner har identisk verdi, slik at en nederlandsk myndighet kan inngå kontrakter på nederlandsk.
• Kompatibilitet. Et tillegg viser kompatible lisenser – blant annet GPLv2 og v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL og CeCILL – og tillater at et avledet verk som kombinerer EUPL-kode med kode under en oppført lisens distribueres under den lisensen i stedet.
• Å nå. Definisjonen av distribusjon dekker å gjøre verket tilgjengelig på nett eller offline eller gi tilgang til dens essensielle funksjoner, og art. 5 i EUPL overfører opphavsrettsplikten til fjerninteraksjon der den samme funksjonaliteten tilbys. Den når derfor ut til programvare levert som en tjeneste, på en måte som GPL ikke gjør.

En nederlandsk offentlig kunde kan kreve EUPL som et spørsmål om policy snarere enn lov. Interoperable Europe Act, forordning (EU) 2024/903, pålegger offentlige organer å prioritere interoperabilitetsløsninger uten restriktive lisensvilkår, for eksempel åpen kildekode, der det er tilsvarende; nasjonalt hviler prinsippet om åpen kildekode, tenzij, på regjeringens vedtak og politiske linjer, ikke på lov: Wet digitale voorziening tilrettelegger for den digitale identitetsinfrastrukturen, men pålegger ingen håndhevbar forpliktelse til å publisere all kildekode. Les anbudsdokumentene: et EUPL-krav binder leveransen din og kan være inkompatibelt med proprietær kode du hadde til hensikt å gjenbruke.

Håndheving i praksis

Hvem kan saksøke? Rettighetshaveren – individuelle bidragsytere, eller stiftelsen eller selskapet som har tildelt opphavsrett. Fragmentert forfatterskap er den praktiske bremsen: en saksøker må bevise eierskap til den aktuelle koden. Dette avviste den mest kjente europeiske GPL-saken, der en kjerneutviklers krav mot en virtualiseringsleverandør mislyktes på grunn av manglende bevis for forfatterskap (LG Hamburg 8. juli 2016, 310 O 89/15; opprettholdt OLG Hamburg 28. februar 2019, 5 U 146/16).

Hva rettspraksis fastslår. Tyske domstoler har gjentatte ganger akseptert at lisenser for åpen kildekode er gyldige og at brudd gjør distribusjon ulovlig, og det starter med det første GPL-forbudet (LG München I 19. mai 2004, 21 O 6123/04). Den amerikanske føderale kretsdomstolen kom til samme konklusjon i Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): lisensvilkår er betingelser for omfanget av tildelingen, ikke bare betingelser, så bruddet støtter et opphavsrettskrav og et forføyningsforbud. Amerikanske søksmål undersøker om en nedstrøms mottaker kan håndheve GPL som tredjepartsbegunstiget. Det er det sentrale spørsmålet i Software Freedom Conservancy v Vizio for Superior Court of California: om forbrukere, som tredjepartsbegunstigede, kan kreve utgivelse av kildekoden under GPLv2. Den 23. desember 2025 avgjorde retten ett punkt i den summariske avgjørelsen, og slo fast at GPLv2 og LGPLv2.1 krever kildekode som kan innhentes og omarbeides for bruk andre steder, i stedet for kildekode som kan installeres på nytt på enheten med intakt funksjonalitet. Spørsmålet om tredjepartsbegunstiget ble i seg selv overlatt til benkesaken, som har blitt utsatt mer enn én gang. Det er uansett et spørsmål om kalifornisk kontraktsrett, så det er ikke bindende i Nederland. Det som ville endret seg er antallet personer som kan klage.

Hvordan en nederlandsk domstol ville handle. Som brudd på opphavsretten i henhold til Auteurswet: saksøker beviser eierskap og reproduksjon eller kommunikasjon; saksøkte påberoper seg lisensen; saksøker svarer at vilkårene ikke var oppfylt, slik at forsvaret mislykkes. Kontraktsmessige rettsmidler i henhold til art. 6:265 BW løper parallelt, men opphavsrett er den sterkere veien.

Rettsmidler. Et forføyning i henhold til art. 3:296 i BW, vanligvis med tvangsmulkt og tilgjengelig i summarisk prosess; erstatning i henhold til art. 27 i Aw og en redegjørelse for fortjeneste i henhold til art. 27a i Aw; tilbakekalling, overlevering eller destruksjon i henhold til art. 28 i Aw; og full dekning av rimelige og forholdsmessige saksomkostninger i henhold til art. 1019h Rv. Der programvare ble distribuert gratis, er tapet vanskelig å tallfeste, og en tysk ankedomstol nektet å tilkjenne erstatning, men opprettholdt forføyningen (OLG Hamm 13. juni 2017, 4 U 72/16). Det som biter på saken er sjelden erstatning: det er forføyningen, tilbakekallingen, saksomkostninger og å måtte publisere kilde du aldri hadde til hensikt å publisere.

Når du oppdager et samsvarsproblem

Oppdagelse kommer vanligvis fra en kundes sikkerhetsspørreskjema, en skanning under due diligence, eller et brev fra en rettighetshaver. Utbedring skjer deretter som følger. Stopp distribusjonen av den berørte versjonen hvis eksponeringen er alvorlig. Fastslå hvilken komponent, hvilken versjon, hvilken lisens, hvilke produkter og utgivelser, over hvilken periode. Finn ut hva lisensen faktisk krever – ofte en attribusjonsfil i stedet for en kildeutgivelse. Forbered artefaktene: varsler, lisenstekster, fullfør tilsvarende kilde inkludert byggeskript og et skriftlig tilbud der det er brukt. Send en kompatibel utgivelse, og fortell deretter rettighetshaveren hva du har gjort i stedet for å krangle om du måtte.

Under GPLv3 og AGPLv3 gir kureringsvinduet juridisk verdi for raskere håndheving; under GPLv2 finnes det ingen rett til kurering, og det er derfor mesteparten av håndhevingen ender i en forhandlet samsvarserklæring. Merk også at privilegiet gjelder råd fra advokaten din, ikke en intern ingeniørrapport.

Åpen kildekode innen fusjoner og oppkjøp og due diligence

Ved programvareoppkjøp er åpen kildekode en standard due diligence-prosess, og en ikke-oppgitt opphavsrettskomponent i kjerneproduktet er et av de få funnene som virkelig driver en avtale: hvis produktet ikke kan distribueres uten å oppgi kildekoden, kjøper kjøperen en annen eiendel enn den som er priset.

Forvent en kodebaseskanning, en komponentinventarliste med lisenser og spørsmål om avtaler mellom bidragsytere og leverandører. Typiske utfall er en spesifikk erstatning, en tilbakeholdelse i påvente av utbedring, en forutsetning for fjerning, eller en skreddersydd garanti med åpen kildekode. Selgere bør skanne først: funn du oppgir er en forhandling, funn kjøperens rådgiver gjør er innflytelsesrike. Kjøpere bør ikke søke «at selskapet eier sin IP», men en representasjon av at ingen produkter inneholder åpen kildekode som krever opplysning om proprietær kildekode.

Materialfortegnelsen, skanning og loven om cyberrobusthet

En programvareliste er en oversikt over et produkts komponenter, med versjoner og lisenser. Inntil nylig er den rent kontraktsmessig, men nå er den også regulatorisk.

Lov om cyberrobusthet, forordning (EU) 2024/2847, trådte i kraft 10. desember 2024 og innføres gradvis. Den står sammen med den nederlandske cybersikkerhetsloven , som omhandler organisasjonen snarere enn produktet. Rapporteringspliktene for aktivt utnyttede sårbarheter og alvorlige hendelser i art. 14 i CRA gjelder fra 11. september 2026; bestemmelsene om varsling av samsvarsvurderingsorganer fra 11. juni 2026; forordningen i sin helhet fra 11. desember 2027 (art. 71 i CRA). Vedlegg I i CRA krever at produsenter identifiserer og dokumenterer komponentene i produktet, blant annet ved å utarbeide en programvareliste i et vanlig brukt og maskinlesbart format som minst dekker de øverste avhengighetene. Den trenger ikke å publiseres; markedstilsynsmyndighetene kan be om det.

Fri og åpen kildekode-programvare levert utenfor en kommersiell aktivitet faller utenfor CRA. Forordningen introduserer forvalteren av åpen kildekode-programvare – en juridisk person som gir vedvarende støtte til utvikling av åpen kildekode-programvare beregnet på kommersiell aktivitet – med lettere forpliktelser i art. 24 i CRA: en dokumentert cybersikkerhetspolicy, samarbeid med markedstilsynsmyndigheter og rapportering. Hvis du kommersialiserer åpen kildekode, eller finansierer et prosjekt som andre kommersialiserer, må du fastslå hvilken rolle du har. Kommisjonen vedtok sin første veiledning 27. juli 2026: Kommisjonens veiledning om anvendelsen av Cyber ​​Resilience Act (CRA), som er vedlagt kommunikasjon C(2026) 5252, som blant annet omhandler når fri og åpen kildekode-programvare faller inn under virkeområdet. Ingen gjennomføringsrettsakt som foreskriver et format for programvarens materialliste er vedtatt, så forordningens egen standard – et vanlig brukt, maskinlesbart format – forblir tiltaket foreløpig.

Analyse av programvaresammensetning som kjøres i CI genererer inventaret som betjener samsvar, lisensgjennomgang og diligence samtidig. Slike verktøy overser leverandørkode, identifiserer dobbeltlisensierte prosjekter feil og kan ikke lese en lisens' betingelser: behandle resultatet som starten på gjennomgangen, ikke selve gjennomgangen.

Hvis du publiserer din egen kode: CLA-er og DCO-en

Et selskap som gir ut kode og aksepterer eksterne bidrag, må vite at det har rettighetene til det det slår sammen. En bidragsyterlisensavtale er en kontrakt mellom prosjekt og bidragsyter, som vanligvis gir en bred opphavsrettslisens og en uttrykkelig patentlisens, med garantier for originalitet og autoritet. Det er det som lar et selskap lisensiere prosjektet sitt på nytt senere, eller tilby kommersielle lisenser ved siden av en åpen kildekode-lisens. Kostnaden er friksjon.

Utviklers opprinnelsesbevis , som brukes av Linux-kjernen og mange andre prosjekter, er ikke en lisensbevilgning, men en lett bekreftelse, lagt til som en signeringslinje til hver commit, om at bidragsyteren kan sende inn koden under prosjektets lisens. Mindre byrdefullt og mindre beskyttende: ingen patentlisens, ingen relisensiering.

Hvis dobbel lisensiering eller en fremtidig relisens er mulig, bruk en CLA. Hvis prosjektet er et ekte commons, er DCO vanligvis nok. Uansett, sørg for at arbeidsavtalene og kontraktøravtalene dine tildeler opphavsrett til koden folkene dine skriver.

En praktisk sjekkliste for retningslinjer

• Generer en komponentbeholdning per produkt og utgi den i byggeprosessen, ikke manuelt.
• Publiser en intern policy: en liste over tillatte ting, en liste over forbudte ting og en godkjenningsrute for alt annet.
• Definer skriftlig hva som teller som distribusjon – lokale installasjoner, apparater, containere, SDK-er, mobilapper, fastvare.
• Send en generert attribusjonsfil med hvert produkt.
• Godkjenn lisensvalg ved designtidspunktet, når en komponent velges, ikke ved utgivelse.
• Avgjør om bidrag til eksterne prosjekter trenger godkjenning, gitt de involverte patenttildelingene, og velg en CLA eller en DCO før det første eksterne bidraget.
• Tilpass garantier, skadesløsholdelser og escrow-vilkår for immaterielle rettigheter med den åpne kildekoden som faktisk er i produktet.
• Kjør gjennomgangen før en innsamlings- eller salgsprosess, ikke underveis i en.

Law & More rådgir programvareselskaper og deres investorer fra Eindhoven og Amsterdam om samsvar med åpen kildekode, lisensgjennomgang, bidragsyteravtaler og arbeidsflyten for åpen kildekode i en transaksjon.