Open Source.

Open source is software waarvan de broncode openbaar is. Iedereen mag hem bekijken, gebruiken, aanpassen en verder verspreiden, binnen de voorwaarden van de licentie die erop zit.

Het internet draait er grotendeels op. Linux, Apache, nginx, MySQL, PHP, WordPress en vrijwel alle programmeertalen zijn open source. De kans is groot dat je website op een stapel draait waarvan geen enkel onderdeel is gekocht.

Wat het niet betekent

Twee misverstanden die ik in vrijwel elk gesprek tegenkom.

Open source is niet hetzelfde als gratis. De code is vrij beschikbaar, en er zijn bedrijven die er goed aan verdienen met ondersteuning, hosting of betaalde uitbreidingen. WordPress kost niets; wat eromheen wordt verkocht wel.

Andersom geldt het net zo goed. Software die je gratis mag downloaden zonder dat je de broncode krijgt, heet freeware en is geen open source. Je mag hem gebruiken en verder niets.

Open source is niet vrij te gebruiken zoals jij wilt. Er zit altijd een licentie op, en die stelt voorwaarden. Sommige zijn ruim, andere leggen je iets op zodra je de software verder verspreidt.

Voor een ondernemer blijft dat verschil meestal theorie, want je gebruikt de software op je eigen site. Het wordt praktijk zodra je iets laat bouwen dat je aan anderen doorgeeft.

Waar de definitie vandaan komt

De beweging begon in 1983, toen Richard Stallman het GNU-project startte omdat hij een printerstuurprogramma niet mocht aanpassen. Twee jaar later richtte hij de Free Software Foundation op, en in 1989 verscheen de eerste GNU General Public License.

Die beweging draait om vier vrijheden: draaien waarvoor je wilt, bestuderen, verspreiden, en verbeterde versies doorgeven. Het Engelse woord free zorgde daarbij voor eindeloze verwarring, want dat betekent zowel gratis als vrij.

In 1998 bedacht een groep mensen de term open source om precies die verwarring te vermijden en het idee beter verkoopbaar te maken aan bedrijven. Datzelfde jaar werd het Open Source Initiative opgericht.

Die club beheert de Open Source Definition: tien punten waar een licentie aan moet voldoen om zo te mogen heten. Vrije verspreiding, beschikbare broncode, aanpassingen toestaan, geen discriminatie tegen personen of toepassingsgebieden. Staat een licentie niet op hun lijst, dan is het geen open source, hoe openbaar de code ook is.

De licenties op een rij

Grofweg zijn er twee families, en het verschil zit in wat er gebeurt als jij iets doorgeeft.

MIT en BSD. Ruim en kort. Je mag vrijwel alles, ook opnemen in gesloten commerciële software, mits je de vermelding van de oorspronkelijke maker meeneemt.

Apache 2.0. Vergelijkbaar, met twee toevoegingen. Er zit een uitdrukkelijke patenttoezegging in, en die vervalt als jij de makers zelf op patenten aanspreekt. Daarnaast moet je vermelden welke bestanden je hebt gewijzigd. Voor bedrijfsjuristen is dit vaak de licentie waar ze het rustigst van worden.

GPL. De licentie van WordPress. Verspreid je een werk dat erop voortbouwt, dan moet dat onder dezelfde licentie vallen en moet je de broncode meeleveren. Dat heet copyleft.

LGPL. Een lichtere variant, bedoeld voor bibliotheken. Je mag hem in gesloten software gebruiken zolang je de bibliotheek zelf niet verandert.

AGPL. Als GPL, maar de verplichting geldt ook als je de software alleen als online dienst aanbiedt. Dat is precies het gat dat GPL openliet: wie software draait maar niet uitlevert, verspreidt formeel niets.

Praktisch: controleer bij elke bibliotheek die in een project wordt gestopt welke licentie erop zit. Bij werk voor een klant die het resultaat later wil verkopen, is het verschil tussen MIT en AGPL geen detail.

Wat GPL betekent voor WordPress

WordPress valt onder GPL versie 2 of hoger. Dat is geen bijzaak van de kleine lettertjes, het bepaalt hoe de hele markt eromheen werkt.

Een thema of plugin praat rechtstreeks met de code van WordPress. In een juridische analyse die in 2009 in opdracht van de WordPress-gemeenschap werd gemaakt, luidde de conclusie dat de PHP-code van een thema daarmee een afgeleid werk is en dus onder GPL valt. Voor de afbeeldingen, de opmaak en de scripts in datzelfde thema zou dat niet gelden.

