Et moderne SaaS-produkt består for en stor del af kode, som andre har skrevet. Open source, på dansk fri software, er ikke uden ejer: ophavsretten består, og licensen er den tilladelse, I bruger koden under. Licenser er forskellige, og nogle stiller pligter, som kan ramme jeres egen kode. For de fleste produkter er det et overskueligt ledelsesspørgsmål: hvilke licenser har vi, hvilke pligter følger med, og hvem holder øje? Her er det, en stifter skal vide, og hvordan I får styr på det uden at skulle læse hver licens.
Et forbehold først. Vi har ikke fundet en dansk primærkilde om licenser som GPL og MIT, og vi henviser ikke til nogen dansk dom. Licensens egen tekst er kilden, og beskrivelsen her er praktisk orientering. Den konkrete betydning for produktet må en advokat vurdere.
To familier af licenser
Tilladende licenser, fx MIT, BSD og Apache 2.0, giver bred adgang til at bruge koden, også i et lukket kommercielt produkt. Pligten er som regel at bevare ophavsmandens navn og licensteksten, når I videregiver koden.
Gensidige licenser, på engelsk copyleft, fx GPL, kræver, at I under visse betingelser giver andre de samme rettigheder til det, I bygger. Det kan betyde, at jeres egen kildekode skal stilles til rådighed. Det, der udløser pligten, afhænger af licensen og af, hvordan koden bruges. Nogle, fx LGPL, er snævrere og knytter sig til selve biblioteket og ændringer i det.
For en virksomhed, hvis værdi ligger i koden, er det den anden familie, der kræver opmærksomhed. De gensidige licenser er ikke farlige i sig selv, og mange solide værktøjer bruger dem. De skal bare vælges med åbne øjne.
Hvorfor SaaS er et særligt tilfælde
Mange gensidige licenser, fx GPL, knytter pligterne til videregivelse af programmet. Et SaaS-produkt kører på jeres egne servere, og brugerne får kun adgang via browseren. Derfor bliver koden ofte ikke videregivet i licensens forstand, og det er grunden til, at mange SaaS-virksomheder bruger GPL-kode på serversiden. Det er en udbredt læsning, og I bør få den bekræftet for jeres situation.
Det ændrer sig i tre tilfælde:
- AGPL. Denne licens er skrevet til netop denne situation. Den udvider pligten, så brugere, der tilgår et ændret program over internettet, kan have krav på kildekoden. Har I ændret i en AGPL-komponent, eller er den tæt bygget ind i produktet, skal det vurderes grundigt.
- Kode, der leveres til kunden. Javascript i browseren, mobilapps, en lokal klient eller en installation hos kunden er videregivelse. Her gælder pligterne.
- Licenser, der ændrer sig. Nogle projekter skifter licens ved en ny version og begrænser fx konkurrerende brug i skyen. Disse licenser er ikke fri software i klassisk forstand, og de skal læses særskilt.
Skifter I fra SaaS til at levere installationer til kunder, eller omvendt, skal licenserne ses igennem igen.
Indirekte afhængigheder
Det svære er sjældent de biblioteker, en udvikler selv har valgt. Hvert bibliotek trækker andre med sig, og disse indirekte afhængigheder kan være mange gange flere. En tilladende komponent kan hvile på noget med en gensidig licens, uden at nogen har opdaget det. Derfor nytter det ikke at spørge lead developeren, hvilke licenser I bruger. Svaret skal komme fra et værktøj.
Licensoversigt i byggepipelinen
Byggepipelinen er den automatiske proces, der bygger og tester koden, hver gang den ændres. Dér hører licenskontrollen hjemme:
- Lad et værktøj til analyse af softwaresammensætning lave en liste over alle komponenter og deres licenser. Mange af de samme værktøjer laver også en softwarekomponentliste, se tredjepartsbiblioteker, SBOM og byggepipeline. Dér handler det om sårbarheder, som er et andet spørgsmål end licenser.
- Del licenserne i tre grupper: godkendt, kræver vurdering, og ikke tilladt. Det er en beslutning, ledelsen skal stå bag, og en advokat kan hjælpe med grupperne.
- Lad pipelinen stoppe eller advare, når der dukker noget op fra de to sidste grupper.
- Skriv ned, hvem der må give en undtagelse, og hvorfor den blev givet.
Dertil kommer den lille pligt, som mange glemmer: at bevare licenstekster og ophavsmandsnavne, hvor koden leveres til kunden. En samlet side med licenser i appen er den almindelige løsning.
Licensoversigten bør også indgå, når I køber eller skifter en udviklingsleverandør: spørg, hvilke komponenter de bruger, og få det skrevet ind, se de tekniske krav i udviklingsaftalen. Det samme gælder AI-genereret kode, hvor ingen har taget stilling til, hvor forslaget kommer fra.
Hvis I finder noget
Finder I en komponent med en licens, der ikke passer, er der som regel flere veje:
- udskift komponenten med en anden,
- isolér den, så den kører som en adskilt tjeneste. Om det rækker, skal vurderes,
- køb en kommerciel licens, hvis projektet tilbyder det,
- få en advokat til at vurdere den konkrete brug.
Tag det roligt, og tag det i en planlagt rækkefølge. Ejerskab af jeres egen kode er behandlet i hvem ejer koden. Kunder kan også spørge til licenser i et spørgeskema, så svaret er godt at have parat.
Det skal I lade være med
- At tro, at open source betyder, at alt er tilladt · licensen er en tilladelse med betingelser.
- At nøjes med de biblioteker, I selv har valgt · de indirekte afhængigheder står for de fleste.
- At opfatte SaaS som et frikort · AGPL, apps og lokale klienter kan ændre svaret.
Det skal I kræve af den eksterne
- ☐ En licensoversigt, der dannes automatisk og holdes ajour.
- ☐ En regel for godkendte licenser, skrevet ned og besluttet.
- ☐ En kontrol i byggepipelinen, så problemer dukker op tidligt.
- ☐ Tydelig besked om, hvornår en advokat skal ind over.
Kilder
- Ophavsretsloven, LBK nr. 1093 af 20. august 2023
- Licensernes egne tekster, som følger med de enkelte komponenter, er kilden til de pligter, der gælder.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvem ejer koden · Bygge, købe eller integrere
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
