Får jeres virksomhed et krav om, at jeres produkt bryder en open source-licens, er det første skridt at dokumentere, hvad der faktisk er sket, før nogen retter eller fjerner noget. Hvilken komponent drejer det sig om, hvilken licens gælder, i hvilke versioner af produktet indgik den, og hvordan blev produktet leveret til kunderne? Svarene ligger i jeres kodehistorik og jeres udgivelser, og de skal sikres, før de bliver ændret.
Artiklen er til ledelsen, udviklingschefen og produktansvarlige i en softwarevirksomhed, der står med et krav. Kravet kan komme fra en rettighedshaver eller fra en køber, der efter et salg mener, at licensforholdene ikke var, som de blev beskrevet. Den juridiske side er beskrevet for advokater. → Open source-licensbrud: SBOM som bevis
Hvordan kravet typisk kommer
- En rettighedshaver skriver og påstår, at jeres produkt bruger deres kode uden at overholde licensens vilkår, fx krav om at udlevere kildekode, bevare ophavsretsmeddelelser eller oplyse om licensen.
- En kunde eller partner spørger til licensforholdene, fordi de selv er blevet opmærksomme på komponenten.
- En køber af virksomheden rejser et krav efter handlen og henviser til garantier om rettigheder og licenser.
- En investor eller långiver stiller spørgsmål, der viser, at nogen har set nærmere på jeres kode.
Open source-licenser er meget forskellige. Nogle stiller næsten ingen krav ud over at bevare en meddelelse om ophavsret. Andre kræver, at afledte værker stilles til rådighed under samme licens, hvis de distribueres. Om et krav er berettiget, afhænger af licensen, af hvordan komponenten er brugt, og af hvordan produktet er leveret.
Det første, I gør
- Lad være med at svare indholdsmæssigt før advokaten har set kravet.
- Bevar kodehistorikken. Sørg for, at ingen sletter grene, omskriver historikken eller rydder op i gamle udgivelser.
- Identificér komponenten og den licens, den var udgivet under på det tidspunkt, I hentede den. Gem licensteksten.
- Find ud af, hvornår komponenten kom ind i jeres kode, af hvem, og i hvilke udgivelser den indgik.
- Kortlæg leveringen. Blev produktet installeret hos kunder, distribueret som app, indlejret i hardware eller kun leveret som en tjeneste?
- Tag en fast kopi af versionsstyringen, byggeopsætningen og de udgivne versioner med dato og kontrolværdier.
Kodehistorikken er det centrale bevis
Versionsstyringen viser, hvornår en fil eller et bibliotek blev tilføjet, ændret eller fjernet, og af hvem. Sammen med jeres udgivelser kan den vise, i hvilke versioner komponenten var med, og dermed hvilke kunder der fik den. Den historik skal være intakt.
- Versionsstyring · Hvornår komponenten kom ind, ændringer og fjernelse
- Afhængighedsfiler og låsefiler · Præcis hvilken version af komponenten der blev brugt
- Byggelogs og udgivelser · Hvad der faktisk blev leveret i hver version
- Komponentoversigt (SBOM) · Hvilke komponenter og licenser produktet indeholdt
- Licensmeddelelser i produktet · Hvad kunderne fik oplyst
- Kundeaftaler og leveringsdata · Hvem der fik hvilke versioner
Har I tidligere lavet en komponentoversigt eller kørt en licensscanning, så gem resultaterne i den version, der forelå på tidspunktet. De kan vise, hvad I vidste, og hvornår. Har I ikke en oversigt, så lav den nu ud fra kodehistorikken, og markér tydeligt, at den er lavet efter kravet. → Kildekode og Git som bevis
Når kravet kommer fra køberen efter et salg
Har I solgt virksomheden eller produktet, og mener køberen, at licensforholdene ikke var, som de blev oplyst, handler tvisten om, hvad køberen fik at vide før handlen. Find jeres kopi af datarummet, spørgsmål og svar, og de oplysninger om licenser og komponenter, der blev givet. Gem også den version af koden, der var aktuel ved overdragelsen. Er I køberen, gælder det samme fra den anden side. → Efter købet: softwaren var ikke, som den blev præsenteret
Hvordan datarummet bør bygges, så det kan dokumentere, hvad der blev oplyst, er beskrevet for sig. → Salg af virksomheden: byg datarummet, så det holder bagefter
Jeres kunder kan også blive berørt
Hvis jeres produkt er installeret hos kunder eller videresolgt af partnere, kan kravet også få betydning for dem. Nogle kundeaftaler indeholder garantier om, at produktet ikke krænker andres rettigheder, og en kunde kan selv få en henvendelse fra rettighedshaveren. Lav en oversigt over, hvilke kunder der har fået de berørte versioner, og hvilke aftaler der gælder for dem. Kontakt ikke kunderne om sagen, før advokaten har vurderet, hvad der skal siges, og hvornår. En forhastet besked kan blive læst som en indrømmelse, og en for sen besked kan skade kundeforholdet. Gem al korrespondance med kunder og partnere om emnet.
Rettelsen skal også dokumenteres
Ofte vil I hurtigt rette forholdet: fjerne komponenten, udskifte den, tilføje licensmeddelelser eller stille kildekode til rådighed. Det kan være fornuftigt, men gør det på en måde, der kan dokumenteres:
- aftal med advokaten, hvad der rettes, og hvornår,
- lav rettelsen som en ny ændring i versionsstyringen, ikke ved at omskrive historikken,
- notér dato, version og hvem der godkendte rettelsen,
- gem en kopi af produktet før og efter rettelsen.
En rettelse, der kan dateres, viser, hvornår forholdet ophørte. En rettelse, der skjuler det tidligere forhold, kan svække jeres troværdighed i hele sagen.
Hvem gør hvad
- Ledelse · Beslutter, hvordan kravet håndteres
- Udviklingschef · Bevarer historik, identificerer komponent og versioner
- Produktansvarlig · Kortlægger levering og kunder
- Juridisk eller advokat · Vurderer licensen og kravet, svarer modparten
- IT-sagkyndig · Vurderer de tekniske forhold uvildigt
Det må I ikke gøre
- Omskrive kodehistorikken for at fjerne komponenten fra fortiden.
- Slette gamle udgivelser fra jeres download- eller udgivelsessystem.
- Erkende eller afvise kravet i en hurtig mail fra en udvikler.
- Lade udviklere diskutere sagen i åbne kanaler eller offentlige fora.
- Antage, at “open source” betyder gratis og frit. Licensen gælder, også når koden er gratis.
Forebyg det næste krav
Når sagen er håndteret, så overvej faste rutiner: en komponentoversigt, der opdateres ved hver udgivelse, en politik for, hvilke licenser der må bruges, og en godkendelse, før nye komponenter tages ind. Gem oversigterne sammen med udgivelserne. → Dokumentér jeres egen udvikling løbende
Hvornår skal I have hjælp udefra?
Når kravet har økonomisk betydning, eller når det er uklart, hvordan komponenten er brugt. En advokat skal vurdere licensen og kravet. En uvildig IT-sagkyndig kan vurdere de tekniske forhold: hvordan komponenten indgår i produktet, i hvilke versioner, og hvad kodehistorikken viser. Nielco IT er uvildig, sælger ikke produkter og tager ikke opgaver for modparten i samme tvist.
Læs også: Efter købet: softwaren var ikke, som den blev præsenteret · Agilt projekt i tvist: det tæller som dokumentation
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