Dat is de reden dat je bij commerciële thema's zo vaak een gesplitste licentie ziet: het PHP-deel onder GPL, de rest onder eigen voorwaarden. Er is in 2010 een beroemde ruzie over gevoerd die eindigde met een thema dat alsnog volledig onder GPL kwam.

De officiële mappen op wordpress.org gaan verder: daar komt alleen materiaal in dat volledig verenigbaar is met GPL. Dat geldt ook voor de plugins waar Platform Pro mee werkt, zoals Beaver Builder.

Wat GPL uitdrukkelijk niet verbiedt is geld vragen. Je mag een plugin verkopen voor elk bedrag dat je wilt. Wat je niet mag, is de koper verbieden om de code door te geven.

Wat je koopt als je een thema of plugin koopt

Hier raakt de licentiekant je dagelijks werk, en hier zit de meeste verwarring.

Je betaalt niet voor het recht om de software te gebruiken, want dat recht geeft de GPL je al. Je betaalt voor updates, voor ondersteuning en voor de zekerheid dat er iemand aan werkt. Dat is een dienst, en daar mag een leverancier voorwaarden aan verbinden.

Vervalt je licentiesleutel, dan mag je de plugin blijven draaien. Je krijgt alleen geen updates meer, en dat is bij een plugin met een beveiligingslek een probleem dat groeit met de dag. Wie op vijf sites een verlopen plugin heeft staan, heeft vijf openstaande risico's.

De prijs is meestal per aantal sites. Technisch houdt niets je tegen om verder te gaan dan je hebt afgenomen, want de code laat zich kopiëren. Je verliest dan wel je aanspraak op ondersteuning, en je komt er meestal achter op het moment dat je die het hardst nodig hebt.

Er zijn winkels die GPL-plugins tegen een fractie van de prijs doorverkopen. Dat mag van de licentie. Wat je koopt is een bestand zonder updates van een partij die geen enkele band met de maker heeft, en er zijn genoeg gevallen bekend waarin er iets extra's in zat. Ik zou het niet doen.

Wie aansprakelijk is als er iets misgaat

Kort antwoord: de maker van de open source software vrijwel nooit, en jij tegenover je eigen klanten en bezoekers wel.

Elke gangbare open source licentie sluit garantie en aansprakelijkheid volledig uit. In de tekst van MIT en GPL staat dat de software wordt geleverd zoals hij is, zonder enige garantie. Er is geen leverancier, geen leveringsvoorwaarde en geen partij om aan te spreken. Je hebt met de maker ook geen overeenkomst gesloten.

Wat je wel hebt is een overeenkomst met de partij die je site heeft gebouwd of die hem beheert. Daar liggen de afspraken over updates, back-ups en herstel na een incident. Als je ergens aansprakelijkheid wilt regelen, is dat de plek, en niet de licentie van de plugin.

Onder de AVG ligt het nog scherper. Lekt er via een plugin persoonsgegevens van je bezoekers, dan ben jij als verwerkingsverantwoordelijke degene die dat binnen 72 uur bij de Autoriteit Persoonsgegevens moet melden. Dat de fout in gratis software van een onbekende zat, verandert daar niets aan.

Wil je die verantwoordelijkheid ergens neerleggen, dan koop je ondersteuning. Er zijn bedrijven die betaalde ondersteuning op open source pakketten leveren, met een echte overeenkomst en een aanspreekpunt. Bij bedrijfskritische software is dat vaak het geld waard. Voor een gewone bedrijfssite is een goede afspraak met je bouwer en je hostingpartij genoeg.

De Cyber Resilience Act verandert de verhoudingen

Europa heeft die aansprakelijkheidsvraag opgepakt. De Cyber Resilience Act is op 10 december 2024 in werking getreden en legt beveiligingseisen op aan software die commercieel op de Europese markt wordt gebracht.

De data om te onthouden: vanaf 11 september 2026 gaat de meldplicht in voor kwetsbaarheden die actief worden misbruikt, en vanaf 11 december 2027 gelden de eisen in volle omvang.

Voor open source is er bewust een aparte regeling gemaakt, omdat de wet anders elke vrijwilliger met een project op internet zou raken. Wie zonder commercieel oogmerk code publiceert valt erbuiten. Voor stichtingen en organisaties die open source projecten dragen is er een lichtere categorie met een eigen artikel, met plichten rond een beveiligingsbeleid en het melden van misbruikte lekken.

De volle last komt te liggen bij partijen die software commercieel op de markt brengen, ook als hun product grotendeels uit open source bestaat.

