Öppen källkod licenser - skillnader och jämförelser

Öppen källkod driver i dag en enorm del av den digitala infrastrukturen – från Linux och WordPress till webbläsare, databaser och AI-modeller. Men "öppen källkod" är inte en enda sak. Det finns dussintals olika licenser, och vilken licens ett projekt använder avgör vad du faktiskt får göra med koden: om du kan använda den i kommersiella produkter, om du måste dela dina ändringar, och vilka juridiska skyldigheter du har. I den här artikeln reder vi ut skillnaderna mellan de viktigaste licenserna och hjälper dig förstå vilken som passar för olika situationer.

Innehåll

• Vad är öppen källkod?
• Två familjer av licenser: permissiva och copyleft
• Översikt: de viktigaste licenserna
• MIT-licensen
• Apache License 2.0
• BSD-licenserna
• GNU GPL (v2 och v3)
• GNU LGPL
• GNU AGPL
• Mozilla Public License 2.0
• Business Source License (BSL)
• Creative Commons
• Jämförelsetabell
• Vilken licens ska du välja?
• Vanliga fallgropar
• Sammanfattning
• Vanliga frågor

Vad är öppen källkod?

Öppen källkod (open source) innebär att programvarans källkod är fritt tillgänglig för vem som helst att granska, använda, modifiera och distribuera. Det är inte samma sak som "gratis" – öppen källkod handlar om frihet, inte pris. De flesta öppen källkods-licenser tillåter kommersiell användning, men villkoren varierar kraftigt beroende på vilken licens som används.

Open Source Initiative (OSI) är den organisation som certifierar vilka licenser som uppfyller den officiella definitionen av öppen källkod. Deras lista omfattar över 100 godkända licenser, men i praktiken domineras landskapet av en handfull. Enligt OSI:s egen statistik för 2025 är MIT, Apache 2.0, BSD (2- och 3-clause) och GNU GPL (v2 och v3) de mest eftersökta licenserna.

Två familjer av licenser: permissiva och copyleft

Alla öppen källkods-licenser kan delas in i två huvudkategorier, och att förstå skillnaden mellan dem är nyckeln till att navigera licenslandskapet:

Permissiva licenser (MIT, Apache, BSD) ställer minimala krav. De säger i princip: "gör vad du vill med den här koden, bara behåll upphovsrättsnotisen och stäm oss inte." Du får använda koden i kommersiella produkter, proprietär mjukvara och stängda projekt utan att behöva dela dina egna ändringar. Det är anledningen till att exempelvis Apple kunde bygga delar av macOS på BSD-kod utan att öppna macOS källkod.

Copyleft-licenser (GPL, LGPL, AGPL, MPL) kräver att om du modifierar koden och distribuerar den, måste dina modifieringar också släppas under samma licens. Det är den så kallade "share-alike"-principen – en garanti för att koden förblir öppen. Linux, WordPress och MariaDB är alla licensierade under GPL, vilket innebär att varje förbättring som distribueras måste vara öppen källkod.

Valet mellan permissivt och copyleft beror på vad du vill uppnå: maximal spridning och adoption (permissivt) eller maximal garanti för att koden förblir fri (copyleft).

Översikt: de viktigaste licenserna

Här går vi igenom de licenser du med störst sannolikhet kommer att stöta på i praktiken.

MIT-licensen

MIT-licensen är den mest använda öppen källkods-licensen i världen – den används av nästan 45 % av alla licensierade projekt på GitHub. Anledningen är enkel: den är extremt kort (171 ord), enkel att förstå och ställer minimala krav. Du får använda, kopiera, modifiera, slå ihop, publicera, distribuera, underlicensiera och sälja koden – så länge du inkluderar den ursprungliga upphovsrättsnotisen.

MIT-licensen innehåller ingen explicit patentklausul, vilket är en skillnad mot Apache. Den är kompatibel med i princip alla andra licenser, inklusive GPL, vilket gör den till det "säkra" valet för bibliotek och verktyg som vill ha maximal adoption.

