Open source‑licenser og SBOM som bevis i licens- og ophavsretstvister

Forside · Gennemgået oktober 2026 · Af John Nielsen

I en tvist om open source er det tekniske kernespørgsmål sjældent, om en licens er “god” eller “dårlig”. Det er tre faktuelle spørgsmål: hvilke komponenter var med i den software, sagen handler om, hvilken licens gjaldt for netop de versioner, og hvordan var komponenterne indbygget og leveret. Svarene skal kunne dokumenteres for et bestemt tidspunkt, og de bygger på kildekode, byggeartefakter, SBOM’er og arkiverede kopier af de oprindelige projekter.

Den juridiske vurdering af licensbrud er beskrevet på digital-bevissikring.dk. Hvordan SBOM og byggeartefakter dokumenterer en leverance i almindelighed, står i SBOM og byggeartefakter som dokumentation. Her handler det om licensoplysningerne: hvor de findes, hvordan de læses, og hvor de kan tage fejl.

Hvor licensoplysningerne står

En komponents licens kan fremgå flere steder, og de stemmer ikke altid overens:

• Licensfiler i projektets rod, typisk LICENSE, COPYING eller NOTICE.
• Filhoveder i de enkelte kildefiler, ofte med en kort SPDX-identifikator i formen SPDX-License-Identifier: MIT.
• Pakkemetadata i pakkehåndteringen, fx feltet license i package.json eller tilsvarende felter i andre økosystemer.
• SBOM’en, hvis en sådan er dannet, hvor licensen er registreret pr. komponent.

SPDX License List giver hver licens en standardiseret kort identifikator, fx MIT, Apache-2.0 eller GPL-3.0-only, og angiver den præcise licenstekst. Listen opdateres løbende, og ældre identifikatorer kan være markeret som forældede. Det er derfor relevant at notere, hvilken version af listen et værktøj har brugt.

Licensudtryk

En komponent har ikke altid én licens. SPDX har et lille udtrykssprog, der kombinerer licenser:

• MIT OR Apache-2.0 betyder, at modtageren kan vælge mellem licenserne.
• MIT AND BSD-3-Clause betyder, at begge gælder, typisk fordi dele af komponenten har hver sin licens.
• GPL-2.0-or-later WITH Classpath-exception-2.0 betyder en licens med en undtagelse, der ændrer betingelserne.

Forskellen mellem OR og AND kan være afgørende i en tvist, og værktøjer læser dem ikke altid korrekt. En scanner, der finder to licenstekster i samme projekt, kan rapportere begge uden at kunne afgøre, om de gælder samtidig eller alternativt. Det må afklares ved at læse projektets egne oplysninger.

SBOM-formaterne

De to udbredte formater er SPDX og CycloneDX. SPDX er standardiseret som ISO/IEC 5962 for version 2.2.1, og version 3.0 er bygget op om profiler, bl.a. for software, licenser, sikkerhed og build. CycloneDX udvikles af OWASP sammen med Ecma International og er standardiseret som ECMA-424. Begge formater kan registrere licens pr. komponent.

I en tvist skal man skelne mellem to slags licensfelter, som SPDX-formatet holder adskilt: den licens, som pakken selv erklærer, og den licens, som et værktøj eller en person har konkluderet efter analyse. Er der forskel på de to, er det et fund, der skal forklares.

Versionen afgør licensen

Projekter skifter licens. En komponent kan have været under én licens i version 2 og en anden i version 3. Spørgsmålet er derfor altid: hvilken licens gjaldt for præcis den version, der indgik, på det tidspunkt den blev hentet?

Det kræver:

1. Den præcise version fra låsefiler som package-lock.json, poetry.lock eller go.sum, eller fra SBOM’en, helst med komponentens hashværdi.
2. Licensen i den version fra projektets eget repository ved det tilsvarende tag eller commit, ikke fra projektets forside i dag.
3. En uafhængig kopi af den version. Software Heritage arkiverer offentligt tilgængelig kildekode og giver hver fil, mappe og revision en indholdsbaseret identifikator, SWHID, der er standardiseret som ISO/IEC 18670. En SWHID gør det muligt at henvise præcist til den version, der er undersøgt.