Wat merk je daar als bedrijf met vijf man van? Vooral dit: je leveranciers moeten kunnen vertellen wat er in hun product zit, in de vorm van een lijst met alle onderdelen. Dat is precies de informatie die tijdens een groot lek het verschil maakt tussen een middag uitzoeken en een week paniek.

Waar open source in Nederland zit

Dichterbij dan de meeste ondernemers denken. Je hosting draait vrijwel zeker op Linux met Apache of nginx, een database uit de MySQL-familie en PHP. Vier open source pakketten, waarvan je er geen enkel zelf hebt uitgezocht.

De Rijksoverheid heeft sinds 2020 als beleid dat broncode van software die in opdracht van de overheid is gemaakt openbaar wordt, tenzij er een reden is om dat niet te doen. De broncode van de corona-app is in 2020 op die manier gepubliceerd, voordat de app in gebruik werd genomen.

Bij gemeenten loopt onder de naam Common Ground een programma om gedeelde onderdelen als open source te bouwen, zodat niet elke gemeente hetzelfde apart laat maken.

Iets anders is de lijst met open standaarden van het Forum Standaardisatie, waar de overheid een pas toe of leg uit regel op hanteert. Open standaarden en open source zijn twee verschillende dingen: het eerste gaat over afspraken waar iedereen zich aan kan houden, het tweede over code die iedereen mag inzien.

En er is Nederlands geld in de andere richting. De NLnet Foundation financiert al decennia open source projecten, tegenwoordig deels met Europese middelen. Dat de infrastructuur van het internet niet volledig op vrijwilligerswerk drijft, komt mede daarvandaan.

Wat het je oplevert

• Geen afhankelijkheid van één leverancier. Stopt een bedrijf ermee, dan kan iemand anders verder met de code. Bij gesloten software eindigt het verhaal daar.
• Controleerbaar. Iedereen kan zien wat de software doet en waar hij verbinding mee maakt. Dat helpt zodra je moet uitleggen waar de persoonsgegevens van je bezoekers naartoe gaan.
• Aanpasbaar. Je kunt iets veranderen dat net niet past, zonder toestemming te vragen of te wachten op een leverancier die het misschien nooit gaat bouwen.
• Geen licentiekosten per gebruiker. Dat scheelt vooral zodra je groeit, want je rekening blijft gelijk als je van vijf naar vijftig medewerkers gaat.
• Snelle oplossingen bij bekende lekken. Bij een populair pakket ligt er meestal binnen dagen een nieuwe versie, en die is voor iedereen tegelijk beschikbaar.
• Een uitweg. Je kunt je gegevens en je code meenemen. Dat is bij een gehoste dienst lang niet altijd zo.

Waar je op let bij het kiezen van een pakket

De licentie is zelden je grootste risico. Het onderhoud wel.

Kijk wanneer een project voor het laatst is bijgewerkt en hoeveel mensen eraan werken. Een pakket dat door één persoon in zijn vrije tijd wordt gedragen kan morgen stoppen, en dat is geen verwijt maar een gegeven waar je rekening mee houdt.

Bij een WordPress-plugin staan de signalen op de pagina in de map zelf. Wanneer is hij voor het laatst bijgewerkt, tot welke WordPress-versie is hij getest, hoeveel actieve installaties zijn er, en worden vragen op het forum beantwoord of blijven ze maanden staan. Die vier gegevens vertellen je in twee minuten genoeg.

Kijk daarnaast of eerdere beveiligingsmeldingen zijn opgelost. Een openstaande lijst met jaren oude problemen betekent dat niemand er meer naar kijkt.

Voor een gewone bedrijfssite geldt verder een simpele regel: hoe minder plugins, hoe minder onderhoud. Elke toevoeging is een afhankelijkheid die je gaat bijhouden. Wat je verder aan onderhoud regelt staat in het artikel over een WordPress website beveiligen.

De toeleveringsketen is het echte risico

Openbare code betekent dat lekken door iedereen te vinden zijn, ook door mensen met slechte bedoelingen. In de praktijk werkt dat meestal in je voordeel, mits je bijwerkt. Het gevaarlijke scenario is een ander.

In maart 2024 bleek dat er een achterdeur zat in xz, een compressiebibliotheek die op vrijwel elke Linux-server staat. Iemand had zich twee jaar lang opgewerkt tot medebeheerder van het project en de code er daarna in gezet. Het werd ontdekt door een ingenieur die zich afvroeg waarom inloggen op zijn testmachine een halve seconde trager was geworden.

