Open source‑licensbrud: SBOM som bevis

Næsten al software indeholder open source-komponenter. Hver komponent har en licens, og licenserne stiller forskellige krav: at ophavsretten oplyses, at licensteksten følger med, eller at kildekoden stilles til rådighed, når programmet videregives. Tvister opstår, når en rettighedshaver mener, at kravene ikke er overholdt, eller når en kunde opdager, at leveret software indeholder komponenter, hvis licens ikke passer med kundens brug. I begge tilfælde er det første spørgsmål faktuelt: Hvad var der i softwaren? Her kommer en SBOM ind i billedet.

Sammenligning af kildekode ved påstået kopiering er behandlet i Ophavsret og software. Denne artikel handler om komponenter og licenser.

Hvad en SBOM er

SBOM står for Software Bill of Materials. Det er en liste over de komponenter, en bestemt version af et program består af. En SBOM indeholder typisk:

komponentens navn og version,
leverandør eller projekt,
licens, som den er registreret,
forhold mellem komponenter, dvs. hvilke der trækker andre med sig,
ofte hashværdier for de enkelte filer.

SBOM’er laves i standardiserede formater, så de kan læses af værktøjer. De mest udbredte er SPDX og CycloneDX.

Hvordan en SBOM bliver til

En SBOM laves næsten altid af et værktøj. Værktøjet kan arbejde på to måder:

Fra kildekoden. Værktøjet læser projektets afhængighedsfiler og finder de komponenter, der er erklæret.
Fra det færdige program. Værktøjet undersøger de filer, der faktisk blev leveret, og genkender komponenter ud fra kendetegn.

De to metoder giver ikke altid samme resultat. En komponent kan være erklæret uden at blive brugt. Omvendt kan kode være kopieret direkte ind i projektet uden at være erklæret som afhængighed. Den slags kopierede stykker ses ofte ikke af den første metode.

Hvad en SBOM kan vise

En SBOM, der er lavet på et kendt tidspunkt ud fra en kendt version, kan understøtte:

at en bestemt komponent i en bestemt version indgik i programmet,
hvilken licens komponenten var registreret med,
hvordan komponenten kom ind, direkte eller via en anden komponent.

Den kan også vise det modsatte: at en påstået komponent ikke var med i den version, der blev leveret.

Hvor den kan tage fejl

Licensregistreringen. Værktøjet aflæser licensen fra metadata eller fra en licensfil. Metadata kan være forkerte, og en komponent kan have flere licenser at vælge imellem.
Kopieret kode. Kodestykker, der er kopieret ind uden at være registreret, kan mangle.
Den forkerte version. En SBOM for udviklingsversionen siger ikke nødvendigvis noget om den version, kunden fik.
Indirekte komponenter. Komponenter, der trækkes med af andre komponenter, kan være udeladt, hvis værktøjet kun ser et lag ned.
Alder. En SBOM lavet i dag ud fra dagens kode beskriver ikke nødvendigvis koden for et år siden.

Det vigtigste spørgsmål er derfor altid: Hvilken version beskriver denne SBOM, og hvordan ved vi det?

At knytte SBOM’en til leverancen

Den stærkeste dokumentation forbinder tre ting:

den version, der faktisk blev leveret eller distribueret, gerne med hashværdi,
det sted i versionsstyringen, hvorfra den blev bygget,
en SBOM lavet ud fra netop den version.

Har leverandøren et byggesystem, der gemmer SBOM’er for hver udgivelse, er det et godt udgangspunkt. Mangler den, kan en sagkyndig ofte genskabe en SBOM ud fra den leverede version, hvis den er gemt. → Mangler ved IT-leverancer

Distribution og brug

Mange licenskrav udløses først, når programmet videregives til andre. Om software, der kun køres som en tjeneste, er videregivet, afhænger af licensens ordlyd.

Teknisk kan advokaten få belyst, hvordan programmet faktisk kom til brugerne: som installationsfil, som app, som indlejret software i et apparat eller kun som en webtjeneste. Det er et faktuelt spørgsmål, som data kan besvare.

Når klienten er leverandøren

Er klienten leverandøren, bør der laves en SBOM ud fra de relevante leverede versioner, så snart en tvist er i sigte, og byggesystemets logs bør bevares. Har leverandøren licensrapporter fra tidligere, bør de sikres med deres oprindelige dato. → Når klienten er IT-leverandøren

Når klienten er kunden eller køberen

Kunden kan have en kopi af den leverede version. Det er værdifuldt, fordi det er den version, kunden har modtaget, uafhængigt af leverandørens oplysninger. Ved køb af en virksomhed kan softwarens komponenter have været et emne i due diligence. → Virksomhedsoverdragelse: datarum og garantibrud

Spørgsmål til skønsmanden

Hvilke komponenter indgik i version X, og under hvilke licenser var de registreret?
Er der kode i version X, som stammer fra komponent Y, uden at være registreret som afhængighed?
Var komponent Y en del af det, der blev leveret til brugerne, eller kun en del af udviklingsværktøjerne?
Kan den fremlagte SBOM knyttes til den leverede version?

Versionsstyringen som tidslinje

Versionsstyringen viser, hvornår en komponent blev tilføjet, opdateret eller fjernet, og af hvem. Det kan være afgørende, når parterne strides om, hvornår en problematisk komponent kom ind, eller om den var fjernet før en bestemt levering. Historikken kan være omskrevet, før den blev sikret. Spørg derfor, om historikken er omskrevet, og sammenhold den med kopier andre steder, fx hos en kunde eller på en byggeserver.

Spørgsmål til klienten

Hvilke versioner er leveret til hvem og hvornår?
Findes der kopier af de leverede versioner?
Bruges der værktøjer, der laver SBOM’er eller licensrapporter automatisk?
Har klienten en politik for, hvilke licenser der må bruges?
Er der kopieret kode ind fra andre projekter uden at registrere den som afhængighed?

Rettighedshaverens dokumentation

Er klienten rettighedshaveren, skal det også dokumenteres, at koden i modpartens program stammer fra klientens projekt, og under hvilken licens den var udgivet på det tidspunkt. Projektets versionshistorik og den licensfil, der lå i projektet dengang, er de centrale spor.

Praktisk rækkefølge

Når en licenstvist opstår, er rækkefølgen vigtig, fordi hvert skridt bygger på det foregående:

Fastlæg den omtvistede version. Hvilken udgivelse, til hvilken modtager, og hvornår. Sikr den leverede fil med hashværdi.
Find byggestedet. Knyt versionen til et bestemt punkt i versionsstyringen, fx et mærke eller en commit.
Lav eller sikr SBOM’en. Brug et værktøj med kendt version og gem både SBOM’en og værktøjets output.
Kontrollér licenserne manuelt. For de komponenter, tvisten drejer sig om, sammenholdes værktøjets angivelse med licensfilen i komponentens eget projekt på det relevante tidspunkt.
Afklar distributionen. Beskriv, hvordan programmet nåede brugerne.

Først derefter giver det mening at vurdere, om licensens krav er opfyldt. Springes de første trin over, risikerer parterne at diskutere licenser for komponenter, der slet ikke var med i den leverede version.