Fri programvare med CLA kan "teppedras"

Publisert 30. mars 2026

Hei! Jeg er bare en kode-apekatt, ikke en advokatt. Ta det jeg sier med en pote salt.

Opprinnelig var denne artikkelen en “IDLJ”, om noe jeg lærte om for litt over en måned siden av Morten LinderudNorge.Chat, men det ballet litt på seg og føles nå mer naturlig som en artikkel.

Jeg har lenge trodd at GPL-3.0 og andre såkalte ‘sterke copyleft’-lisenser betyr følgende: “programvaren kan brukes til alle formål, så lenge du gjør egne modifikasjoner og utvidelser tilgjengelige under samme lisens”. Dette er generelt sett korrekt, med litt variasjon mellom de ulike lisensene på hva som er å anse som en modifikasjon.

Feilaktig har jeg lenge antatt at kravet om å gjøre endringer tilgjengelige under samme lisens også gjelder den som opprinnelig lagde programvaren. I min verden betydde dette at så fort programvare var ‘sterk copyleft’, kommer alltid fremtidige versjoner også til å være det.

Dessverre er dette ikke sant. Disse lisensene er noe opphavsrettholderen gir til andre, men er ikke bundet av selv.

I praksis vil større prosjekter med mange bidragsytere, der bidragsyterene alle deler sin kode med hverandre under samme sterke copyleft-lisens, og alle beholder det opphavsrettslige eierskapet til sin egen kode, være ganske trygge. Dette er fordi de må alle gå sammen i enighet om den skal omlisensieres.

Problemet kommer når et prosjekt du er avhengig av, og har festet tillit til fordi det er ‘sterk copyleft’, enten (1) opphavsrettslig har bare én eier, eller (2) har én entitet med mye sterkere rettigheter til kildekoden enn alle andre. Da har du risiko, fordi en enkelt entitet kan bestemme seg for at fremtidige versjoner av programmet ikke lenger skal være fritt.

For meg virker det som at de fleste prosjekter innen ‘sterk copyleft’-programvare med en eier som ønsker å beholde rettighetene til å omlisensiere i fremtiden, oppnår dette ved bruk av såkalte “CLA”-er (bidragsyters lisensavtale). I disse avtalene beholder bidragsyteren fortsatt opphavsretten, men gir en svært omfattende og ugjenkallelig lisens til prosjektets eier, uten den samme restriksjonen rundt modifikasjoner og utvidelser som kommer med sterke copyleft-lisenser.

Selvfølgelig kan prosjektet “gafles”, og versjonen fra før lisensendringen skjedde vil fortsatt være fri, men det er mange prosjekter (spesielt de som rettes mot utviklere) som markedsføres med at de er fri programvare, men utvikles i all hovedsak av et enkelt selskap, og det er vanskelig å bygge nok momentum til å vedlikeholde en gaffel. Dette utgjør en risiko.

Et eksempel på et slikt prosjekt er Overleaf, en populær nettside i akademia for å samarbeide om LaTeX dokumenter. For i overkant av et år siden priste jeg dem for å være AGPL-3.0-lisensiert fri programvare, men i dag ser jeg at for å bidra til prosjektet må du signere en CLA med eierene av Overleaf, som gir de rettighetene til å ta med din kode i en eventuell fremtidig omlisensiert versjon av programvaren.

Eksempler relativt ferskt i mitt minne på prosjekter som har gjort “åpen-kildekode teppedragning” inkluderer Redis og MinIO. Disse fungerte på litt ulike måter, og det er verdt å nevne at ingen av de var ‘sterk copyleft’+CLA, slik jeg har beskrevet hittil i artikkelen, men MinIO blir ganske nærliggende.

Redis var opprinnelig (frem til versjon 7.2) BSD-3-Clause-lisensiert, og hadde aldri en ‘sterk copyleft’-lisens. De trengte dermed ikke en CLA, da BSD-3-Clause gir veldig brede rettigheter for hva programvaren kan brukes til, og kommer ikke med noe krav om at endringer eller utvidelser skal gis ut under samme lisens.