In december 2021 zat het lek in Log4j, een bibliotheek voor het bijhouden van logregels die in ontelbare bedrijfssystemen zat en door een handvol vrijwilligers werd onderhouden. Het Nationaal Cyber Security Centrum hield destijds een openbare lijst bij van getroffen software, omdat vrijwel niemand wist wat hij eigenlijk gebruikte.

Bij WordPress heeft het zijn eigen vorm. Een plugin met een grote gebruikersgroep wordt overgenomen door een nieuwe eigenaar, en een paar updates later staat er advertentiecode in of erger. De map op wordpress.org grijpt daarop in, alleen altijd achteraf.

Wat je ertegen doet: het aantal afhankelijkheden laag houden, updates niet laten liggen, en een controle instellen die je waarschuwt bij bekende kwetsbaarheden in wat je gebruikt. Voor de gangbare programmeertalen is dat gereedschap gratis en ingebouwd.

Licenties en eigenaren kunnen veranderen

Open source is niet automatisch voor altijd. De afgelopen jaren hebben meerdere bedrijven hun eigen product opnieuw gelicentieerd zodra concurrenten er te veel aan verdienden.

MongoDB begon ermee in 2018, Elastic volgde in 2021 en HashiCorp deed het in 2023 met Terraform. Redis ging dezelfde weg in 2024. In al die gevallen ging het naar een licentie die het gebruik beperkt en die het Open Source Initiative niet als open source erkent.

Wat er daarna gebeurde is het interessantste deel. Bij Terraform en bij Redis nam de gemeenschap de laatste vrije versie en ging zelfstandig verder onder een nieuwe naam. Zo'n afsplitsing heet een fork, en het recht om er een te beginnen is de echte bescherming die open source je biedt. Elastic en Redis zijn later overigens deels teruggekeerd naar een vrije licentie.

De WordPress-wereld had in het najaar van 2024 zijn eigen versie van dit verhaal, zij het over merknamen en toegang in plaats van over licenties. Een populaire plugin werd op wordpress.org overgenomen en onder een andere naam voortgezet, terwijl de oorspronkelijke makers gewoon met hun eigen versie doorgingen.

De les daaruit is nuchter. Een licentie beschermt de code. Hij beschermt niet het kanaal waarlangs je die code binnenkrijgt, en dat kanaal is meestal in handen van één partij. Weet dus altijd waar de bron van je software staat en hoe je hem zonder die ene map zou kunnen bijwerken.

Terugdoen zonder te programmeren

Als je bedrijf op open source draait, en dat doet het waarschijnlijk, dan valt er iets terug te doen zonder een regel code te schrijven.

Fouten melden met een duidelijke beschrijving is het waardevolste wat er is. Wat deed je, wat verwachtte je, wat gebeurde er, en welke versies gebruik je. Beheerders krijgen veel meer vage klachten binnen dan meldingen waar ze iets mee kunnen.

Documentatie verbeteren kan iedereen die de taal spreekt. De meeste projecten staan op GitHub, waar je een tekstwijziging in de browser kunt voorstellen zonder ook maar iets te installeren. Vertalen naar het Nederlands is een tweede route, en een contentmanagementsysteem als WordPress heeft daar een eigen vertaalomgeving voor.

Of gewoon geld geven. Veel projecten die het halve internet draaiende houden, worden onderhouden door een paar mensen zonder budget. Dat is een reëel risico voor iedereen die erop bouwt, en het is met een maandelijks bedrag per project deels op te lossen.

Veelgestelde vragen over open source

Wat betekent open source precies?

Open source betekent dat de broncode van software openbaar is en dat je hem mag bekijken, gebruiken, aanpassen en verspreiden. De licentie bepaalt onder welke voorwaarden dat mag.

Code die je wel kunt inzien maar niet mag aanpassen of doorgeven, valt er niet onder. Openbaar en open source zijn twee verschillende dingen.

Is open source hetzelfde als gratis?

Nee. Vrijwel alle open source software kost niets om te downloaden, en dat is een gevolg van de licentie en geen onderdeel ervan. Je mag open source software gewoon verkopen.

Andersom is gratis software niet automatisch open source. Krijg je een programma zonder de broncode, dan heet dat freeware.

Mag ik open source software commercieel gebruiken?

Ja, bij alle gangbare licenties. Geen enkele open source licentie mag onderscheid maken naar toepassingsgebied, dus commercieel gebruik uitsluiten kan niet.

Let alleen op wat er gebeurt zodra je iets doorgeeft aan anderen. Bij GPL en AGPL moet het resultaat dan onder dezelfde licentie vallen; bij MIT en Apache niet.