Används av: React, Vue.js, jQuery, Node.js, Ruby on Rails, .NET, Babel

Apache License 2.0

Apache License 2.0 har samma permissiva grundfilosofi som MIT men med mer juridisk detaljrikedom. Den viktiga skillnaden är en explicit patentklausul: varje bidragsgivare ger automatiskt en patenträttslicens till användarna, och om någon stämmer dig med ett patentanspråk relaterat till projektet förlorar de sin rätt att använda koden. Det gör Apache-licensen populär bland företag som oroar sig för patentrisker.

Apache-licensen kräver också att modifieringar tydligt markeras som sådana – du måste ange vilka filer du ändrat. Den är kompatibel med GPL v3 (men inte GPL v2), vilket kan vara viktigt att veta vid licensmixning.

Används av: Android (AOSP), Kubernetes, TensorFlow, Apache HTTP Server, Swift, Rust-compilatorn

BSD-licenserna

BSD-licensfamiljen (Berkeley Software Distribution) finns i flera varianter. Den mest använda är BSD 2-Clause ("Simplified") och BSD 3-Clause ("New" eller "Revised"). Skillnaden är att 3-Clause-versionen lägger till en klausul som förbjuder att man använder ursprungsprojektets namn för att marknadsföra avledda produkter utan tillstånd.

Funktionellt liknar BSD-licenserna MIT-licensen – de är korta, permissiva och ställer minimala krav. Den historiska skillnaden ligger i ursprunget: MIT-licensen kommer från universitetsvärlden, medan BSD-licensen härstammar från Berkeley-distributionen av Unix.

Används av: FreeBSD, OpenBSD, Nginx (tidigare), PostgreSQL (liknande), Flask

GNU GPL (v2 och v3)

GNU General Public License är den mest kända copyleft-licensen och skapades av Richard Stallman och Free Software Foundation (FSF). Den finns i två aktivt använda versioner: GPL v2 (1991) och GPL v3 (2007). De är inte kompatibla med varandra – kod licensierad under "GPLv2 only" kan inte kombineras med GPLv3-kod.

GPL:s kärnmekanism är stark copyleft: om du distribuerar mjukvara som innehåller GPL-kod måste hela det sammansatta verket distribueras under GPL, inklusive tillgång till all källkod. Det innebär att företag inte kan ta GPL-kod, bygga in den i proprietär mjukvara och distribuera resultatet utan att dela källkoden.

GPLv3 lade till skydd mot patenttroll, förbättrad kompatibilitet med Apache 2.0 och skydd mot "tivoization" (hårdvarulåsning som förhindrar att modifierad mjukvara körs). GPLv2 saknar dessa skydd men föredras av projekt som Linux-kärnan, bland annat för att Linus Torvalds anser att GPLv3:s anti-tivoization-klausul går för långt.

Används av: Linux-kärnan (GPLv2), WordPress (GPLv2+), MariaDB (GPLv2), GIMP, GCC

GNU LGPL

Lesser General Public License (LGPL) är en mildare variant av GPL, specifikt designad för bibliotek. Den tillåter proprietär mjukvara att länka till LGPL-licensierade bibliotek utan att den proprietära koden behöver släppas under GPL. Däremot måste ändringar i själva LGPL-biblioteket fortfarande delas som öppen källkod.

LGPL var historiskt viktig för att möjliggöra att kommersiell mjukvara kunde använda GNU:s C-bibliotek (glibc) och andra systembibliotek. I dag har den tappat i popularitet till förmån för MIT och Apache, men den lever vidare i projekt som Qt och FFmpeg.

Används av: FFmpeg, Qt (LGPL-versionen), GNU C Library, VLC (delar)

GNU AGPL

Affero General Public License (AGPL) är GPL med en extra klausul som stänger det så kallade "molnkryphålet". Vanlig GPL utlöses bara vid distribution av mjukvara. Men om du kör mjukvaran som en nättjänst (SaaS) utan att distribuera den utlöses aldrig GPL:s krav – du kan ta GPL-kod, modifiera den och köra den på dina servrar utan att dela ändringarna.

