Geschiedenis van open source software uitgelegd

Wat open source software is en waar het vandaan komt

De geschiedenis van open source software is grotendeels de geschiedenis van de bijbehorende licenties. Een licentie bepaalt immers als enige wat u mag doen met code die door iemand anders is geschreven. Code werd al openlijk gedeeld lang voordat iemand deze licenties op schrift stelde. Het delen stopte zodra software een product werd, en de licenties werden geschreven om het delen juridisch afdwingbaar te maken.

Dat is de korte versie. De lange versie is van belang omdat de software die u vandaag op een server draait, nog steeds de sporen van die beslissingen draagt. Sommige van die beslissingen werden genomen in 1983. Andere werden vorig jaar genomen, en zij zijn de reden dat enkele applicaties in onze self-hosting handleidingen nu in twee versies met verschillende namen beschikbaar zijn.

Software werd gedeeld voordat het werd verkocht

In de jaren 50 en 60 werd software meegeleverd met de machine. IBM leverde broncode bij zijn systemen en gebruikersgroepen zoals SHARE, opgericht in 1955, wisselden programma's uit via tapes. Twee ontwikkelingen maakten hier een einde aan. IBM kondigde in 1969 aan dat het software apart van hardware zou prijzen, wat een markt voor zelfstandige software creëerde. Daarna volgde de wetgeving. De Computer Software Copyright Act van 1980 bevestigde dat programma's in de Verenigde Staten werken zijn waarop auteursrecht rust. Na 1980 was code die u niet zelf had geschreven standaard gesloten, waardoor voor het delen ervan schriftelijke toestemming van de auteur vereist was.

De Homebrew Computer Club en de Open Brief aan Hobbyisten

De Homebrew Computer Club hield haar eerste bijeenkomst in maart 1975, in een garage in Menlo Park, Californië. Leden brachten hardware en ponsband mee, en het kopiëren daarvan was onderdeel van de bijeenkomst. Altair BASIC, geschreven door Bill Gates en Paul Allen, ging op gekopieerde band de kamer rond. In februari 1976 reageerde Gates in de nieuwsbrief van de club met "An Open Letter to Hobbyists".

Zoals de meerderheid van de hobbyisten moet weten, steelt het merendeel van jullie software.

Hij schreef dat minder dan één op de tien Altair-bezitters had betaald voor BASIC, en dat de computertijd die nodig was om het te schrijven meer dan 40.000 dollar waard was. Het volledige moderne debat is al in die brief terug te vinden. Het kopiëren van software kost niets en helpt iedereen die het kopieert. Het schrijven ervan kostte echter nog steeds iemand een jaar van zijn leven. Elke licentie die hieronder wordt beschreven, is een poging om beide feiten tegelijkertijd te adresseren.

GNU in 1983 en de GPL als juridische uitvinding

Richard Stallman kondigde GNU in september 1983 aan op Usenet, het nieuwsgroepnetwerk dat mensen gebruikten vóór het web. GNU staat voor "GNU's Not Unix". Het plan was een volledig Unix-compatibel systeem dat iedereen mocht kopiëren en aanpassen.

Vrije Unix! Vanaf Thanksgiving ga ik een volledig Unix-compatibel softwaresysteem schrijven genaamd GNU (voor Gnu's Not Unix), en dit gratis weggeven aan iedereen die het kan gebruiken.

De Free Software Foundation (FSF) volgde in 1985. De definitie van vrije software van de FSF somt vier vrijheden op, genummerd vanaf nul: het programma voor elk doel uitvoeren, het bestuderen en aanpassen, kopieën herdistribueren en uw aangepaste versies distribueren. Vrijheid 1 vereist de broncode, omdat niemand een binair bestand op een praktische manier kan bestuderen. "Vrij" betekent hier vrijheid en niet de prijs. De eigen uitdrukking van de FSF is "free as in free speech, not free beer".

Het manifest was niet de uitvinding. De licentie was dat wel. De GNU General Public License (GPL) gebruikt auteursrecht om delen te verplichten in plaats van te voorkomen. U ontvangt de vier vrijheden onder één voorwaarde: iedereen aan wie u de software doorgeeft, ontvangt deze ook, inclusief de broncode. Stallman noemde dit copyleft. Het werd voor het eerst uitgebracht met GNU Emacs in 1985, werd GPL versie 1 in 1989 en versie 2 in juni 1991.

De GPL werkt omdat deze op het auteursrecht steunt, niet ertegenin gaat. Zonder licentie heeft u helemaal geen recht om andermans code te distribueren. De GPL verleent dat recht en verbindt er voorwaarden aan. Een leverancier die aangepaste GPL-code in een router levert en weigert de broncode te overhandigen, breekt dus geen belofte. Zij schenden het auteursrecht, waarvoor een auteursrechthebbende naar de rechter kan stappen. Daarom is handhaving mogelijk, van de gpl-violations.org-zaken van Harald Welte in de jaren 2000 tot de rechtszaak van de Software Freedom Conservancy tegen Vizio, aangespannen in 2021, waarin wordt gesteld dat een persoon die de televisie heeft gekocht ook de broncode mag eisen.

Linux voltooit het systeem

Rond 1991 beschikte het GNU-project over de compiler, de C-library, de shell en het merendeel van de tools. Er was echter geen werkende kernel, omdat de eigen kernel van GNU, de Hurd, veel langer op zich liet wachten dan gepland. In augustus 1991 plaatste een student uit Helsinki een bericht in de nieuwsgroep comp.os.minix:

Ik werk aan een (vrij) besturingssysteem (slechts een hobby, het zal niet groot en professioneel worden zoals gnu) voor 386(486) AT-klonen.

Linux 0.01 verscheen in september 1991 onder een licentie die Linus Torvalds zelf had geschreven en die verkoop verbood. Begin 1992 verving hij deze door de GPLv2; hij heeft sindsdien verklaard dat dit een van zijn beste beslissingen was. Deze licentie maakte bijdragen door bedrijven veilig: een bedrijf kon engineers aan de kernel laten werken in de wetenschap dat een concurrent die verbeteringen niet privé kon houden.

Er bestond al een vrije Unix aan Berkeley. De reden dat Linux en niet BSD (Berkeley Software Distribution) de standaard vrije Unix werd, is deels te wijten aan een rechtszaak. Unix System Laboratories klaagde Berkeley Software Design aan in 1992 en de zaak liep tot begin 1994. Gedurende die twee jaar droegen BSD-systemen een juridisch risico en Linux geen enkel, en dat was het moment waarop de gebruikers instroomden. De FSF verzoekt mensen om het gecombineerde systeem GNU/Linux te noemen, aangezien Linux de kernel is en de meeste omliggende tools van GNU zijn. De meeste mensen zeggen Linux. Beide namen verwijzen naar dezelfde verzameling software.

1998: de rebranding naar open source en de breuk die nooit is geheeld

In januari 1998 kondigde Netscape aan dat het de broncode van zijn browser zou publiceren. Dit was destijds het grootste bedrijf dat een dergelijke stap zette, en het legde een praktisch probleem bloot. De term "free software" wordt in het Engels gelezen als "software die niets kost", en bedrijfsleiders interpreteerden het precies zo. Een groep kwam in februari 1998 in Palo Alto bijeen om een betere term te vinden, en Christine Peterson stelde "open source" voor. Binnen enkele weken richtten Eric Raymond en Bruce Perens het Open Source Initiative (OSI) op. Het nam de Open Source Definition aan, gebaseerd op de Debian Free Software Guidelines die Perens in 1997 had geschreven.

De Open Source Definition bevat tien criteria. Twee daarvan bepalen de meeste moderne discussies: de broncode moet beschikbaar zijn en de licentie mag niet beperken wie het programma mag gebruiken of waarvoor zij het mogen gebruiken. Een licentie die stelt "u mag dit niet als commerciële dienst aanbieden" voldoet niet aan de test, ongeacht wat er verder wordt toegestaan. Onthoud deze zin goed. Het is de grens die de huidige source-available licenties overschrijden.

De breuk die in 1998 ontstond, gaat over de beweegredenen, niet over welke licenties acceptabel zijn. Het standpunt van de FSF is ethisch: een gebruiker die het programma niet kan wijzigen, heeft geen controle over zijn eigen computer. Het standpunt van het OSI, dat door Raymonds essay "The Cathedral and the Bazaar" aan het bedrijfsleven werd gepresenteerd, is praktisch: open ontwikkeling levert betere software op, en een bedrijf kan daarvan profiteren. Stallmans repliek, "Why Open Source Misses the Point of Free Software", is nog steeds gepubliceerd op gnu.org, en hij heeft de nieuwere term nooit geaccepteerd. Perens, die hielp bij de oprichting, trad in 1999 af uit het bestuur van het OSI met de mededeling dat de beweging was afgedreven van vrije software.

Het is de moeite waard om precies te zijn over hoe klein het praktische gat is. De lijst met vrije licenties van de FSF en de lijst met goedgekeurde licenties van het OSI komen op bijna alle punten overeen, inclusief de GPL, MIT, Apache 2.0 en BSD. Auteurs die beide betekenissen tegelijkertijd willen aanduiden, gebruiken FOSS (free and open source software) of FLOSS (free/libre and open source software).

Hoe bedrijven leerden software uit te brengen

De beursgang van Red Hat in 1999 toonde aan dat er meer geld te verdienen viel met ondersteuning en verpakking dan met de verkoop van kopieën. IBM investeerde in 2001 een miljard dollar in Linux. De CEO van Microsoft noemde Linux in 2001 "een kankergezwel", maar in 2016 trad hetzelfde bedrijf toe tot de Linux Foundation als platinum-lid, om vervolgens in 2018 GitHub te kopen voor 7,5 miljard dollar in aandelen. IBM kocht Red Hat in 2019 voor 34 miljard dollar. Dit was geen verandering van inzicht wat betreft licenties. Het was een verschuiving in waar het geld zich bevindt. Wanneer een besturingssysteem een gedeelde kostenpost is, is het onderhouden van een eigen versie duur, en elke leverancier concurreert liever op de laag daarboven.

Zakelijk eigendom werkt ook de andere kant op. Toen Oracle in 2010 Sun kocht, erfde het MySQL en OpenOffice.org, waarna beide gemeenschappen vertrokken. MariaDB ontstond uit MySQL en LibreOffice werd in september 2010 afgesplitst van OpenOffice.org. Een fork is de enige stem die een gebruikersgemeenschap werkelijk heeft, en de licentie is wat die stem mogelijk maakt.

Waarom sommige zelfgehoste applicaties tegenwoordig forks hebben

Vanaf 2018 wijzigde een groep bedrijven de voorwaarden van software die zij al hadden uitgebracht. De situatie was telkens hetzelfde. Eén bedrijf nam bijna alle ontwikkelaars in dienst, een veel grotere cloudprovider verkocht dezelfde software als een managed service, en het kleinere bedrijf concludeerde dat de licentie de reden was dat zij niet konden concurreren.

• MongoDB nam in oktober 2018 de Server Side Public License (SSPL) aan. De SSPL stelt dat als u de software als dienst aan anderen aanbiedt, u de broncode moet publiceren van alles wat u gebruikt om die dienst te leveren. De OSI accepteerde dit niet als open source en MongoDB trok de licentie in 2019 terug uit de beoordeling.
• Redis voegde in 2018 en 2019 gebruiksbeperkingen toe aan sommige modules en stapte in maart 2024 met versie 7.4 over naar dubbele source-available voorwaarden. Enkele dagen later verscheen een fork van de laatste BSD-gelicentieerde release onder de naam Valkey, vallend onder de Linux Foundation en ondersteund door onder andere Amazon, Google en Oracle. In mei 2025 voegde Redis de Affero General Public License versie 3 (AGPLv3) toe, die wel door de OSI is goedgekeurd, als derde optie voor Redis 8.
• Elastic stapte in januari 2021 voor Elasticsearch en Kibana af van de Apache 2.0-licentie en koos voor dubbele voorwaarden onder de SSPL en de Elastic License. Amazon maakte een fork genaamd OpenSearch. Elastic voegde in augustus 2024 de AGPLv3 toe als derde optie, en OpenSearch werd in september 2024 overgedragen aan de Linux Foundation als de OpenSearch Software Foundation.
• HashiCorp stapte in augustus 2023 voor Terraform en zijn andere tools over naar de Business Source License (BUSL). De BUSL is geen open source-licentie zolang deze van kracht is, omdat het concurrerend productiegebruik verbiedt. Elke release wordt op een vaste datum omgezet naar een open licentie, voor Terraform is dat vier jaar later. OpenTofu werd binnen enkele weken geforkt en valt inmiddels ook onder de Linux Foundation.

Beide partijen hebben een valide punt en niemand handelt te kwader trouw. Een bedrijf dat vijftig salarissen betaalt terwijl een veel grotere firma het werk doorverkoopt, heeft een probleem dat niet met goede wil alleen kan worden opgelost. Een gebruiker die bouwde op basis van de Apache 2.0-voorwaarden en wakker werd met nieuwe voorwaarden, heeft eveneens een probleem, en niemand heeft hen vooraf om toestemming gevraagd. Let op wat er daarna gebeurde in twee van deze gevallen. Nadat de forks voet aan de grond kregen, voegden Elastic en Redis beide weer sterke copyleft-bepalingen toe. Copyleft beantwoordde de oorspronkelijke klacht, omdat de AGPLv3 vereist dat een serviceprovider de wijzigingen die zij draaien, publiceert. Sinds augustus 2026 zijn beide projecten en beide forks nog steeds actief; dit is het resultaat waarvoor de licenties zijn ontworpen.

Wie mag een licentie wijzigen

Een project kan alleen van licentie veranderen als één partij het auteursrecht op het geheel bezit. Bedrijven verkrijgen die controle op een van de twee volgende manieren. Bij een overdracht van auteursrecht (copyright assignment) wordt het eigendom van elke bijdrage aan het bedrijf overgedragen. Een Contributor Licence Agreement (CLA) laat u als eigenaar, maar verleent het bedrijf voldoende rechten om uw werk onder een andere licentie uit te brengen. Beide worden meestal ondertekend door op een link te klikken die een bot in uw eerste pull request plaatst.

Linux heeft geen CLA. Bijdragen worden geleverd onder de GPLv2 met een Developer Certificate of Origin, en het auteursrecht is verspreid over duizenden personen en bedrijven. Niemand kan de licentie van Linux wijzigen, omdat het onmogelijk is om al die handtekeningen te verzamelen. Dezelfde bescherming geldt voor elk project met veel onafhankelijke auteursrechthebbenden, en dit is een sterkere bescherming dan een belofte, omdat het een feitelijke vaststelling is van wie wat bezit.

De vraag die u zich moet stellen bij software waar u van plan bent afhankelijk van te worden, is dus niet of het vandaag open source is. De vraag is wie dat zou kunnen veranderen en of zij dat alleen zouden kunnen doen.

Wat een foundation daadwerkelijk biedt

Een foundation beheert de assets en legt de regels vast voor besluitvorming. De Apache Software Foundation, de Linux Foundation, de daarbinnen vallende Cloud Native Computing Foundation en de Software Freedom Conservancy voeren elk een variant van deze taak uit. Een foundation is niet op magische wijze neutraal. Leden betalen voor hun zetels en de meeste mensen die fulltime aan een groot foundation-project werken, worden betaald door lidbedrijven. Wat u krijgt is beperkter, maar nog steeds zeer waardevol: het handelsmerk en het releaseproces zijn niet in handen van één leverancier, waardoor geen enkel bedrijf het project kan privatiseren.

Het handelsmerk is het aspect dat vaak over het hoofd wordt gezien. Code is gelicentieerd. Een naam is een handelsmerk en een handelsmerk valt niet onder de licentie van de code. U kunt de code altijd forken. U kunt de naam meestal niet behouden. Dat is de reden waarom de forks in dit verhaal Valkey, OpenSearch, OpenTofu en Forgejo worden genoemd.

Het probleem met beheerders

Moderne infrastructuur rust op projecten met een of twee onbetaalde beheerders, en de fouten die optreden maken dit zichtbaar. De Heartbleed-bug in OpenSSL in 2014 trof een bibliotheek die een groot deel van het versleutelde webverkeer afhandelde, onderhouden door een handvol mensen met vrijwel geen budget. Log4Shell in december 2021 dwong de wereldwijde incidentrespons door een klein team van vrijwilligers bij het Apache Log4j-project.

De XZ Utils-backdoor die in maart 2024 werd ontdekt, is het meest scherpe voorbeeld, omdat de aanval zich richtte op de beheerder in plaats van op de code. Een account besteedde ongeveer twee jaar aan het leveren van oprecht nuttige bijdragen aan een compressiebibliotheek die in alle Linux-distributies wordt gebruikt. Andere accounts oefenden druk uit op de uitgeputte enige beheerder om hulp te accepteren. De nieuwe mede-beheerder plaatste vervolgens een backdoor in de release-archieven, gericht op systemen waar de SSH (secure shell) daemon linkt tegen liblzma. Een ontwikkelaar vond dit tijdens het onderzoeken waarom inlogpogingen ongeveer een halve seconde langer duurden dan verwacht. Dat was geluk, en iedereen die erbij betrokken was, heeft dat publiekelijk toegegeven.

Er is inmiddels geld beschikbaar gekomen: GitHub Sponsors sinds 2019, Open Collective, het Duitse Sovereign Tech Fund sinds 2022 en het Alpha-Omega-project van de OpenSSF. Dit geld komt ongelijkmatig binnen en vindt meestal de projecten die al bekend zijn. Regelgeving is ook in aantocht. De Cyber Resilience Act van de Europese Unie is in december 2024 in werking getreden, waarbij de meeste verplichtingen vanaf december 2027 van toepassing zijn. Eerdere ontwerpen zouden fabrikantaansprakelijkheid hebben opgelegd aan onbetaalde vrijwilligers, dus de definitieve tekst creëert een lichtere categorie genaamd een "open source software steward" na langdurige lobbywerkzaamheden door stichtingen en distributies.

Wat de geschiedenis van open source betekent voor de software op uw VPS

Elke applicatie in onze handleidingen voor self-hosting is het resultaat van deze beslissingen. Nextcloud bestaat dankzij een fork: in 2016 verlieten de oprichter van ownCloud en een groot deel van het team het project om het opnieuw te starten onder de AGPLv3-licentie. Sindsdien draaien beide producten parallel aan elkaar. Die geschiedenis vormt de achtergrond voor de Nextcloud-alternatieven die het overwegen waard zijn en voor de self-hosted Dropbox-alternatieven die met beide concurreren.

Hetzelfde patroon zien we bij Git-hosting. Gitea begon in 2016 zelf als een fork van Gogs. Eind 2022 werden het handelsmerk en de domeinen van het project overgedragen aan een bedrijf. Codeberg startte in december van dat jaar de fork Forgejo, en Forgejo stapte met versie 9 in 2024 over van MIT naar GPLv3. Beide worden besproken in de self-hosted Git-serveropties, en het verschil in licentie is een belangrijke reden waarom ze steeds verder uit elkaar groeien. Ondertussen wordt de meeste vrije software ontwikkeld op GitHub, een gesloten platform in eigendom van Microsoft. Dit is een oude discussie met valide argumenten aan beide kanten: zie wat GitHub daadwerkelijk is.

Voordat u een server aan een project toewijst, zijn vier controles tien minuten van uw tijd waard.

• Lees het LICENSE-bestand in de repository, niet de marketingpagina. Pagina's blijven vaak "open source" roepen lang nadat het bestand zelf iets anders aangeeft.
• Zoek naar een CLA of een copyrightoverdracht. Als die bestaat, kan één eigenaar de voorwaarden voor toekomstige releases wijzigen.
• Zoek uit wie het auteursrecht bezit: één bedrijf, vele bijdragers of een stichting.
• Tel het aantal actieve beheerders. Een project met slechts één beheerder is een risico voor die persoon, maar net zo goed voor u.

Dit betekent niet dat u software van een enkele leverancier moet vermijden. Veel daarvan is uitstekend, en het feit dat er voor betaald wordt, is vaak de reden dat het überhaupt onderhouden wordt. Het geeft u inzicht in waar u aan blootgesteld wordt. Wanneer u beslist wat de moeite waard is om zelf te hosten, neem de licentie dan mee in de vergelijking, naast de geheugenvereisten.

U kunt een deel van deze geschiedenis lezen op de machine voor u. Elk pakket op een Debian- of Ubuntu-systeem levert zijn eigen voorwaarden mee:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Het eerste getal geeft aan hoeveel geïnstalleerde pakketten een copyrightbestand bevatten; meestal enkele honderden op een kleine VPS. Het tweede commando toont het begin van het bestand voor bash, waarin de GNU General Public License versie 3 wordt genoemd. Een ontbrekend bestand betekent dat het pakket niet volgens het Debian-beleid is gebouwd; dit is zeldzaam en verdient een nadere inspectie voordat u het vertrouwt.

FAQ

Wat is het verschil tussen vrije software en open source?

Deze termen dekken vrijwel dezelfde set licenties, maar verschillen van mening over waarom die licenties van belang zijn. "Vrije software" is de oudere term, afkomstig van de Free Software Foundation uit 1985, en het argument hiervoor is ethisch: een gebruiker die het programma niet kan aanpassen, heeft geen controle over de computer. "Open source" werd in februari 1998 bedacht om dezelfde licenties makkelijker uit te leggen aan bedrijven, en het argument hiervoor is praktisch. De licenties GPL, MIT, BSD en Apache 2.0 staan op beide officiële lijsten. Auteurs die beide termen tegelijk willen aanduiden, gebruiken FOSS of FLOSS.

Is source-available software hetzelfde als open source?

Nee. Source-available betekent dat u de broncode kunt inzien. Open source, volgens de Open Source Definition, betekent ook dat de licentie niet mag beperken wie de software gebruikt of waarvoor deze wordt gebruikt. Zowel de SSPL als de Business Source License beperken concurrerend commercieel gebruik, waardoor geen van beide volgens die definitie open source is, ook al publiceren ze beide de broncode. Als u de software alleen voor uzelf host, heeft u mogelijk nooit last van deze beperking. Als u een product wilt bouwen op basis van de software, lees dan eerst de licentietekst zorgvuldig door.

Kan een bedrijf een open source-licentie die het al heeft verleend intrekken?

Niet voor code die al is uitgebracht. Die versie blijft onder de licentie waaronder deze werd uitgebracht; dit is precies de reden waarom forks zoals Valkey en OpenTofu konden starten vanaf de laatste commit met een permissieve licentie. Wat een bedrijf wel kan doen, is toekomstige versies onder nieuwe voorwaarden uitbrengen, en dat kan alleen als het bedrijf het auteursrecht op het gehele project beheert via overdracht of een contributor licence agreement. Projecten met veel onafhankelijke auteursrechthebbenden, waaronder Linux, kunnen door niemand van licentie worden veranderd.

Naar welke licentie moet ik zoeken bij zelfgehoste software?

Voor software die u zelf draait en niet doorverkoopt, biedt elke door de OSI goedgekeurde licentie zoals GPL, AGPL, MIT of Apache 2.0 alles wat u nodig heeft. De nuttigere controle is wie het auteursrecht bezit, omdat dit bepaalt of de voorwaarden later in uw nadeel kunnen veranderen. Een project dat wordt beheerd door een stichting of door veel onafhankelijke bijdragers kan niet tegen de wil van de gebruikers van licentie worden veranderd. Een project van een enkele leverancier met een contributor licence agreement kan dat wel. Beide kunnen goede software zijn. Slechts één van beide kan de regels eigenhandig wijzigen.