Wat is het verschil tussen GPL en MIT?

MIT is toegeeflijk: je mag de code overal in stoppen, ook in gesloten software, zolang je de vermelding van de maker meeneemt.

GPL is copyleft: verspreid je iets dat op GPL-code voortbouwt, dan moet dat ook onder GPL vallen. Voor eigen gebruik op je eigen server maakt het verschil niets uit.

Is WordPress open source?

Ja, WordPress valt onder GPL versie 2 of hoger. Je mag het gratis downloaden, gebruiken, aanpassen en doorgeven.

Dat geldt voor de software die je zelf installeert. Voor het verschil met de gehoste variant is er een apart artikel over WordPress.com tegenover WordPress.org.

Waarom zijn WordPress-thema's en plugins bijna altijd GPL?

Omdat ze rechtstreeks met de code van WordPress praten en daarmee als afgeleid werk worden gezien. De GPL van WordPress werkt dan door in wat erop voortbouwt.

Daarbij komt dat de officiële mappen op wordpress.org alleen materiaal opnemen dat volledig verenigbaar is met GPL.

Mag ik een gekochte plugin op meerdere websites gebruiken?

Van de GPL mag dat, want die legt geen beperking op het aantal installaties. Van je overeenkomst met de leverancier meestal niet, want daar koop je een aantal sites af.

Wat je verliest bij overschrijden zijn de updates en de ondersteuning voor die extra sites. Bij beveiligingsupdates is dat een echt risico en geen formaliteit.

Wie is aansprakelijk als open source software een lek veroorzaakt?

De maker vrijwel nooit. Elke gangbare open source licentie sluit garantie en aansprakelijkheid uit, en je hebt met die maker geen overeenkomst.

Aanspreekbaar is de partij waarmee je wel een overeenkomst hebt: je websitebouwer, je beheerder of je hostingpartij. Richting je bezoekers en de Autoriteit Persoonsgegevens blijf je zelf verantwoordelijk.

Is open source veilig?

Bij goed onderhouden pakketten meestal beter dan gesloten alternatieven, omdat meer mensen meekijken en oplossingen sneller beschikbaar zijn.

De zwakke plek zit in kleine projecten met weinig beheerders, en in de keten eronder. De achterdeur die in 2024 in de compressiebibliotheek xz werd gevonden, kwam van iemand die zich jarenlang als behulpzame medebeheerder had opgesteld.

Wat gebeurt er als een open source project stopt?

De code blijft van jou en blijft werken. Wat verdwijnt zijn de updates, en daarmee wordt het pakket na verloop van tijd een risico.

Bij populaire projecten pakt iemand anders het meestal op, soms onder een nieuwe naam. Bij een klein pakket dat je nergens anders tegenkomt is de kans daarop klein, en dat is precies waarom je bij de keuze naar het onderhoud kijkt.

Wat is een fork?

Een fork is een afsplitsing: iemand neemt de code zoals hij op dat moment is en gaat er zelfstandig mee verder onder een eigen naam.

Dat recht is de belangrijkste bescherming die open source je geeft. Toen de eigenaren van Terraform en Redis hun licentie beperkten, ging de gemeenschap in beide gevallen zelfstandig verder met de laatste vrije versie.

Wat betekent de Cyber Resilience Act voor open source?

De Europese wet legt beveiligingseisen op aan software die commercieel op de markt wordt gebracht. Vrijwilligers die zonder commercieel oogmerk code publiceren vallen erbuiten.

Voor organisaties die open source projecten dragen geldt een lichtere regeling. De meldplicht voor actief misbruikte kwetsbaarheden begint op 11 september 2026, de volledige eisen gelden vanaf 11 december 2027.

Hoe weet ik of een plugin nog wordt onderhouden?

Kijk op de pagina van de plugin naar vier dingen: de datum van de laatste update, tot welke WordPress-versie hij is getest, het aantal actieve installaties, en of vragen op het supportforum antwoord krijgen.

Staat de laatste update meer dan een jaar terug en blijven forumvragen onbeantwoord, ga dan op zoek naar een alternatief voordat je er iets belangrijks op bouwt.

Moet ik betalen voor ondersteuning op open source software?

Dat hoeft niet, en soms wil je het. Er is geen partij die je kunt bellen als er iets stukgaat, en gemeenschapsforums werken op goede wil.

Bij software waar je bedrijf op stilvalt is een betaalde ondersteuningsovereenkomst het overwegen waard. Je koopt daarmee geen andere software, je koopt een aanspreekpunt en een reactietijd.