AGPL löser detta genom att kräva att om mjukvaran görs tillgänglig över ett nätverk (exempelvis som en webbapplikation), måste källkoden erbjudas till användarna. Det gör AGPL populär för projekt som vill förhindra att molnleverantörer utnyttjar deras arbete utan att bidra tillbaka.

Används av: MongoDB (tidigare, nu SSPL), Nextcloud, Grafana, Mattermost

Mozilla Public License 2.0

MPL 2.0 är en svag copyleft-licens som tar en filbaserad approach: modifieringar av filer som ursprungligen var MPL-licensierade måste delas, men du kan fritt kombinera MPL-kod med proprietär kod i samma projekt, så länge de är i separata filer. Det gör MPL till en pragmatisk medelväg mellan permissiva licenser och stark copyleft.

MPL 2.0 är explicit kompatibel med GPL v2+, LGPL och AGPL, vilket gör den flexibel att kombinera med andra projekt.

Används av: Firefox, Thunderbird, LibreOffice (delar), Terraform (tidigare)

Business Source License (BSL)

BSL är inte en traditionell öppen källkods-licens – OSI godkänner den inte som open source. Men den har blivit alltmer vanlig, särskilt bland företag som vill skydda sig mot att molnleverantörer erbjuder deras produkt som tjänst. BSL tillåter fri användning av källkoden för de flesta ändamål, men med en begränsning: du får inte erbjuda en hostadversion av produkten som en konkurrerande tjänst.

En central del av BSL är att licensen automatiskt konverterar till en öppen källkods-licens (vanligtvis Apache 2.0) efter en bestämd tidsperiod – typiskt 3–4 år. Det ger företaget kommersiellt skydd medan produkten är aktuell, men säkerställer att koden till slut blir helt fri.

Används av: MariaDB MaxScale, Sentry, CockroachDB, HashiCorp Terraform (sedan 2023)

Creative Commons

Creative Commons (CC) är inte avsett för mjukvara utan för kreativt innehåll: text, bilder, musik, video och dokumentation. CC-licenserna är modulära – du kombinerar olika villkor: CC BY (attribution, ge credit), CC SA (share-alike, samma licens), CC NC (non-commercial, ej kommersiell användning) och CC ND (no derivatives, inga bearbetningar).

Den mest använda varianten för öppet innehåll är CC BY 4.0 (gör vad du vill, bara ge credit) och CC BY-SA 4.0 (ge credit och använd samma licens för derivat – samma princip som GPL fast för innehåll). Wikipedia använder CC BY-SA, och många dokumentationsprojekt använder CC BY.

Används av: Wikipedias innehåll (CC BY-SA), OpenStreetMap (ODbL, CC-liknande), många bloggar och utbildningsmaterial

Jämförelsetabell

Vilken licens ska du välja?

Valet av licens beror på vad du vill uppnå med ditt projekt. Här är en praktisk guide:

Du vill ha maximal spridning och adoption. Välj MIT eller Apache 2.0. Företag och utvecklare är mer benägna att använda din kod om licensen är permissiv. Vill du ha patentskydd på köpet, gå med Apache 2.0. Annars räcker MIT:s enkelhet.

Du vill garantera att koden förblir öppen. Välj GPL v3. Det säkerställer att alla som distribuerar modifierad kod också måste dela den. Perfekt om du vill bygga en community där alla bidrar på lika villkor.

Du bygger ett bibliotek som andra ska kunna använda i proprietär mjukvara. Välj LGPL eller MPL 2.0. De tillåter länkning utan att kräva att den proprietära koden öppnas, men modifieringar av själva biblioteket måste delas.

Du bygger en webbapplikation eller SaaS-produkt med öppen källkod. Välj AGPL. Utan AGPL kan molnleverantörer köra din kod utan att dela modifieringar. AGPL stänger det kryphålet.

Du bygger en produkt som du vill skydda kommersiellt, men ändå erbjuda öppen källkod. Överväg BSL. Det skyddar dig mot att konkurrenter erbjuder din produkt som en hostadtjänst, men koden blir helt öppen efter 3–4 år.

