Hvilken åpen kildekode ligger i produktet ditt, og spiller det noen rolle?

Nesten ingen bestilt kode skrives fra bunnen av. Den bygges oppå tusenvis av ferdige komponenter med åpen kildekode, og det er både klokt og nødvendig. Å finne opp alt selv ville vært sløsing. Men hver komponent kommer med en lisens, og de vilkårene følger med inn i produktet ditt. Som regel er det uproblematisk. Noen ganger kan én eneste feilvalgt komponent skape et spørsmål som først dukker opp når en investor går gjennom koden. Denne guiden forklarer hva som gjelder, og hvordan du holder oversikten.

Permissive lisenser mot copyleft i klartekst

Det finnes mange lisenser for åpen kildekode, men i praksis faller de i to leirer som er verdt å forstå. Forskjellen handler om hva lisensen krever tilbake av deg.

Permissive lisenser, der de vanligste er MIT, Apache og BSD, lar deg i prinsippet gjøre hva du vil med koden, inkludert å bygge den inn i et lukket, kommersielt produkt som du selger. Kravet er stort sett bare at du beholder opphavsrettsmerknaden. De skaper sjelden problemer og utgjør ryggraden i de fleste produkter.

Copyleft-lisenser stiller et motkrav: Bruker du koden, skal endringer, og i de sterke variantene hele verk som bygger på den, gjøres tilgjengelige på de samme åpne vilkårene. Den mest kjente er GPL. Tanken er at det som er bygd åpent, skal forbli åpent. Det er en helt legitim modell, men den passer dårlig hvis forretningsideen din bygger på å holde din egen kode lukket. En vanlig misforståelse er at «åpen kildekode betyr gratis og fritt». Gratis å bruke, ofte, men ikke alltid fri for vilkår.

Krev en lisensoversikt fra leverandøren

Problemet med lisenser er at de er usynlige i det ferdige systemet. Koden fungerer likt uansett hvilke vilkår komponentene har, så en uegnet lisens merkes ikke i drift, bare ved en gjennomgang. Løsningen er å gjøre det usynlige synlig.

Krev derfor en lisensoversikt fra leverandøren: en fortegnelse over alle komponentene med åpen kildekode som inngår, med lisensen til hver av dem. Et moderne prosjekt kan inneholde hundrevis av avhengigheter, ofte avhengigheter som selv har avhengigheter, så listen lages med verktøy snarere enn for hånd. Det viktige er at den finnes, at den holdes oppdatert når nye komponenter kommer til, og at noen faktisk ser på den. Da ser man med en gang, mens det fortsatt er enkelt å bytte ut komponenten, om det ligger en sterk copyleft-lisens der den ikke burde ligge. En seriøs leverandør har orden på dette og synes ikke spørsmålet er rart. Tvert imot er uviljen mot å lage en slik oversikt i seg selv et varselsignal.

Lisensspørsmålet i avtalen og ved gjennomgang

Lisenshåndtering skal ikke avhenge av god vilje, men stå i avtalen. Et par formuleringer gjør stor forskjell. La avtalen si at leverandøren er ansvarlig for at levert kode ikke inneholder komponenter med lisenser som strider mot hvordan dere har tenkt å bruke produktet, og at en oppdatert lisensoversikt skal inngå i leveransen. Da blir det leverandørens sak å holde det ryddig, ikke en overraskelse for dere i ettertid.

Spørsmålet får ekstra tyngde ved en investering eller et oppkjøp. Da blir kodens lisenser rutinemessig gjennomgått som en del av due diligence, og en sterk copyleft-komponent i kjernen av produktet kan bli en reell forretningsrisiko, noe som senker verdsettelsen eller setter transaksjonen på pause til det er utredet. En ryddig og dokumentert lisenssituasjon er derfor ikke bare teknisk hygiene, men et fortrinn som gjør selskapet lettere å investere i. Litt innsats for å holde orden tidlig er billig. Å rydde opp i et lisenskaos midt i en pågående transaksjon er dyrt og stressende.

Et konkret scenario

Et selskap hadde i et par år fått bygd produktet sitt uten at noen holdt oversikt over lisensene. Før en investeringsrunde gjorde investorens rådgivere en lisensgjennomgang og fant en komponent under sterk copyleft dypt inne i en sentral funksjon. Spørsmålet ble straks om kjernen i produktet risikerte å måtte åpnes.

Utredningen tok tid og skapte usikkerhet i en sårbar fase. Til slutt viste det seg at komponenten kunne byttes mot et permissivt alternativ uten større arbeid, og transaksjonen kunne gå videre. Men lærdommen var tydelig: Hadde det funnes en lisensoversikt som ble holdt oppdatert fra starten, ville komponenten aldri ha blitt bygd inn, eller den ville i det minste ha blitt byttet ut lenge før den ble et tema ved forhandlingsbordet.

Hold orden fra starten

Åpen kildekode er en ressurs, ikke en risiko, så lenge du vet hva du bruker. De aller fleste komponenter er uproblematiske, og poenget er ikke å bli redd for åpen kildekode, men å ha oversikt over den. En lisensoversikt, et par linjer i avtalen og noen som faktisk leser listen, gjør mye for å unngå overraskelsene som ellers dukker opp i verst tenkelige øyeblikk.

Vi i Weapp holder orden på lisensene i det vi bygger og hjelper gjerne kunder med å gå gjennom hva som ligger i et eksisterende produkt, som en del av tjenestene våre. Er dere usikre på hva koden deres hviler på? Ta kontakt, så ser vi på lisenssituasjonen sammen før den blir noen andres sak.