Hvilken open source ligger der i dit produkt, og betyder det noget?
Næsten al bestilt kode indeholder open source-komponenter. Permissive licenser som MIT er uproblematiske at bruge kommercielt mens stærke copyleft-licenser som GPL i visse tilfælde kan tvinge dig til at åbne din egen kode. Kræv en licensoversigt fra leverandøren, og regulér spørgsmålet i kontrakten så der ikke dukker overraskelser op når en investor gennemgår koden.
Næsten ingen bestilt kode skrives fra bunden. Den bygges oven på tusindvis af færdige open source-komponenter, og det er både klogt og nødvendigt. At opfinde det hele selv ville være spild. Men hver komponent kommer med en licens, og de vilkår følger med ind i dit produkt. For det meste er det uproblematisk. Nogle gange kan en enkelt forkert valgt komponent skabe et spørgsmål der først dukker op når en investor gennemgår koden. Denne guide gør rede for hvad der gælder, og hvordan du holder styr på det.
Permissive licenser og copyleft i klart sprog
Der findes mange open source-licenser, men i praksis falder de i to lejre som er værd at forstå. Forskellen handler om hvad licensen kræver tilbage af dig.
Permissive licenser (de mest udbredte er MIT, Apache og BSD) lader dig i princippet gøre hvad du vil med koden, herunder at bygge den ind i et lukket, kommercielt produkt som du sælger. Kravet er stort set kun at du bevarer ophavsretsangivelsen. De skaber sjældent problemer og udgør rygraden i de fleste produkter.
Copyleft-licenser stiller et modkrav: Hvis du bruger koden, skal ændringer, og i de stærke varianter hele værker der bygger på den, gøres tilgængelige under de samme åbne vilkår. Den mest kendte er GPL. Tanken er at det der er bygget åbent, skal forblive åbent. Det er en helt legitim model, men den passer dårligt hvis din forretningsidé bygger på at holde din egen kode lukket. En udbredt misforståelse er at “open source betyder gratis og frit”. Gratis at bruge, ofte, men ikke altid fri for vilkår.
| Licenstype | Hvad det betyder for dit produkt |
|---|---|
| Permissiv (MIT, Apache, BSD) | Frit at bruge i et lukket kommercielt produkt, bevar ophavsretsangivelsen |
| Svag copyleft (LGPL, MPL) | Ændringer i selve komponenten skal deles, din øvrige kode berøres som regel ikke |
| Stærk copyleft (GPL, AGPL) | Kan kræve at værker der bygger på og spredes med koden, også åbnes |
Kræv en licensoversigt fra leverandøren
Problemet med licenser er at de er usynlige i det færdige system. Koden fungerer på samme måde uanset hvilke vilkår komponenterne har, så en uegnet licens mærkes ikke i driften, kun ved en gennemgang. Løsningen er at gøre det usynlige synligt.
Kræv derfor en licensoversigt fra leverandøren: en fortegnelse over alle de open source-komponenter der indgår, og hvilke licenser de har. Et moderne projekt kan indeholde hundredvis af afhængigheder, ofte afhængigheder af andre afhængigheder, så listen laves med værktøjer snarere end i hånden. Det vigtige er at den findes, at den holdes opdateret når der kommer nye komponenter til, og at nogen faktisk kigger på den. Så ses det med det samme hvis der ligger en stærk copyleft-licens et sted hvor den ikke burde, på et tidspunkt hvor det stadig er let at skifte komponenten ud. En seriøs leverandør har styr på det og synes ikke at spørgsmålet er mærkeligt. Tværtimod er modvilje mod at lave en oversigt i sig selv et advarselssignal.
Licensspørgsmålet i kontrakten og ved due diligence
Håndteringen af licenser skal ikke hænge på god vilje, men stå i kontrakten. Et par formuleringer gør en stor forskel. Lad kontrakten fastslå at leverandøren har ansvaret for at den leverede kode ikke indeholder komponenter hvis licens strider mod den måde I har tænkt jer at bruge produktet på, og at en opdateret licensoversigt skal indgå i leverancen. Så bliver det leverandørens opgave at holde det rent, ikke jeres overraskelse bagefter.
Spørgsmålet får ekstra vægt ved en investering eller et opkøb. Her bliver kodens licenser rutinemæssigt gennemgået som en del af due diligence, og en stærk copyleft-komponent i kernen af produktet kan blive en reel forretningsrisiko, noget der sænker værdiansættelsen eller sætter handlen på pause indtil det er afklaret. En ryddelig og dokumenteret licenssituation er derfor ikke kun teknisk hygiejne, men et aktiv der gør virksomheden lettere at investere i. At bruge en lille indsats på at skabe orden tidligt er billigt; at rede et licensrod ud midt i en igangværende handel er dyrt og stressende.
Et konkret scenarie
En virksomhed havde i et par år fået bygget sit produkt uden at nogen holdt styr på licenserne. Forud for en investeringsrunde gennemgik investorens rådgivere licenserne og fandt en komponent under stærk copyleft dybt inde i en central funktion. Spørgsmålet blev straks om produktets kerne risikerede at skulle åbnes.
Afklaringen tog tid og skabte usikkerhed i en følsom fase. Til sidst viste det sig at komponenten kunne skiftes ud med et permissivt alternativ uden større arbejde, og handlen kunne gå videre. Men læren var klar: Havde der fra starten været en licensoversigt som blev holdt opdateret, var komponenten aldrig blevet bygget ind, eller i det mindste skiftet ud længe før den blev et spørgsmål ved forhandlingsbordet.
Hold orden fra begyndelsen
Open source er et aktiv, ikke en risiko, så længe du ved hvad du bruger. Langt de fleste komponenter er uproblematiske, og pointen er ikke at blive bange for åben kode, men at have styr på den. En licensoversigt, et par linjer i kontrakten og en person der faktisk læser listen, rækker langt for at undgå de overraskelser der ellers dukker op på det værst tænkelige tidspunkt.
Hos Weapp holder vi styr på licenserne i det vi bygger, og vi hjælper gerne kunder med at gennemgå hvad der ligger i et eksisterende produkt, som en del af vores services. Er I usikre på hvad jeres kode hviler på? Kontakt os, så kigger vi sammen på licenssituationen før den bliver nogen andens spørgsmål.
Ofte stillede spørgsmål
Hvad er open source-licenser, og hvorfor angår de mig som kunde?
Næsten al moderne software bygges på åbne komponenter, og hver af dem har en licens der styrer hvordan den må bruges. Som kunde arver du de vilkår i dit produkt. De fleste licenser er helt uproblematiske, men nogle stiller krav der kan påvirke om du må holde din egen kode lukket. Derfor er det værd at vide hvad der ligger i det du betaler for.
Hvad er forskellen på permissive licenser og copyleft?
Permissive licenser som MIT og Apache lader dig bruge koden næsten frit, også i et lukket kommercielt produkt, så længe du bevarer ophavsretsangivelsen. Copyleft-licenser som GPL kræver til gengæld at ændringer, og nogle gange hele værker der bygger på koden, gøres tilgængelige under de samme vilkår. Permissivt giver frihed; copyleft stiller krav om åbenhed tilbage.
Kan GPL tvinge mig til at åbne min egen kode?
I visse tilfælde, ja. Stærk copyleft som GPL er udformet sådan at software der bygger videre på og distribueres sammen med den, kan skulle frigives under de samme åbne vilkår. Præcis hvornår det slår igennem, afhænger af hvordan koden bruges og spredes, og det er et juridisk indviklet spørgsmål. Netop derfor vil du gerne vide om der er GPL-kode i produktet før den bygges ind, ikke bagefter.
Hvad er en licensoversigt, og hvorfor skal jeg kræve en?
En fortegnelse over alle open source-komponenter i systemet og deres licenser. Den viser sort på hvidt hvad produktet hviler på, og om en licens stiller krav der kræver eftertanke. At kræve en fra leverandøren, og at den holdes opdateret, er den enkleste måde at undgå ubehagelige overraskelser på, især fordi moderne projekter kan indeholde hundredvis af afhængigheder.
Hvordan påvirker open source-licenser en investors gennemgang?
Ved en investering eller et opkøb bliver kodens licenser ofte gennemgået som en del af due diligence. Findes der copyleft-komponenter som kan tvinge kerneproduktet til at blive åbnet, kan det sænke værdiansættelsen eller stoppe handlen indtil det er afklaret. En ryddelig licenssituation, dokumenteret i en opdateret oversigt, er derfor ikke kun et teknisk spørgsmål, men et forretningsmæssigt aktiv.