Du publicerar dokumentation, bilder eller utbildningsmaterial. Välj CC BY 4.0 (maximal frihet) eller CC BY-SA 4.0 (garanti att derivat förblir öppna).

Vanliga fallgropar

Att blanda inkompatibla licenser. GPL v2 och Apache 2.0 är inte kompatibla – du kan inte kombinera kod under dessa licenser i samma projekt. GPL v3 och Apache 2.0 är däremot kompatibla. Kontrollera alltid kompatibiliteten innan du blandar beroenden med olika licenser.

Att glömma att inkludera licensen. Kod utan licens är inte automatiskt fri – tvärtom, utan licens gäller upphovsrätt som standard, och ingen har laglig rätt att använda den. Lägg alltid en LICENSE-fil i projektroten.

Att underskatta copyleft-smittan. Om du inkluderar GPL-licensierad kod i ditt projekt kan hela projektet behöva licensieras under GPL. Det kan vara ett problem om du planerar att distribuera proprietär mjukvara.

Att anta att "öppen källkod" betyder "inga regler". Alla öppen källkods-licenser har villkor – ofta minimala, men de finns. Att inte följa dem (exempelvis att ta bort upphovsrättsnotiser från MIT-licensierad kod) kan leda till juridiska problem.

Sammanfattning

Öppen källkods-licenser är fundamentet som möjliggör samarbete i mjukvaruvärlden. De mest populära licenserna 2025 – MIT, Apache 2.0, BSD och GPL – har alla sina styrkor och passar olika situationer. Permissiva licenser maximerar adoption och flexibilitet. Copyleft-licenser garanterar att koden förblir fri. Nyare modeller som BSL adresserar molntidens kommersiella utmaningar. Oavsett vilken du väljer, se till att inkludera den – kod utan licens är inte fri kod.

Vanliga frågor

Vilken är den mest populära öppen källkods-licensen?
MIT-licensen, som används av nästan 45 % av licensierade GitHub-projekt. Den följs av Apache 2.0 och GPL.

Kan jag använda öppen källkod i kommersiella produkter?
Ja, de flesta öppen källkods-licenser tillåter kommersiell användning. Men copyleft-licenser som GPL kräver att du också öppnar din källkod om du distribuerar produkten.

Vad händer om jag använder GPL-kod i mitt proprietära projekt?
Om du distribuerar mjukvaran måste hela det sammansatta verket licensieras under GPL och källkoden göras tillgänglig. Undantaget är LGPL, som tillåter länkning utan copyleft-smitta.

Är BSL en öppen källkods-licens?
Nej, BSL godkänns inte av Open Source Initiative. Det är en "source-available"-licens med kommersiella begränsningar. Men koden konverterar automatiskt till en riktig öppen källkods-licens efter en bestämd tidsperiod.

Kan jag byta licens på mitt projekt?
Ja, om du äger all upphovsrätt. Om andra har bidragit med kod behöver du deras samtycke – eller använda en Contributor License Agreement (CLA) som ger dig rätten att relicensiera.

Vilken licens ska jag välja om jag inte vet?
MIT-licensen är det säkraste standardvalet. Den är kort, enkel, och ger alla maximal frihet att använda din kod. Om du senare bestämmer dig för att du vill ha starkare copyleft-skydd kan du relicensiera (om du äger koden).

Officiella resurser:

• opensource.org/licenses – OSI:s lista över godkända licenser
• gnu.org/licenses – FSF:s licensinformation
• choosealicense.com – GitHubs interaktiva licensväljare
• creativecommons.org/choose – Välj Creative Commons-licens

Hur kan vi på Webbproffs hjälpa er med öppen källkod och licenser?

Vi arbetar dagligen med öppen källkod – Joomla, WordPress, MariaDB, Matomo och en rad andra verktyg som alla styrs av specifika licenser. Vi kan hjälpa er att förstå licensvillkoren för de verktyg ni använder, säkerställa att ni uppfyller kraven och vägleda er i valet av licens för era egna projekt. Hör av er så berättar vi mer!