Open source‑licenser, når koden er brugt uden at følge vilkårene

I har udgivet kode under en open source-licens, og nu dukker den op i et kommercielt produkt, der hverken nævner jer, medsender licensen eller stiller kildekoden til rådighed. Open source betyder, at andre må bruge koden på licensens vilkår, og vilkårene er netop det, sagen drejer sig om. Hvad I kan kræve, hviler på tre forhold, som skal dokumenteres: at koden er jeres, hvilken licens der gjaldt, og hvordan den anden part har brugt koden.

Open source er stadig ophavsret

En licens som MIT, Apache eller GPL er en tilladelse fra den, der har ophavsretten. Uden ophavsret er der ingen licens at give. Ophavsretsloven § 1, stk. 3, regner edb-programmer til de litterære værker, og § 2 giver ophavsmanden eneret til at råde over værket med de begrænsninger, loven fastsætter. Licensen fastlægger, på hvilke vilkår andre må bruge, ændre og videregive koden.

Vilkårene er forskellige fra licens til licens. MIT-licensen kræver, at copyrightmeddelelsen og tilladelsesteksten følger med i alle kopier. GPL version 3 kræver i afsnit 6, at den, der videregiver programmet i objektkode, også stiller den tilsvarende kildekode til rådighed, og afsnit 8 beskriver, hvordan rettighederne efter licensen ophører ved brud, og hvordan de kan genetableres. Teksten er ikke juridisk rådgivning, og hvordan vilkårene skal forstås i jeres sag, vurderer advokaten. Open Source Initiative har en liste over godkendte licenser med deres fulde tekst.

Vis, at koden er jeres

Udgangspunktet er, at I kan dokumentere ophavet. Ved open source er det ofte mere indviklet, end man tror, fordi mange kan have bidraget.

Versionshistorik · repositoriet med commits, forfattere og datoer. → Bevis for, at I var først: de spor, der holder
Bidragydere · hvem der har skrevet de dele, der er brugt, og om de var ansatte, frivillige eller eksterne.
Bidragsaftaler · eventuelle aftaler, hvor bidragydere har overdraget eller givet licens til jer.
Copyrightmeddelelser · overskrifter i filerne og den tekst, der stod i projektets licensfil.
Udgivelser · pakker og tags med dato, fx på en offentlig pakkeregistrering.

Er dele af koden skrevet af andre bidragydere uden en aftale, kan det have betydning for, hvem der kan gøre kravet gældende. Det spørgsmål skal advokaten have med fra starten.

Koden kan også være nået frem via en afledt udgave. Mange projekter bliver forgrenet, og den anden part kan have hentet en fork frem for jeres eget repository. Kortlæg i så fald kæden: hvilken version af jeres kode forken bygger på, hvilken licens forken angiver, og om jeres copyrightmeddelelser stadig står i filerne. Sikr forkens side og historik på samme måde som jeres egen.

Vis, hvilken licens der gjaldt

Licenser kan skifte undervejs i et projekts liv. Det er derfor licensen på det tidspunkt, hvor koden blev hentet, der er relevant.

☐ Licensfilens historik i repositoriet, så det ses, hvornår den blev indført eller ændret
☐ Den version af koden, I mener er brugt, med den licens, der fulgte med
☐ Projektets hjemmeside og dokumentation på det tidspunkt, også i arkiver som Wayback Machine
☐ Eventuelle dobbeltlicenser eller kommercielle licenser, I også tilbyder

Dokumentér brugen hos den anden part

Det, der er synligt for en almindelig bruger eller køber, kan dokumenteres som andet online materiale. → Sådan dokumenteres en hel hjemmeside, før den ændres

Produktets egne oplysninger · skærmen “Om” eller “Licenser”, vejledninger og tredjepartslister.
Distributionen · hvordan produktet leveres: app, installationsfil, firmware, fysisk enhed eller kun som tjeneste.
Tilbud om kildekode · om der er et sådant tilbud, og hvordan det er formuleret.
Markedsføring · påstande om, at produktet er udviklet af virksomheden selv.
Henvendelser · har I tidligere skrevet til virksomheden, så gem korrespondancen.

Leveringsformen har betydning, fordi nogle licenser knytter vilkårene til, at programmet videregives. Notér derfor, om I har modtaget en kopi af programmet, og hvordan.

Er produktet en fysisk enhed, kan et køb være den mest direkte vej til at se, hvad der følger med. Gem emballage, trykte vejledninger og eventuelle licenssedler, og fotografér de skærme i enheden, der viser licensoplysninger. → Testkøb af kopien

Gå ikke selv i gang med at skille et program ad for at finde jeres kode. Ophavsretsloven § 37 sætter snævre rammer for den slags, og en dybere analyse bør aftales med advokaten og udføres af en IT-sagkyndig. → Sådan sammenligner en IT-sagkyndig to programmer

Det skal I lade være med

Ændre licensen nu · det gør det sværere at vise, hvilke vilkår der gjaldt, da koden blev hentet.
Udstille virksomheden offentligt · et opslag i et forum eller på sociale medier kan skabe en ny tvist.
Antage, at en tjeneste på nettet altid er omfattet · om vilkårene gælder, afhænger af licensen og af, hvordan programmet bruges.
Glemme bidragyderne · krav, der rejses uden at vide, hvem der ejer hvad, kan falde fra hinanden.
Sende en hård henvendelse fra projektets mailadresse · lad advokaten se den først. → Henvendelsen til den, der har kopieret

Hvad dokumentationen kan og ikke kan vise

Dokumentationen kan vise, hvem der har skrevet koden, hvilken licens den var udgivet under, og hvad den anden part viser, leverer og oplyser. Den kan ikke afgøre, om brugen er et brud på licensen, hvad bruddet betyder for den anden parts ret til at bruge koden, eller hvad der kan kræves. Det er spørgsmål for advokaten.

Hvad sikrer I nu, og hvad er næste skridt?

Gem repositoriet urørt sammen med licensfilens historik, lav en oversigt over bidragydere, og dokumentér produktets licensoplysninger og leveringsform. Giv materialet til advokaten, før der skrives til virksomheden. → Hvornår skal en advokat ind over?

Hvordan en softwarestykliste (SBOM) bruges som dokumentation i licenssager, er beskrevet på søstersitet for advokater. → Open source-licensbrud: SBOM som bevis

Kilder

Ophavsretsloven, LBK nr. 1093 af 20. august 2023: § 1, stk. 3, § 2 og § 37.
GNU General Public License version 3 hos Open Source Initiative: afsnit 6 om kildekode og afsnit 8 om ophør.
MIT-licensen hos Open Source Initiative: krav om copyrightmeddelelse og tilladelsestekst.
Open Source Initiative: licenser: liste over godkendte licenser.

Senest gennemgået: november 2026.

Næste skridt

Del af: Artikler om kopiering og ophavsret

Læs også: Jeres app er kopieret i en appbutik · Arkivér jeres egen side løbende · Kopieret kode på GitHub: anmeldelsen og det, den skal vise

→ Kontakt · Tlf. 70 13 63 23 · Bevissikring ved kopiering hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

Er I blevet kopieret?

Skriv kort, hvad der er kopieret, hvor I har set kopien, og om den stadig er online. Så vender jeg tilbage. Arbejdet er uvildigt og uafhængigt, og der laves konflikttjek af parterne, før opgaven tages.