Många företag använder öppen källkod varje dag, ofta utan att tänka på det. Den finns i ramverk, databaser och i de system ni köper. Att koden är öppen betyder dock inte att den saknar regler. Varje komponent kommer med en licens, och licensen avgör vad ni får göra och vad ni måste göra. Här går vi igenom de vanligaste licenstyperna och hur ett mindre företag kan hålla ordning på dem.
Fri att använda – men inte utan villkor
Öppen källkod är fortfarande upphovsrättsskyddad. Den som skrivit koden har gett andra rätt att använda, ändra och sprida den, men bara enligt de villkor som står i licensen.
Det finns hundratals licenser, men de flesta projekt använder ett fåtal välkända. Open Source Initiative (OSI) granskar och godkänner licenser som uppfyller den så kallade Open Source Definition. Grovt kan licenserna delas in i två grupper: tillåtande licenser och copyleft-licenser.
Tillåtande licenser
Tillåtande licenser, på engelska permissive, ställer få krav. De vanligaste är MIT och BSD. I huvudsak kräver de att upphovsrättsnotisen och licenstexten följer med när ni sprider koden. Ni får använda koden i egna, stängda produkter och behöver inte publicera er egen källkod.
Apache 2.0 är också en tillåtande licens men något mer utförlig. Den innehåller en uttrycklig patentlicens från bidragsgivarna, vilket ger ett visst skydd mot patentanspråk från dem som bidragit till koden. Den kräver också att filer som ni har ändrat märks som ändrade.
Copyleft: GPL och LGPL
Copyleft-licenser bygger på en annan idé: friheten ska följa med koden. Den mest kända är GNU General Public License, GPL, som finns i version 2 och 3. Om ni distribuerar ett GPL-licensierat program, eller ett verk som bygger på det, måste ni göra källkoden tillgänglig under samma licens.
Det avgörande ordet är distribuerar. Om ni bara använder ett GPL-program internt, utan att lämna det vidare till någon utanför företaget, utlöses inte kravet på att dela källkoden.
LGPL, Lesser General Public License, är en svagare form av copyleft och används ofta för bibliotek. Ett program som bara länkar mot ett LGPL-bibliotek behöver normalt inte självt licensieras under LGPL. Däremot omfattas ändringar i själva biblioteket av licensens krav.
AGPL och webbtjänster
En webbtjänst distribueras i regel inte till användarna. Därför finns GNU Affero General Public License, AGPL v3. Den fungerar som GPL men lägger till ett villkor: om ni har modifierat programmet och låter användare interagera med det över ett nätverk, till exempel som en webbtjänst, ska ni erbjuda dem källkoden till er version.
För företag som bygger eller säljer SaaS-tjänster är detta viktigt att känna till. En AGPL-komponent i en tjänst som kunder använder kan innebära skyldigheter även om ingen programfil någonsin lämnar era servrar.
| Licens | Typ | Det viktigaste kravet |
|---|---|---|
| MIT | Tillåtande | Upphovsrätts- och licenstexten ska följa med |
| Apache 2.0 | Tillåtande | Licenstext ska följa med och ändrade filer märkas; innehåller patentlicens |
| GPLv3 | Copyleft | Vid distribution ska källkoden lämnas under samma licens |
| LGPL | Svagare copyleft | Ändringar i biblioteket omfattas, program som länkar normalt inte |
| AGPLv3 | Copyleft | Även nätverksanvändare av en ändrad version ska erbjudas källkoden |
När licensen ändras
Licenser kan bytas. Under de senaste åren har några kända projekt gått från en öppen licens till så kallade source available-licenser, till exempel Business Source License eller Server Side Public License. Koden går då fortfarande att läsa, men OSI räknar inte dessa licenser som öppen källkod. De kan begränsa kommersiell användning, särskilt möjligheten att erbjuda programmet som en tjänst.
En sådan ändring gäller normalt nya versioner. Äldre versioner som släppts under den tidigare licensen brukar fortsätta att omfattas av den. Därför är det viktigt att kontrollera licensen för exakt den version ni använder, och att se över licensen igen när ni uppgraderar.
Så håller ni ordning
Licenserna är inte svåra att följa, men ni behöver veta vad ni använder:
- För en förteckning. Håll en lista över komponenter, versioner och licenser, gärna i form av en SBOM (software bill of materials).
- Kontrollera beroenden. Ett bibliotek drar ofta med sig andra bibliotek. Även indirekta beroenden har licenser som kan ställa krav.
- Läs licensen för rätt version. Utgå från licensfilen i den version ni använder.
- Fråga leverantörerna. Be leverantörer av system ni köper redovisa vilken öppen källkod som ingår och under vilka licenser. Det hör till vad du ska kontrollera i ett SaaS-avtal.
- Bestäm vem som ansvarar. Utse någon som godkänner nya komponenter och vet när en fråga behöver gå vidare till juridisk expertis.
Öppen källkod kan vara ett bra och kostnadseffektivt val, men licensen är bara en del av kalkylen. Drift, uppdateringar och support kostar också, och det kan vara värt att jämföra den totala kostnaden med en prenumeration, till exempel med hjälp av SaaS-kalkylen. Med en aktuell förteckning och en vana att läsa licensen innan en ny komponent tas in blir licensfrågorna för de flesta företag en hanterbar del av vardagen.
Källor: Open Source Initiative – Licenses, GNU Affero General Public License v3, GNU GPL FAQ. Texten är allmän information och inte juridisk rådgivning.