Et licensskift fremgår ofte af projektets historik som en ændring i licensfilen. Den commit bør med i dokumentationen sammen med datoen. Se kildekode og Git som bevis om forbeholdene ved datoer i Git.

Hvordan komponenten var indbygget

Licensbetingelser knytter ofte an til, hvordan koden bruges og leveres. Det er en juridisk vurdering, men den bygger på tekniske fakta, som den sagkyndige kan fastlægge:

• Kopieret ind eller hentet som afhængighed. Kode, der er kopieret direkte ind i projektets egne filer, optræder ikke i pakkehåndteringen og ofte heller ikke i SBOM’en. Den findes kun ved at sammenligne med kendte projekter; se kodesammenligning: værktøjer og faldgruber.
• Ændret eller uændret. Er komponenten modificeret, kan ændringerne vises med en diff mod den oprindelige version.
• Linket statisk, dynamisk eller kaldt som separat program. Det kan ses i byggekonfiguration og i det byggede artefakt.
• Leveret til kunden eller kun kørt som tjeneste. Om softwaren blev distribueret som installationsfil, container eller kun stillet til rådighed over netværket, fremgår af leverancen og driftsmiljøet.
• Udviklings- eller produktionsafhængighed. Et testværktøj i SBOM’en er ikke nødvendigvis en del af det leverede produkt.

Licensscannere og deres fejl

Licensscannere sammenligner tekst i filerne med kendte licenstekster og identifikatorer. De er uundværlige i store kodebaser, men giver typiske fejl:

• Falske fund i dokumentation, testdata eller i kode, der blot nævner en licens.
• Manglende fund, når licensen kun står i en ekstern fil, på projektets hjemmeside, eller når kode er kopieret ind uden filhoved.
• Forkert sammenlægning af flere licenser til ét udtryk.
• Forskelle mellem værktøjer, så to scannere giver forskellige lister for samme kodebase.

Brug samme værktøj og version til sammenligninger, gem rå output med hashværdi, og efterprøv manuelt alle fund, der bærer en konklusion.

Sikring i en licens- eller ophavsretstvist

Sikr som minimum:

• kildekoden med fuld historik og låsefiler fra de relevante versioner
• de byggede artefakter, som de blev leveret, med hashværdier
• eventuelle SBOM’er fra leveringstidspunktet og fra byggejobbet
• byggelogs, der viser, hvilke pakker der blev hentet og fra hvilket register; se CI/CD-logs og testdokumentation
• de oprindelige komponenters licensfiler i de relevante versioner, med kilde og SWHID eller commit-id

Gør det tidligt. Pakkeregistre og repositories kan ændres, versioner kan trækkes tilbage, og projekter kan flyttes eller slettes. Se også leverancens tilstand på overdragelsestidspunktet.

Præsentation

En overskuelig rapport viser en tabel pr. relevant komponent med navn, version, kilde, erklæret licens, konkluderet licens og indbygningsmåde, og en kort begrundelse for hvert punkt, hvor de afviger. Usikkerhed angives åbent, fx når en komponent ikke kunne identificeres med sikkerhed, eller når licensoplysningerne i projektet er modstridende.

Hvad det kan og ikke kan bevise

Den tekniske analyse kan vise, hvilke komponenter og versioner der indgik, hvilke licensoplysninger projekterne selv angav på det tidspunkt, og hvordan komponenterne var indbygget og leveret. Den kan ikke afgøre, om betingelserne er overholdt, eller hvad følgen er. Det er juridiske spørgsmål, som den tekniske dokumentation skal gøre det muligt at besvare.

Kilder og versioner

• SPDX: overview og specifikation
• SPDX License List
• CycloneDX: specification overview
• Software Heritage
• ISO/IEC 18670:2025, SWHID

Senest gennemgået: oktober 2026.

Næste skridt

• SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte
• GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
• Massesletning efter en tvist er opstået: tekniske tegn

Læs også: Kodesammenligning ved ophavsretskrænkelse: værktøjer og faldgruber · Kodekvalitet og teknisk gæld som mangel: sådan kan det måles i en tvist

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT