Ingen læser licensen på en pakke, de installerer på fire minutter. Den bliver interessant på præcis ét tidspunkt — når en investor, en køber eller en stor kunde beder om en liste, og der står noget på den, som forpligter dig til at udlevere kode, du betragter som din.
Det er en forretningsrisiko, der opfører sig anderledes end en sikkerhedsrisiko. En sårbarhed haster og bliver så rettet. En licensforpligtelse ligger i dvale i årevis og afgør så en handel. Den kan heller ikke lappes: når den dukker op, er koden i dit produkt og er allerede sendt ud.
Det følgende er et ingeniørkort, ikke juridisk rådgivning. Grænsen mellem "den her licens gælder os" og "det gør den ikke" afhænger af, hvordan du distribuerer din software, og det spørgsmål hører til hos en advokat. Det, du kan gøre uden en, er at vide, hvad du har.
De tre familier
Tilladelige — MIT, BSD, Apache 2.0, ISC
Gør hvad du vil, også bruge det i lukket kommerciel software. Forpligtelserne er små: behold ophavsretsnoten og licensteksten sammen med distributionen. Apache 2.0 tilføjer en udtrykkelig patentlicens, og det er derfor, juridiske afdelinger som regel foretrækker den frem for MIT. Den beder desuden om, at du markerer de filer, du har ændret, og at du sender projektets NOTICE-fil videre, hvis der er en.
Det er det store flertal af det, du afhænger af, og derfor føles emnet teoretisk det meste af tiden.
Svag copyleft — LGPL, MPL 2.0, EPL
Forpligtelsen hænger på komponenten, ikke på dit produkt. Ændrer du biblioteket, offentliggør du de ændringer; din egen kode rundt om forbliver din. MPL trækker grænsen ved filen: enhver fil, der indeholder MPL-kode, forbliver under MPL — også en af dine, hvis du har indsat koden dér. Filer, du selv har skrevet fra bunden, er urørte.
Den praktiske fælde er LGPL og statisk linkning. Dynamisk linkning er det tilfælde, licensen er skrevet til, og er som regel uproblematisk: brugeren kan selv skifte biblioteket ud. Statisk linkning er også tilladt, men på en betingelse, de færreste opdager — du skal give modtageren nok, enten objektfiler eller din kildekode, til at kunne linke din binære fil sammen med en ændret udgave af biblioteket. På et produkt, du udsender som én lukket binær fil, er det en reel forpligtelse, og derfor betyder det langt mere for desktop, mobil og Go end for en server, du aldrig udleverer til nogen.
Stærk copyleft — GPL, AGPL
Det er den familie, der kan række ind i din egen kode. Er dit produkt et afledt værk af GPL-kode, og distribuerer du det, skal du tilbyde den fuldstændige tilhørende kildekode til det hele på samme vilkår. For et lukket produkt er det som regel ikke en mulighed, og så bliver det en udskiftningsopgave i stedet for en overholdelsesopgave.
AGPL fortjener sit eget afsnit, for det er den, der fanger moderne virksomheder. GPL-forpligtelser udløses ved distribution, og at køre software på sin egen server, som brugere tilgår over et netværk, blev længe ikke regnet for distribution — det såkaldte ASP-smuthul. AGPL lukker det: interagerer brugere med din ændrede udgave over et netværk, skal du tilbyde dem kildekoden. For en SaaS-forretning er det præcis scenariet, så en AGPL-afhængighed dybt i en webapplikation er noget kvalitativt andet end en GPL-licenseret.
Bemærk, at det er derfor, projekter som Grafana og Nextcloud har valgt AGPL. Det er ikke et uheld eller en forglemmelse fra deres side; det er hele pointen.
To forbehold er værd at tage med videre. Netværksklausulen udløses af en ændret udgave, så det at køre en uændret AGPL-tjeneste er et smallere tilfælde, end det som regel bliver beskrevet som. Og om det at kalde et AGPL-bibliotek fra din egen applikation gør din applikation til en ændret udgave, er præcis det spørgsmål om afledte værker, en advokat skal svare på med din arkitektur i hånden — det bliver ikke afgjort af at læse licensen. De fleste virksomheder fører ikke den sag. De skriver "ingen AGPL i produktet" ind i politikken og går videre, og det er en forsvarlig måde at bruge risikobudgettet på snarere end en udtalelse om, hvad licensen betyder.
Hvorfor det dukker op ved due diligence og ikke før
Ingen gennemgår licenser en almindelig tirsdag. Udløseren er altid en transaktion.
En købers tekniske due diligence kører en scanning over dine repositories, for de køber koden og arver de forpligtelser, der følger med. En stor kundes indkøbsafdeling beder om en stykliste med licenser, fordi deres egen overholdelse afhænger af din. En investor spørger, fordi advokaterne har sagt det.
På det tidspunkt er fundet ikke "Du har et problem, der skal rettes". Det er "Du har et problem, det ligger nu i et datarum, og uret går". Udbedring på det stadie betyder at finde et andet bibliotek, skrive integrationen om og teste igen — under et tidspres, du ikke selv har valgt. Et halvt år tidligere ville det have været en beslutning på et kvarter om at vælge en anden pakke.
De dele, der er reelt svære
Transitive licenser. Du valgte fyrre pakker og tjekkede deres licenser, hvis du var omhyggelig. De seks hundrede, de trak med sig, har også licenser, og dem har ingen kigget på. I praksis er det dér, overraskelserne bor.
Uklare angivelser. En ikke ubetydelig del af pakkerne angiver deres licens dårligt eller slet ikke: et tomt metadatafelt, fritekst, ingen parser genkender, eller en LICENSE-fil, der er uenig med manifestet. Et værktøj har to muligheder, og kun den ene er ærlig — registrér den som ubestemt, eller gæt. Et gæt breder sig: det bliver læst ind, rapporteret og til sidst lagt til grund for en beslutning om, hvorvidt du må sende produktet ud. Det er dét, NOASSERTION findes til i SPDX, og et værktøj, der aldrig udsteder den, er ikke dygtigere — kun mindre omhyggeligt.
Dobbeltlicensering og undtagelser. Nogle projekter tilbyder et valg mellem licenser, eller en copyleft-licens med en linkning-undtagelse hæftet på. Undtagelsen er ofte hele grunden til, at pakken overhovedet kan bruges kommercielt, og en scanner, der kun melder grundlicensen, alarmerer dig om noget, der er helt i orden.
Licensskift. En pakke kan skifte licens mellem versioner. En opdatering, du godkendte på grund af en sikkerhedsrettelse, kan i stilhed ændre dine forpligtelser. Det er ikke et tænkt eksempel — Elastic, MongoDB, HashiCorp og Redis er alle gået over til source-available-vilkår i de senere år — og den vigtige detalje er, at de licenser slet ikke er open source, så en politik formuleret som "tilladelig eller copyleft" har intet svar på dem.
Hvad man rent faktisk gør
Beslut din politik én gang, på forhånd. De fleste virksomheder lander på: tilladelige licenser er fine, svag copyleft kræver et kig på, hvordan der linkes, stærk copyleft kræver godkendelse, AGPL er et nej til alt i produktet. At skrive det ned laver en skønsafgørelse om til et opslag.
Tjek, når afhængigheden bliver tilføjet — ikke når handlen bliver underskrevet. Det er hele forskellen i pris. En licens markeret i en pull request er en anden pakke. Den samme licens markeret i et datarum er en omskrivning.
Hold fortegnelsen genereret, ikke vedligeholdt. Et regneark med licenser er forkert inden for en måned. Det skal komme fra den samme opløsning, der producerer dit faktiske afhængighedstræ.
Behandl "ukendt" som et fund. En ubestemt licens er ikke en frikendelse. Det er netop det punkt, der er mest sandsynligt et reelt problem — fordi ingen har set på det.
Hvilke open source-licenser er risikable for et kommercielt produkt?
Familien med stærk copyleft — GPL og AGPL — er den, der kan række ind i din egen kode, fordi et afledt værk, du distribuerer, skal tilbydes på samme vilkår med den fuldstændige tilhørende kildekode. Svag copyleft som LGPL og MPL hæfter forpligtelser på komponenten og ikke på dit produkt og er som regel til at håndtere, selvom statisk linkning af LGPL-kode ind i en binær, du udsender, kræver omtanke. Tilladelige licenser som MIT, BSD, ISC og Apache 2.0 kræver stort set kun, at noten følger med.
Hvad er forskellen på GPL og AGPL?
GPL-forpligtelser udløses af distribution, og at køre ændret software på sin egen server, som brugere tilgår over et netværk, er længe ikke blevet regnet for at distribuere den. AGPL lukker præcis det hul: interagerer brugere med din ændrede udgave over et netværk, skal du tilbyde dem kildekoden. For en SaaS-forretning er det den normale driftsmodel, så en AGPL-afhængighed i en webapplikation er væsentligt mere alvorlig end en GPL-licenseret.
Hvorfor dukker licensproblemer op under due diligence?
Licensproblemer dukker op under due diligence, fordi en transaktion er den eneste rutinemæssige begivenhed, der får nogen til at gennemgå licenser. En køber scanner dine repositories, eftersom de arver forpligtelserne, og en stor kundes indkøb beder om en stykliste med licenser, fordi deres overholdelse afhænger af din. På det tidspunkt er fundet ikke en opgave, men et problem i et datarum med et ur på — den samme sag fanget, da afhængigheden blev tilføjet, ville have været en beslutning på et kvarter om at vælge en anden pakke.
Hvad bør et værktøj gøre, når en pakkes licens ikke kan fastslås?
Et værktøj bør registrere en licens, der ikke kan fastslås, som ubestemt i stedet for at gætte på den. En ikke ubetydelig del af pakkerne angiver deres licens dårligt eller slet ikke, og en gættet licens forbliver ikke et gæt: den bliver læst ind, rapporteret og til sidst lagt til grund for en beslutning om, hvorvidt du må sende produktet ud. SPDX har NOASSERTION til præcis det, og et værktøj, der aldrig udsteder den, er ikke dygtigere end et, der gør — kun mindre omhyggeligt. En ukendt licens er samtidig det punkt, der er mest sandsynligt et reelt problem, fordi ingen har set på det.
Hvor CodeControl passer ind
CodeControl opløser licensen for hver eneste pakke i dit træ, også de transitive, ingen har valgt, og rejser et fund, hvor en licens juridisk kan række ind i dit eget produkt. En licens, vi ikke genkender, meldes som ubestemt i stedet for gættet og eksporteres som NOASSERTION i SPDX-styklisten — netop det dokument, due diligence-anmodningen beder om ved navn. Og fordi det kører ved hvert push, sker tjekket, når pakken bliver tilføjet, og ikke når handlen bliver underskrevet.