Redis sin overgang til en såkalt ‘source-available’ lisens i 2024 fikk en rask respons i form av gaffelen “Valkey”, som fortsatt er BSD-3-Clause lisensiert, ser ut til å være godt vedlikeholdt, og eies av Linux Foundation. Redis har siden gjort enda en lisensendring, men min følelse er at utviklere flest fortsatt heller velger å stole på Valkey.

MinIO var annerledes. I april 2021 byttet de fra Apache-2.0 til AGPL-3.0, men krevde fra august 2021 at eksterne bidag ble lisensiert under Apache-2.0. (Hva som skjedde med eksterne bidrag i perioden april-august 2021 vet jeg ikke, dette er kanskje materiale for en fremtidig undersøkelse.) I slutten av 2025 var det klart at selskapet bak MinIO ikke lenger var intressert i å vedlikeholde den åpne versjonen av programvaren, og pekte brukere heller på det proprietære produktet “MinIO AIStor”. Dette kunne de gjøre, fordi eksterne bidragsytere hadde lisensiert sin kode til MinIO på et vis som gav de tillatelse til det. Siden februar 2026 har repoet vært arkivert på GitHub.

Det har ikke på samme måte som Valkey for Redis dukket opp en klar arvtaker etter MinIO. Gafler finnes selvfølgelig, men ingen av de aktivt vedlikeholdt såvidt jeg kan finne.

Andre alternativer som baserer seg på helt selvstendige kodebaser er Garage (AGPL-3.0) og SeaweedFS (Apache-2.0), begge uten CLA. Sistnevnte virker som den mest avanserte løsningen, som prøver å være mye mer enn “bare” en S3-erstatning, men er i all hovedsak laget av én enkelt utvikler, og trolig lite resistent mot likennde teppedragning. Førstnevnte ser litt mer indie og minimalistisk ut, med tilsynelatende 3-4 aktive utviklere.

Et av de mer omtalte alternativene er kanskje RustFS, men det har Apache-2.0 og CLA, så det er ingen grunn til å tro at det samme som skjedde MinIO ikke kan skje her også. Det gir meg også litt avsmak hvor mye de reklamerer for å være skrevet i Rust.

En annen faktor, som kan være grunn til at selskaper foretrekker ‘sterk copyleft’+CLA fremfor ‘permissive licensing’ er konkurransevern. Om selskapet bak produktet ønsker å lage en proprietær versjon med ekstra funksjoner, har de all rett til å gjøre det, men eventuelle konkurrenter må gjøre sine ekstra funksjoner offentlig tilgjengelig under samme lisens. Det kreves selvsagt ikke at eksterne signerer CLA med mindre de vil ha sin endring inn i den “offisielle” versjonen. Personlig har jeg egentlig ikke et stort problem med dette.

Fremover kommer det til å bli viktig for meg å ikke bare sjekke lisensen, men også hvorvidt det kreves at bidragsytere underskriver en CLA, sammen med hvem som står bak og hvor godt vedlikeholdt det er når jeg evaluerer om jeg skal bruke et program. Gullstandarden vil nok være ‘sterk copyleft’ uten CLA, med aktive vedlikeholdere, eller eierskap i en ideell organisasjon, som Linux, Valkey, eller (på den mer ekstreme siden) GNU-programvare.

Diskusjonen med Morten på Norge Chat var grunnet i at jeg sa jeg likte NetBird, et europeisk-utviklet alternativ til Tailscale. NetBird er AGPL-3.0-lisensiert, og markedsfører seg med at det er åpen kildekode, selv om det også er et kommersielt produkt. NetBird krever CLA, og det gjør meg nå usikker på at jeg fortsatt kan bruke i fremtiden, og mer engstlig for å avhenge av det.

Rent filosofisk synes ikke jeg at vi kan gjøre krav på fremtidig innsats fra åpen-kode-bidragsytere i å fortsette å vedlikeholde et prosjekt vi avhenger av. Vi kan heller ikke forvente av et selskap at de skal vedlikeholde åpne prosjekter om det ville vært mer inntektsbringende å gjøre de proprietære. Vi bør likevel være klar over at selskaper kan spekulere i å markedsføre seg som åpent, eller mer generelt å gjøre noe gratis tilgjengelig i begynnelsen, for å bygge en brukerbase som avhenger av de som infrastruktur, for så å gjøre produktet proprietært. Det er dette vi bør kjenne igjen som teppedragning.