07 nov 2025·8 min
Richard Stallman en vrije software: ideeën die code veranderden
Ontdek Richard Stallmans filosofie over vrije software, het GNU Project en de GPL—en hoe ze licenties, ontwikkelaarsrechten en open source hebben hervormd.
Ontdek Richard Stallmans filosofie over vrije software, het GNU Project en de GPL—en hoe ze licenties, ontwikkelaarsrechten en open source hebben hervormd.
Software is niet alleen een technisch product—het is ook een set permissies. Wie mag het draaien, kopiëren, met een vriend delen, een bug repareren of iets nieuws bovenop bouwen? Die vragen worden minder door code beantwoord en meer door licenties. Nu software centraal kwam te staan in werk, communicatie en onderzoek, begonnen de regels rond “wat je mag doen” innovatie net zo te vormen als de functies zelf.
Richard Stallman (vaak “RMS” genoemd) is belangrijk omdat hij die regels onmiskenbaar maakte. Begin jaren tachtig zag hij een verschuiving: meer programma’s werden zonder broncode verspreid en gebruikers werd steeds vaker verteld dat ze software alleen op iemands voorwaarden mochten gebruiken. Stallman stelde dit niet voor als een klein ongemak, maar als een verlies van gebruikers- en ontwikkelaarsvrijheid—en hij reageerde door een duidelijke set principes en juridische instrumenten voor te stellen om die vrijheden te beschermen.
Dit artikel richt zich op Stallmans ideeën en hun praktische gevolgen: de definitie van vrije software, het GNU Project, copyleft en de GNU General Public License (GPL)—en hoe die het moderne open‑source ecosysteem en de normen rond softwarelicenties vormgaven.
Het is geen biografie en het is geen technische duik in kernelcompilatie of repositorybeheer. Je hebt geen programmeerachtergrond nodig om het te volgen.
Stallman is invloedrijk en tegelijk controversieel. Het doel hier is feitelijk en leesbaar blijven: waar hij voor pleitte, welke juridische mechanismen ontstonden, hoe bedrijven en ontwikkelaars zich aanpasten, en waar debatten vandaag doorgaan—zodat je kunt zien waarom zijn werk nog steeds dagelijkse softwarekeuzes beïnvloedt.
"Vrije software" is makkelijk verkeerd te begrijpen omdat het woord vrij klinkt als een prijskaartje. Richard Stallman gebruikte vrij om vrijheid te bedoelen—het vermogen van de gebruiker om controle te hebben over de software waarop zij vertrouwen.
Als een programma €0 kost maar je mag het niet inspecteren, veranderen of delen, kan het nog steeds “gratis als in biertje” zijn terwijl het onvrij is in de zin waar Stallman om gaf.
Vrije software wordt gedefinieerd door vier basispermissies:
Deze vrijheden gaan over handelingsbekwaamheid: je bent niet alleen consument van gereedschap—je kunt deelnemer worden die het verifieert, aanpast en verbetert.
Vrijheden 1 en 3 zijn onmogelijk zonder toegang tot de broncode—de voor mensen leesbare instructies. Zonder die code lijkt software meer op een verzegeld apparaat: je kunt het gebruiken, maar je begrijpt niet wat het doet, je kunt het niet repareren als het kapot gaat, en je kunt het niet aanpassen aan nieuwe behoeften.
Toegang tot broncode is ook belangrijk voor vertrouwen. Het maakt onafhankelijke controle mogelijk (voor privacy, veiligheid en eerlijkheid) en maakt het haalbaar om software te onderhouden, zelfs als de originele ontwikkelaar stopt met ondersteunen.
Denk aan een restaurantmaaltijd.
Dat is de kern: vrije software gaat over de vrijheden die gebruikers nodig hebben om de controle over hun computergebruik te behouden.
Voordat "softwarelicenties" veelbesproken waren, draaide veel programmeercultuur—vooral aan universiteiten en in onderzoekslabs—op een aanname: als je een tool kon verbeteren, deelde je die verbetering. Broncode ging mee met software, mensen leerden door elkaars werk te lezen, en fixes verspreidden zich via informele samenwerking.
Die cultuur begon te veranderen toen software zelf een product werd. Bedrijven (en sommige instellingen) begonnen broncode als concurrentievoordeel te zien. Distributie ging gepaard met "niet delen"‑voorwaarden, code stopte mee te liften met programma’s, en geheimhoudingsverklaringen werden normaal. Voor ontwikkelaars die gewend waren problemen collectief op te lossen, voelde deze verschuiving niet alleen onaangenaam—het voelde als een regelswijziging die samenwerken juridisch riskant maakte.
Een van de meest vertelde oorsprongsverhalen gaat over een printer in MIT’s AI Lab. Stallman beschreef hoe er een nieuwe printer kwam waarvan de software alleen in binaire vorm werd verspreid, zonder broncode. Het praktische probleem was alledaags: het lab wilde het programma aanpassen om zaken te regelen zoals gebruikers informeren over vastlopers of het intelligenter routeren van taken. Onder de oudere "hacker"‑normen zou iemand de code patchen en de fix delen. Hier kon dat niet—omdat ze de bron niet mochten inzien of wijzigen.
Het is goed om dit in proportie te houden: het was niet één printer die een wereldwijde beweging heeft gecreëerd. Het was een duidelijk, herkenbaar voorbeeld van een bredere trend—tools waarop mensen vertrouwden werden onherstelbaar voor hun gebruikers.
Voor Stallman ging het kernprobleem niet alleen over technische toegang; het ging om het verlies van de vrijheid om samen te werken. Als je niet kunt bestuderen hoe een programma werkt, kun je het niet echt beheersen. Als je verbeteringen niet kunt delen, fragmenteren gemeenschappen en eindigt iedereen met het privé opnieuw uitvinden van fixes.
Die motivatie vormde de licentievernieuwingen die volgden. In plaats van te vertrouwen op goedheid of informele normen wilde Stallman regels die het vermogen om software te gebruiken, bestuderen, aanpassen en delen bewaren—zodat samenwerking niet kan worden teruggetrokken zodra een programma commercieel waardevol wordt.
Stallmans grote stap was niet alleen het schrijven van een manifest—het was het starten van een praktische engineeringinspanning. In 1983 kondigde hij het GNU Project aan, met een ambitieus doel: bouw een volledig besturingssysteem dat iedereen kan gebruiken, bestuderen, wijzigen en delen, en blijf compatibel met Unix zodat mensen vertrouwde programma’s en workflows konden draaien.
Een besturingssysteem is niet één programma—het is een hele stapel. GNU zette zich in om alle alledaagse onderdelen te maken die je nodig hebt om een computer nuttig te maken, waaronder:
Kort gezegd: GNU bouwde de leidingen, bedrading en schakelaars—niet slechts één apparaat.
Begin jaren negentig had GNU een groot deel van deze “userland” geproduceerd, maar één kritisch onderdeel bleef achter: de kernel (het deel dat direct hardware en systeembronnen beheert). Toen Linux in 1991 verscheen, vulde het die lacune.
Daarom combineren veel populaire systemen vandaag GNU‑componenten met de Linux‑kernel—vaak aangeduid als “GNU/Linux”.
GNU maakte het idee van vrije software concreet door een werkende basis te leveren waarop anderen konden voortbouwen. Filosofie legde uit waarom vrijheid belangrijk was; GNU leverde de tools die vrijheid praktisch, herhaalbaar en schaalbaar maakten.
Copyleft is een licentiestrategie die bedoeld is om software vrij (in de zin van vrijheid) te houden, niet alleen bij de eerste uitgave maar ook in toekomstige versies. Als je copyleft‑code ontvangt, mag je die gebruiken, bestuderen, wijzigen en delen—maar wanneer je je gewijzigde versie verspreidt, moet je diezelfde vrijheden weer doorgeven aan anderen.
Copyleft klinkt als “anti‑auteursrecht”, maar het steunt juist op auteursrechtwetgeving. De auteur gebruikt zijn auteursrechten om toestemmingsregels in een licentie vast te leggen: "Je mag dit kopiëren en wijzigen, maar als je het herdistribueert, moet je het onder dezelfde licentie houden." Zonder auteursrecht zou er geen juridisch instrument zijn om die voorwaarden af te dwingen.
Zie het als een regel die de code volgt:
Het doel is een patroon te voorkomen waar iemand communitywerk neemt, het verbetert en die verbeteringen vervolgens afsluit.
Permissieve licenties (zoals MIT of BSD) laten je meestal bijna alles met de code doen, inclusief het herdistribueren van gewijzigde versies onder een gesloten, propriëtaire licentie. Copyleft‑licenties (zoals de GNU GPL) staan breed gebruik en wijziging toe, maar vereisen dat herverdeelde afgeleiden onder dezelfde copyleft‑voorwaarden blijven—zodat de vrijheid downstream behouden blijft.
De GNU General Public License (GPL) veranderde softwarelicenties door “delen” om te zetten in een afdwingbare regel, niet slechts een vriendelijke handeling. Vóór de GPL kon je broncode krijgen, die verbeteren en vervolgens een gesloten versie uitbrengen die gebruikers niet konden bestuderen of wijzigen. De GPL keerde die dynamiek om: het beschermt de vrijheden van gebruikers door voorwaarden aan distributie te koppelen.
Concreet verleent de GPL gebruikers het recht om het programma voor elk doel te draaien, de bron te lezen en te wijzigen en de originele of gewijzigde versies te delen.
Als je GPL‑software herdistribueert (vooral in een product), moet je diezelfde vrijheden doorgeven. Dit betekent doorgaans:
De GPL‑verplichtingen treden vooral in werking wanneer je de software aan anderen distribueren—binaries verzenden, apparaten verkopen met de software of kopieën aan klanten geven. Als je GPL‑code voor intern gebruik aanpast en niet distribueert, hoef je meestal de bron niet te publiceren.
Je hebt geen juridische theorie nodig om het idee te begrijpen: als je programma GPL‑code opneemt op een manier die een gecombineerd werk creëert (bijvoorbeeld door het te linken in je applicatie), wordt het resultaat meestal als een afgeleid werk behandeld en moet het onder de GPL worden verspreid. Het simpelweg draaien van een GPL‑programma, of communiceren met dat programma als een apart proces via standaardinterfaces, is vaak anders.
GPLv2 is de klassieke veelgebruikte versie. GPLv3 voegt bescherming toe rond patentdeals en "tivoization" (hardware die gewijzigde software blokkeert). De LGPL is ontworpen voor bibliotheken: het staat toe om te linken vanuit propriëtaire programma’s onder bepaalde voorwaarden terwijl de bibliotheek zelf vrij blijft.
Vrije licenties (vooral de GNU GPL) doen meer dan alleen "delen toestaan"—ze beschermen het recht om software te bestuderen, te wijzigen en te herdistribueren op een manier die moeilijk terug te draaien is. Voor ontwikkelaars betekent dit dat je verbeteringen beschikbaar kunnen blijven voor anderen onder dezelfde voorwaarden, in plaats van opgeslokt te worden in een gesloten product zonder manier voor de community om te profiteren.
Onder de GPL kun je:
Daarom wordt de GPL vaak beschreven als “afdwingbare wederkerigheid.” Als iemand een GPL‑gedekt programma (of een afgeleid werk) distribueert, kan diegene geen aanvullende beperkingen opleggen die downstream‑gebruikers beletten dezelfde aanpassingen te maken en te delen.
Die rechten komen met verplichtingen wanneer je software distribueert:
Die verantwoordelijkheden zijn geen "valstrikken"—ze zijn het mechanisme dat voorkomt dat samenwerking verandert in eenrichtingsextractie.
Teams moeten licentie‑naleving behandelen als release‑hygiëne. Houd bij:
Een eenvoudige Software Bill of Materials (SBOM) en een herhaalbare checklist voor releases kunnen de meeste problemen voorkomen voordat juristen erbij komen.
Op code‑niveau beschrijven “vrije software” en “open source” vaak veel van dezelfde projecten. De scheidslijn gaat vooral over waarom delen belangrijk is.
De Free Software‑beweging (geassocieerd met Richard Stallman en de Free Software Foundation) ziet softwarevrijheid als een ethische kwestie: gebruikers zouden het recht moeten hebben software te draaien, te bestuderen, te wijzigen en te delen. Het punt is niet alleen betere techniek—het is het beschermen van gebruikersautonomie.
De Open Source‑benadering benadrukt praktische uitkomsten: betere samenwerking, snellere iteratie, minder bugs en verbeterde veiligheid door transparantie. Het presenteert openheid als een superieur ontwikkelmodel, zonder teams te dwingen een moreel standpunt in te nemen.
In 1998 populariseerde de Open Source Initiative (OSI) de term “open source” om het idee zakelijker en toegankelijker te maken. “Free software” werd vaak verkeerd begrepen als “kosteloos”, en sommige bedrijven voelden zich ongemakkelijk bij een boodschap die rond rechten en ethiek was geslingerd. “Open source” gaf organisaties een manier om te zeggen “we kunnen zo werken” zonder ideologisch te klinken.
Veel projecten die zichzelf open source noemen gebruiken de GNU GPL of andere copyleft‑licenties, terwijl anderen permissieve licenties zoals MIT of Apache kiezen. De juridische tekst kan identiek zijn; het verhaal dat aan bijdragers, gebruikers en klanten wordt verteld verandert. De ene boodschap is “dit beschermt je vrijheden”, de andere is “dit vermindert wrijving en verbetert kwaliteit.”
Als het prioriteit van je team is dat downstream‑gebruikers dezelfde vrijheden behouden, kies dan de vrije software‑framing en overweeg copyleft.
Als je prioriteit is maximale adoptie (ook door bedrijven die geen wederkerige verplichtingen willen), past de open source‑framing en vaak een permissieve licentie beter.
Als je brede samenwerking wilt maar ook wilt dat verbeteringen terugvloeien, gebruik dan open‑source taal voor toegankelijkheid en kies copyleft voor het resultaat.
Vrije software betekent niet “niemand krijgt betaald.” Het betekent dat gebruikers de vrijheid hebben om de code te draaien, bestuderen, wijzigen en delen. Veel bedrijven bouwen gezonde omzet rond die vrijheid—vaak door te vragen voor zaken waar organisaties echt tegenaan lopen: betrouwbaarheid, verantwoordelijkheid en tijd.
Enkele gangbare, bewezen modellen:
Een moderne twist op het "managed offering"‑model is de opkomst van platforms die snel applicaties genereren en draaien. Bijvoorbeeld, Koder.ai is een vibe‑coding platform dat teams helpt web-, backend‑ en mobiele apps te bouwen via chat—terwijl het nog steeds export van broncode ondersteunt. Die combinatie (snelle iteratie plus eigendom van code) past goed bij de waarden achter softwarevrijheid: de mogelijkheid om je software te inspecteren, te wijzigen en te verplaatsen wanneer nodig.
De keuze van licentie kan bepalen wie waarde kan vangen:
“Commercieel” beschrijft hoe het verkocht wordt; “vrije software” beschrijft de rechten van de gebruiker. Een bedrijf kan vrije software verkopen, betalen vragen voor support en toch softwarevrijheid respecteren.
Voordat je een product op een FOSS‑project baseert of erop inzet, vraag:
De GPL en “FOSS” worden veel besproken, maar een paar hardnekkige mythen vertroebelen het beeld—vooral voor teams die gewoon een product willen uitbrengen zonder per ongeluk een licentie te schenden.
Dat is niet zo. Publiek domein betekent dat er geen auteursrechthebbende is die voorwaarden afdwingt—iedereen kan het werk zonder beperkingen hergebruiken.
De GNU GPL is het tegenovergestelde van “geen voorwaarden”. De auteur behoudt het auteursrecht en verleent brede toestemming om te gebruiken, wijzigen en delen—maar alleen als je de GPL‑voorwaarden volgt (bekendste eis: delen van de bron bij distributie van gedekte binaries).
Zichtbaarheid van code kan helpen bij veiligheid, maar het garandeert het niet. Een project kan open source zijn en toch:
Veiligheid komt voort uit actieve onderhoud, audits, verantwoordelijke melding en goede operationele praktijken—niet uit een licentielabel.
Mensen noemen de GPL soms “viraal” om te suggereren dat hij zich ongecontroleerd verspreidt. Dat is een geladen metafoor.
Wat men meestal bedoelt is copyleft: als je een afgeleid werk van GPL‑code distribueert, moet je de bijbehorende bron onder de GPL vrijgeven. Die eis is doelbewust: hij beschermt gebruikersvrijheden downstream. Het is geen "infectie"; het is een voorwaarde die je kunt accepteren—or vermijden door andere code te gebruiken.
Vuistregel: verplichtingen treden vooral bij distributie in werking.
Waar het ertoe doet, haal je een nauwkeurige beoordeling op basis van hoe de code is gecombineerd en verspreid—niet op aannames.
Richard Stallman is een controversieel figuur. Je kunt dat erkennen en toch duidelijk praten over de blijvende invloed van de ideeën en licenties die met hem geassocieerd zijn.
Een nuttige start is om twee gesprekken te scheiden: (1) discussies over Stallman als persoon en community‑lid, en (2) de meetbare impact van principes van vrije software, het GNU Project en de GNU GPL op softwarelicenties en ontwikkelaarsrechten. De tweede discussie kun je voeren op basis van primaire bronnen (licentieteksten, projecthistorie, adoptiepatronen) ook als mensen sterk van mening verschillen over de eerste.
Een terugkerende kritiek gaat niet over licenties, maar over governance: hoe projecten besluiten nemen, wie autoriteit heeft en wat er gebeurt als oprichters, maintainers en gebruikers verschillende wensen hebben. Vrije‑softwaregemeenschappen worstelen met vragen als:
Die vragen zijn belangrijk omdat licenties juridische afspraken geven, maar geen gezonde besluitvorming op zichzelf creëren.
Een ander lopend debat richt zich op inclusiviteit en gedragsregels: hoe projecten verwachtingen voor respectvol gedrag vastleggen, hoe ze conflicten behandelen en hoe gastvrij ze zijn voor nieuwkomers. Sommige communities benadrukken formele gedragscodes; andere geven de voorkeur aan minimale regels en informele moderatie. Geen van beide benaderingen is automatisch “juist”, maar de afwegingen zijn reëel en het verdient serieuze discussie zonder persoonlijke aanvallen.
Als je Stallmans nalatenschap beoordeelt, helpt het om beweringen verifieerbaar te houden: wat de GPL vereist, hoe copyleft nalevingspraktijken veranderde en hoe die ideeën latere licenties en instellingen beïnvloedden. Je kunt kritisch, ondersteunend of onbeslist zijn—streef naar precisie, respect en duidelijkheid over wat precies bekritiseerd wordt.
Stallmans grootste praktische gift aan alledaagse teams is een eenvoudige vraag: welke vrijheden wil je downstream garanderen? Het beantwoorden daarvan maakt "licentiekeuze" van een gevoel tot een beslissing.
Als je het niet zeker weet, baseer je keuze op je doel: adoptie (permissief) versus wederkerigheid (copyleft) versus bibliotheekvriendelijke wederkerigheid (zwakke copyleft).
LICENSE‑bestand in de root van de repo toe (kopieer de volledige licentietekst).Als je producten bouwt met AI‑assisted development (inclusief chatgestuurde platforms zoals Koder.ai), wordt deze checklist nog belangrijker: je levert nog steeds echte afhankelijkheden, echte artifacts en echte licentieverplichtingen. Snelheid neemt verantwoordelijkheid niet weg—het maakt herhaalbare compliance‑routines alleen waardevoller.
Houd het saai en herhaalbaar:
Voor diepere vergelijkingen, zie de tekstverwijzingen over choosing‑en gpl‑vergelijkingen: /blog/choosing-an-open-source-license en /blog/gpl-vs-mit-vs-apache.
"Free software" betekent vrijheid, niet prijs.
Een programma kan €0 kosten en toch onvrij zijn als je het niet kunt inspecteren, aanpassen of delen. Vrije software gaat over de rechten om het software te draaien, te bestuderen, te wijzigen en te verspreiden.
De definitie is gebaseerd op vier permissies:
Als een van deze ontbreekt, verliezen gebruikers controle en wordt samenwerking moeilijker.
Omdat je praktisch gezien niet kunt bestuderen of wijzigen zonder de broncode.
Toegang tot broncode maakt het mogelijk om:
Copyleft gebruikt het auteursrecht om “gedeeld gelijk” te vereisen wanneer je het herdistribueert.
Je mag de software gebruiken, wijzigen en zelfs verkopen, maar als je een gewijzigde versie verspreidt, moet je de ontvangers dezelfde vrijheden geven (meestal door de bijbehorende bron vrij te geven onder dezelfde licentie).
De GPL geeft brede rechten (gebruik, bestuderen, wijzigen, delen) en vraagt wederkerigheid bij distributie.
Als je GPL‑gedekte binaries herdistribueert, moet je doorgaans:
Meestal niet.
Bij GPL‑software treden verplichtingen meestal in werking bij distributie. Als je GPL‑code wijzigt voor intern gebruik en je geeft geen kopieën aan derden, hoef je normaal gesproken je wijzigingen niet openbaar te maken.
(Randgevallen bestaan—beschouw dit als vuistregel, geen juridisch advies.)
Het hangt af van hoe de code wordt gecombineerd.
In het algemeen:
Als het relevant is, breng dan het exacte integratiepatroon in kaart voordat je iets uitbrengt.
Ze richten zich op verschillende zorgen:
Kies op basis van of je sterke wederkerigheid (GPL) wilt of bibliotheekvriendelijke wederkerigheid (LGPL).
Gewoonlijk niet onder de GPL.
Als je GPL‑software op je eigen servers draait en gebruikers alleen over het netwerk interacteren, deel je meestal geen kopieën, dus treden de GPL‑verplichtingen tot brondeling meestal niet in werking.
Als je wilt dat netwerkgebruik bronpublicatie vereist, kijk dan naar de AGPL en beoordeel die zorgvuldig voor je deploymentmodel.
Ja—veel bedrijven verdienen geld met vrije/open‑source software via diensten en levering, niet door gebruikersrechten te beperken.
Veelvoorkomende modellen zijn:
De keuze van licentie beïnvloedt strategie: permissief kan adoptie maximaliseren; copyleft kan gesloten forks ontmoedigen en wederkerigheid ondersteunen.