07 nov. 2025·8 min
Richard Stallman och fri programvara: idéer som förändrade koden
Utforska Richard Stallmans filosofi om fri programvara, GNU‑projektet och GPL—och hur de omformade licenser, utvecklarrättigheter och öppen källkod.
Utforska Richard Stallmans filosofi om fri programvara, GNU‑projektet och GPL—och hur de omformade licenser, utvecklarrättigheter och öppen källkod.
Mjukvara är inte bara en teknisk produkt—det är också ett paket med rättigheter. Vem får köra den, kopiera den, dela den med en vän, laga en bugg eller bygga något nytt ovanpå? De frågorna besvaras mindre av själva koden och mer av licenserna. När mjukvara blev central för arbete, kommunikation och forskning började reglerna kring “vad du får göra” forma innovation lika mycket som funktionerna gjorde.
Richard Stallman (ofta kallad “RMS”) är viktig eftersom han gjorde de här reglerna omöjliga att ignorera. I början av 1980‑talet såg han en förändring: fler program distribuerades utan källkod och användare fick i allt större grad veta att de bara fick använda mjukvaran på någon annans villkor. Stallman beskrev detta inte som ett litet bekymmer utan som en förlust av användar‑ och utvecklarfrihet—och han svarade genom att föreslå tydliga principer och juridiska verktyg för att skydda de friheterna.
Den här artikeln fokuserar på Stallmans idéer och deras praktiska följder: definitionen av fri programvara, GNU‑projektet, copyleft och GNU General Public License (GPL)—och hur dessa formade det moderna ekosystemet för öppen källkod och normer för programvarulicenser.
Det är inte en biografi och inte en teknisk djupdykning i att kompilera kärnor eller hantera repositories. Du behöver ingen bakgrund i programmering för att hänga med.
Stallman är inflytelserik och också kontroversiell. Målet här är att vara faktabaserad och lättläst: vad han argumenterade för, vilka juridiska mekanismer som växte fram, hur företag och utvecklare anpassade sig, och var debatterna pågår idag—så att du kan se varför hans arbete fortfarande påverkar vardagliga mjukvaruval.
“Fri programvara” är lätt att missförstå eftersom ordet fri låter som ett pris. Richard Stallman använde fri för att mena frihet—användarens möjlighet att kontrollera den mjukvara de förlitar sig på.
Om ett program kostar 0 kronor men du inte får inspektera det, ändra det eller dela det, kan det fortfarande vara “fritt som i öl” samtidigt som det är ofritt i den mening Stallman brydde sig om.
Fri programvara definieras av fyra grundläggande tillstånd:
Dessa friheter handlar om handlingsutrymme: du är inte bara en konsument av verktyg—du kan bli en deltagare som kan verifiera, anpassa och förbättra dem.
Friheterna 1 och 3 är omöjliga utan tillgång till källkoden—de mänskligt läsbara instruktionerna. Utan den är programvara mer som en förseglad apparat: du kan använda den, men du kan inte förstå vad den gör, laga den när den går sönder eller anpassa den för nya behov.
Tillgång till källkod spelar också roll för förtroende. Den möjliggör oberoende granskning (för integritet, säkerhet och rättvisa) och gör det möjligt att underhålla mjukvara även om den ursprungliga utvecklaren slutar stödja den.
Tänk på en restaurangmåltid.
Det är kärnan: fri programvara handlar om de friheter användare behöver för att behålla kontroll över sin databehandling.
Innan “programvarulicensiering” blev ett vanligt debattämne byggde mycket programmeringskultur—särskilt inom universitet och forskningslaboratorier—på en oskriven regel: om du kunde förbättra ett verktyg delade du förbättringen. Källkoden följde ofta med programmen, folk lärde sig genom att läsa varandras arbete och bugfixar spreds genom informellt samarbete.
Den kulturen började förändras när mjukvara blev en produkt i sig. Företag (och ibland institutioner) började behandla källkod som en konkurrensfördel. Distribution kom med “ingen delning”-villkor, kod slutade levereras med programmen och sekretessavtal blev norm. För utvecklare som var vana vid att lösa problem kollektivt kändes detta inte bara besvärligt—det kändes som en regeländring som gjorde samhällsbaserat problemlösande juridiskt riskabelt.
Ett ofta citerat ursprungsexempel handlar om en skrivare vid MIT:s AI‑labb. Stallman har berättat hur en ny skrivare kom med mjukvara som bara distribuerades i binär form, utan källkod. Det praktiska problemet var vardagligt: labbet ville ändra programmet för att hantera meddelanden om pappersstopp eller smartare jobbrouting. Under den gamla “hacker”-normen skulle någon patcha koden och dela fixen. Här kunde de inte—för de fick inte se eller ändra källkoden.
Det är viktigt att hålla detta i proportion: det var inte en enskild skrivare som skapade en global rörelse. Det var ett tydligt, relaterbart exempel på en större trend—verktyg folk var beroende av blev ofixbara för sina användare.
För Stallman handlade kärnfrågan inte bara om teknisk åtkomst utan om förlusten av friheten att samarbeta. Om du inte kan studera hur ett program fungerar kan du inte kontrollera det. Om du inte kan dela förbättringar fragmenteras samhällen och alla börjar lösa problem privat.
Den motivationen formade de licensinnovationer som följde. Istället för att lita på välvilja eller informella normer ville Stallman ha regler som bevarade möjligheten att använda, studera, ändra och dela mjukvara—så att samarbetet inte kunde dras tillbaka i samma ögonblick som ett program blev kommersiellt värdefullt.
Stallmans stora initiativ var inte bara ett manifest—det var ett praktiskt ingenjörsarbete. 1983 tillkännagav han GNU‑projektet med ett ambitiöst mål: bygga ett komplett operativsystem som vem som helst kunde använda, studera, ändra och dela, och samtidigt vara kompatibelt med Unix så att folk kunde köra bekanta program och arbetsflöden.
Ett operativsystem är inte ett program—det är en hel stack. GNU satte upp sig att skapa alla vardagliga delar du behöver för att en dator ska vara användbar, inklusive:
Enkelt uttryckt: GNU byggde rördragningen, elinstallationerna och strömbrytarna—inte bara en enskild apparat.
I början av 1990‑talet hade GNU producerat en stor del av det här “userland”, men en kritisk del saknades: kärnan (delen som direkt hanterar hårdvara och systemresurser). När Linux dök upp 1991 fyllde den det gapet.
Därför kombinerar många populära system idag GNU‑komponenter med Linux‑kärnan—ofta kallat “GNU/Linux”.
GNU gjorde idén om fri programvara verklig genom att skapa en fungerande bas som andra kunde bygga vidare på. Filosofin förklarade varför frihet var viktig; GNU levererade verktygen som gjorde frihet praktisk, upprepbar och skalbar.
Copyleft är en licensstrategi som är utformad för att hålla mjukvara fri (i Stallmans mening) inte bara i första versionen, utan även i framtida versioner. Om du får copyleftad kod får du använda, studera, ändra och dela den—men när du distribuerar din modifierade version måste du ge vidare samma friheter till andra.
Copyleft låter som “anti‑upphovsrätt”, men bygger faktiskt på upphovsrätten. Upphovspersonen använder sin upphovsrätt för att ställa villkor i en licens: “Du får kopiera och modifiera detta, men om du återdistribuerar måste du behålla samma licens.” Utan upphovsrätt skulle det inte finnas något juridiskt sätt att upprätthålla dessa villkor.
Tänk på det som en regel som följer koden:
Målet är att förhindra ett mönster Stallman var orolig för: någon tar gemenskapsarbete, förbättrar det och låser sedan in förbättringarna.
Permissiva licenser (som MIT eller BSD) låter dig i stort sett göra vad du vill med koden, inklusive att återdistribuera modifierade versioner under en sluten, proprietär licens. Copyleft‑licenser (som GNU GPL) tillåter fortfarande bred användning och modifiering, men kräver att distribuerade derivat förblir under samma copyleft‑villkor—så friheten bevaras nedströms.
GNU General Public License (GPL) förändrade programvarulicenser genom att göra “delning” till en verkställbar regel, inte bara en trevlig gest. Före GPL kunde du få källkod, förbättra den och sedan skicka en sluten version som användare inte kunde studera eller ändra. GPL vände på det: den skyddar användarnas friheter genom att koppla villkor till distribution.
I praktiken ger GPL användare rätt att köra programmet för vilket syfte som helst, läsa och ändra källkoden och dela originalet eller modifierade versioner.
Om du återdistribuerar GPL‑mjukvara (särskilt i en produkt) måste du föra vidare samma friheter. Det innebär vanligtvis:
GPL:s skyldigheter träder främst i kraft när du distribuerar mjukvaran till andra—skicka binärer, sälja enheter med mjukvaran eller ge kopior till kunder. Om du modifierar GPL‑kod för privat internt bruk och inte distribuerar den behöver du generellt inte publicera källkoden.
Du behöver ingen juridisk teori för att förstå huvudpoängen: om ditt program innesluter GPL‑kod på ett sätt som skapar ett kombinerat verk (till exempel genom länkning), behandlas resultatet ofta som ett derivat och måste distribueras under GPL. Att bara köra ett GPL‑program eller kommunicera med det som en separat process över standardgränssnitt ses ofta annorlunda.
GPLv2 är den klassiska, mycket använda versionen. GPLv3 lägger till skydd kring patentavtal och mot “tivoization” (enheter som blockerar modifierad mjukvara). LGPL är utformad för bibliotek: den tillåter länkning från proprietära program under vissa villkor samtidigt som biblioteket självt förblir fritt.
Fria licenser (särskilt GNU GPL) gör mer än att “tillåta” delning—de skyddar rätten att studera, modifiera och återdistribuera programvara på ett sätt som är svårt att ta tillbaka. För utvecklare betyder det att dina förbättringar kan förbli tillgängliga för andra under samma villkor istället för att smälta in i ett slutet system där samhället inte får ta del av dem.
Under GPL kan du:
Detta är anledningen till att GPL ofta beskrivs som “verkställbar ömsesidighet.” Om någon distribuerar ett GPL‑täck program (eller ett derivat) kan de inte lägga till restriktioner som hindrar nedströmsanvändare från att göra samma slags ändringar och dela.
De rättigheterna kommer med skyldigheter när du distribuerar mjukvara:
Dessa ansvar är inte fällor—de är mekanismen som förhindrar att samarbete blir ensidigt utvinning.
Team bör hantera licensefterlevnad som release‑hygien. Spåra:
Ett enkelt Software Bill of Materials (SBOM) och en repeterbar checklista för releaser kan förebygga de flesta problem långt innan jurister blir involverade.
På kodnivå beskriver “fri programvara” och “open source” ofta många av samma projekt. Splittringen handlar mest om varför delning är viktig.
Free Software‑rörelsen (associerad med Richard Stallman och Free Software Foundation) ser programvarufrihet som en etisk fråga: användare bör ha rätt att köra, studera, ändra och dela programvara. Poängen är inte bara bättre teknik—det är att skydda användarens självbestämmande.
Open Source‑synsättet betonar praktiska resultat: bättre samarbete, snabbare iteration, färre buggar och förbättrad säkerhet genom transparens. Det är bekvämt att presentera öppenhet som en överlägsen utvecklingsmodell utan att kräva att organisationer antar en moralisk hållning.
1998 populariserade Open Source Initiative (OSI) termen “open source” för att göra idén mer företagsvänlig. “Free software” missförstods ofta som “kostnadsfritt”, och vissa företag var vaksamma mot ett budskap format kring rättigheter och etik. “Open source” gav organisationer ett sätt att säga “vi kan arbeta så här” utan att låta ideologiska.
Många projekt som kallar sig open source använder GNU GPL eller andra copyleft‑licenser, medan andra väljer permissiva licenser som MIT eller Apache. Den juridiska texten kan vara densamma; berättelsen som berättas för bidragsgivare, användare och kunder ändras. Ett budskap är “detta skyddar dina friheter”, ett annat är “detta minskar friktion och förbättrar kvaliteten.”
Om ni vill ha brett samarbete men också att förbättringar återflyter, använd open source‑språk för tillgänglighet men välj copyleft för att uppnå resultatet.
Fri programvara betyder inte “ingen får betalt.” Det betyder att användarna har friheten att köra, studera, ändra och dela koden. Många företag bygger lönsamhet kring den friheten—ofta genom att ta betalt för det organisationer verkligen brottas med: tillförlitlighet, ansvarstagande och tid.
Några vanliga, beprövade modeller:
En modern twist är framväxten av plattformar som snabbt genererar och kör applikationer. Till exempel är Koder.ai en vibe‑coding‑plattform som hjälper team bygga webb, backend och mobilappar via chatt—samtidigt som den stödjer export av källkod. Den kombinationen (snabb iteration plus kodägande) passar naturligt med värdena bakom programvarufrihet: möjligheten att inspektera, ändra och flytta din mjukvara när du behöver.
Licensval kan forma vem som fångar värde:
“Kommersiell” beskriver hur det säljs; “fri programvara” beskriver användarens rättigheter. Ett företag kan sälja fri programvara, ta betalt för support och ändå respektera programvarufriheten.
Innan ni antar eller satsar på ett FOSS‑projekt, fråga:
GPL och “FOSS” diskuteras ofta, men några vanliga myter förvirrar särskilt team som bara vill leverera en produkt utan att oavsiktligt bryta en licens.
Det gör den inte. Public domain innebär att ingen upphovsrättsägare ställer villkor—vem som helst kan återanvända arbetet utan skyldigheter.
GNU GPL är motsatsen till “inga villkor”. Författaren behåller upphovsrätten och ger omfattande tillstånd att använda, modifiera och dela—men endast om du följer GPL:s villkor (mest känt: dela källkod när du distribuerar täckta binärer).
Synlig kod kan hjälpa säkerheten, men det garanterar den inte. Ett projekt kan vara open source och ändå vara:
Säkerhet kommer från aktivt underhåll, revisioner, ansvarig hantering av sårbarheter och god driftspraxis—inte från licensetiketten.
Folk kallar ofta GPL “viral” som om den sprider sig okontrollerat. Det är en laddad metafor.
Vad man brukar mena är copyleft: om du distribuerar ett derivat av GPL‑kod måste du ge motsvarande källkod under GPL. Det kravet är avsiktligt: det bevarar användarnas friheter nedströms. Det är inte en “infektion”; det är ett villkor du kan välja att acceptera—eller att undvika genom att använda annan kod.
Tumregeln: skyldigheter utlöses främst vid distribution.
När det väl spelar roll, skaffa en noggrann bedömning baserad på hur koden är kombinerad och distribuerad—inte bara antaganden.
Richard Stallman är en kontroversiell person. Det går att erkänna det—och samtidigt tala klart om den varaktiga påverkan av de idéer och licenser som associeras med honom.
En bra start är att separera två samtal: (1) debatter om Stallman som person och medlemi samhället, och (2) den mätbara effekten av principerna för fri programvara, GNU‑projektet och GNU GPL på programvarulicenser och utvecklarrättigheter. Den andra går att diskutera med primärkällor (licenstexter, projekthistorik, adoptionsmönster) även när människor har starka åsikter om den första.
En återkommande kritik handlar inte om licenser utan om styrning: hur projekt fattar beslut, vem som har auktoritet och vad som händer när grundare, underhållare och användare vill olika saker. Fria programvarusamhällen har brottats med frågor som:
Licenser sätter juridiska villkor, men skapar inte automatiskt hälsosamt beslutsfattande.
En annan debatt gäller inkludering och normer: hur projekt sätter förväntningar för respektfullt beteende, hanterar konflikter och välkomnar nykomlingar. Vissa projekt betonar formella uppförandekoder; andra föredrar få regler och informell moderation. Ingen metod är automatiskt “rätt”, men avvägningarna är verkliga och värda att diskutera utan personangrepp.
När du utvärderar Stallmans arv är det hjälpsamt att hålla påståenden verifierbara: vad GPL kräver, hur copyleft förändrade efterlevnadspraxis och hur dessa idéer påverkade senare licenser och institutioner. Du kan vara kritisk, stödjande eller osäker—målet är precision, respekt och klarhet i vad som kritiseras.
Stallmans största praktiska gåva till vardagsteam är en enkel fråga: vilka friheter vill ni garantera nedströms? Att svara på den gör “licensval” till en konkret beslutsprocess.
Om ni är osäkra, välj efter mål: adoption (permissiv) vs ömsesidighet (copyleft) vs biblioteksvänlig ömsesidighet (svag copyleft).
LICENSE‑fil i repo‑roten (kopiera fullständig licenstext).Om ni bygger produkter med AI‑stöd (inklusive chattbaserade plattformar som Koder.ai) blir den här checklistan ännu viktigare: ni levererar fortfarande riktiga beroenden, riktiga artefakter och riktiga licensskyldigheter. Hastighet tar inte bort ansvar—det gör repeterbara efterlevnadsrutiner mer värdefulla.
Gör det tråkigt och repeterbart:
För djupare jämförelser, se /blog/choosing-an-open-source-license och /blog/gpl-vs-mit-vs-apache.
“Fri programvara” betyder frihet, inte pris.
Ett program kan kosta 0 kronor och ändå vara ofritt om du inte kan undersöka, ändra eller dela det. Fri programvara handlar om rättigheterna att köra, studera, ändra och distribuera den programvara du är beroende av.
Definitionen bygger på fyra tillstånd:
Om någon av dessa saknas förlorar användarna kontrollen och samarbete blir svårare.
För att realistiskt studera eller ändra ett program behöver du källkoden.
Tillgång till källkod möjliggör:
Copyleft använder upphovsrätten för att kräva “dela‑lika” när du återdistribuerar.
Du kan använda, modifiera och även sälja programvaran, men om du distribuerar en modifierad version måste du ge mottagarna samma friheter (vanligtvis genom att släppa motsvarande källkod under samma licens).
GPL ger breda rättigheter (använda, studera, ändra, dela) och kräver ömsesidighet vid distribution.
Om du återdistribuerar GPL‑täckta binärer måste du vanligtvis:
I många fall nej.
För GPL utlöses skyldigheter vanligtvis vid distribution. Om du modifierar GPL‑kod för internt bruk och inte ger kopior till någon utanför din organisation behöver du vanligtvis inte publicera ändringarna.
(Det finns undantag — betrakta detta som en tumregel, inte juridisk rådgivning.)
Det beror på hur koden kombineras.
Generellt:
När det spelar roll, kartlägg exakt integrationsmönster innan du skickar ut programvara.
De riktar sig mot olika frågor:
Välj beroende på om du vill ha stark ömsesidighet (GPL) eller biblioteksvänlig ömsesidighet (LGPL).
Vanligtvis inte under GPL.
Om du kör GPL‑program på egna servrar och användare bara interagerar över nätverket räknas det oftast inte som “distribution”, så GPL:s skyldigheter att dela källkod triggas vanligtvis inte.
Om du vill att nätverksanvändning ska kräva källkodssläpp, titta på AGPL och utvärdera den noga för din distributionsmodell.
Absolut — många företag tjänar pengar på fri/öppen källkod genom tjänster och leverans, inte genom att begränsa användarrättigheter.
Vanliga modeller:
Licensval påverkar strategi: permissiva licenser kan maximera adoption; copyleft kan uppmuntra ömsesidighet och göra det svårare att göra slutna fork‑produkter.