Vilken open source ligger i din produkt – och spelar det roll?

Nästan ingen beställd kod skrivs från grunden. Den byggs ovanpå tusentals färdiga open source-komponenter, och det är både klokt och nödvändigt – att uppfinna allt själv vore slöseri. Men varje komponent kommer med en licens, och de villkoren följer med in i din produkt. För det mesta är det oproblematiskt. Ibland kan en enda felaktigt vald komponent skapa en fråga som dyker upp först när en investerare granskar koden. Den här guiden reder ut vad som gäller och hur du håller koll.

Permissivt kontra copyleft – i klartext

Open source-licenser är många, men i praktiken faller de i två läger som är värda att förstå. Skillnaden handlar om vad licensen kräver tillbaka av dig.

Permissiva licenser – de vanligaste är MIT, Apache och BSD – låter dig i princip göra vad du vill med koden, inklusive att bygga in den i en stängd, kommersiell produkt som du säljer. Kravet är i stort sett bara att du behåller upphovsrättsnoteringen. De skapar sällan några bekymmer och utgör ryggraden i de flesta produkter.

Copyleft-licenser ställer ett motkrav: om du använder koden ska förändringar, och i starka varianter hela verk som bygger på den, göras tillgängliga under samma öppna villkor. Den mest kända är GPL. Tanken är att det som byggts öppet ska förbli öppet. Det är en fullt legitim modell – men den passar dåligt om din affärsidé bygger på att hålla din egen kod stängd. En vanlig missuppfattning är att “open source betyder gratis och fritt”. Gratis att använda, ofta, men inte alltid fritt från villkor.

Kräv en licensinventering av leverantören

Problemet med licenser är att de är osynliga i det färdiga systemet. Koden fungerar likadant oavsett vad komponenterna har för villkor, så en olämplig licens märks inte i drift – bara i en granskning. Lösningen är att göra det osynliga synligt.

Kräv därför en licensinventering av leverantören: en förteckning över alla open source-komponenter som ingår och vilka licenser de har. Ett modernt projekt kan innehålla hundratals beroenden, ofta beroenden till andra beroenden, så listan tas fram med verktyg snarare än för hand. Det viktiga är att den finns, att den hålls uppdaterad när nya komponenter tillkommer, och att någon faktiskt tittar på den. Då syns direkt om det ligger en stark copyleft-licens där den inte borde, medan det fortfarande är enkelt att byta ut komponenten. En seriös leverantör har ordning på detta och tycker inte att frågan är konstig – tvärtom är oviljan att ta fram en inventering i sig en varningssignal.

Licensfrågan i avtal och vid granskning

Licenshantering ska inte hänga på god vilja, utan stå i avtalet. Ett par formuleringar gör stor skillnad. Låt avtalet ange att leverantören ansvarar för att levererad kod inte innehåller komponenter vars licens strider mot hur ni tänkt använda produkten, och att en aktuell licensinventering ska ingå i leveransen. Då blir det leverantörens sak att hålla rent, inte er överraskning i efterhand.

Frågan får extra tyngd vid en investering eller ett förvärv. Där granskas kodens licenser rutinmässigt som en del av due diligence, och en stark copyleft-komponent i kärnan av produkten kan bli en verklig affärsrisk – något som sänker värderingen eller pausar affären tills det är utrett. En städad och dokumenterad licenssituation är därför inte bara teknisk hygien, utan en tillgång som gör bolaget lättare att investera i. Att lägga en liten insats på ordning tidigt är billigt; att reda ut en licensröra mitt under en pågående affär är dyrt och stressigt.

Ett konkret scenario

Ett bolag hade under ett par år låtit bygga sin produkt utan att någon hållit koll på licenserna. Inför en investeringsrunda gjorde investerarens rådgivare en licensgenomgång och hittade en komponent under stark copyleft djupt inne i en central funktion. Frågan blev genast om produktens kärna riskerade att behöva öppnas.

Utredningen tog tid och skapade osäkerhet i en känslig fas. Till slut visade det sig att komponenten kunde bytas mot ett permissivt alternativ utan större arbete, och affären kunde gå vidare. Men lärdomen var tydlig: hade en licensinventering funnits och hållits uppdaterad från början, hade komponenten aldrig byggts in – eller åtminstone bytts ut långt innan den blev en fråga vid förhandlingsbordet.

Håll ordning från början

Open source är en tillgång, inte en risk – så länge du vet vad du använder. De allra flesta komponenter är oproblematiska, och poängen är inte att bli rädd för öppen kod, utan att ha koll på den. En licensinventering, ett par rader i avtalet och någon som faktiskt läser listan räcker långt för att undvika de överraskningar som annars dyker upp i värsta tänkbara stund.

Vi på Weapp håller ordning på licenserna i det vi bygger och hjälper gärna beställare att granska vad som ligger i en befintlig produkt, som en del av våra tjänster. Är ni osäkra på vad er kod vilar på? Hör av dig så tittar vi tillsammans på licenssituationen innan den blir någon annans fråga.