OPINIE – Opensource is gebouwd op vertrouwen: wie de broncode deelt onder een OSI-goedgekeurde licentie, geeft gebruikers het recht om die code vrij te gebruiken, aan te passen en te herdistribueren. Maar dat vertrouwen wordt nu opgerekt – of liever: misbruikt. Grote namen als Meta presenteren hun artificiële intelligence (ai)-modellen als ‘opensource’, terwijl restrictieve clausules commercieel gebruik onmogelijk maken. Dit ‘open washing’ misleidt bedrijven, verstoort marktwerking en ondermijnt vijfentwintig jaar opgebouwde zekerheid rond eigenaarschap in software. Hoog tijd dat ontwikkelaars én beslissers scherper naar licenties kijken en de term ‘opensource’ terugclaimen voordat hij zijn waarde verliest.
De renaissance van opensource en de sluiproute van restrictieve licenties
Opensource leeft weer. Niet alleen ontwikkelaars, maar ook beslissers zonder programmeerachtergrond praten tegenwoordig over llm-gewichten en permissieve licenties. Die hernieuwde belangstelling heeft echter een keerzijde: enkele van de meest zichtbare ‘open’ ai-projecten hebben voorwaarden die allerminst open zijn. Meta zette de toon toen Mark Zuckerberg de Llama-modellen in 2023 presenteerde als ‘opensource-ai’. De bijbehorende licentie sluit commerciële herdistributie echter uit: een directe schending van het ‘Open Source Definition‘-criterium ‘vrije herdistributie’.
De Open Source Initiative (OSI) corrigeerde Meta publiekelijk; Llama 3 is nog steeds ‘geen opensource in welke betekenis dan ook‘. Toch inspireerde de campagne van Meta andere bedrijven om de term te kapen. Van kleine startups tot gevestigde namen die hun model ‘source-available’ noemen, maar wél restricties opleggen aan concurrentie of cloud-distributie.
Eigent: Britse multi-agent hype met een eigen ‘open-source-plus’ licentie
Een voorbeeld dichter bij huis (nou ja: aan de overkant van het Kanaal) is Eigent, een VK-gebaseerde startup die een ‘multi-agent workforce’ op GitHub onderhoudt. In de README pronkt een ‘Eigent Open Source License‘, formeel gebaseerd op Apache 2.0 maar met extra voorwaarden die commerciële saas-exploitatie beperken.
Dankzij dergelijke clausules blijft de broncode zichtbaar en verifieerbaar, maar de vrijheid om het project integraal in te bouwen in closed-source-producten ontbreekt. Daarmee belandt Eigent in dezelfde categorie als Llama: bron inzichtelijk, maar niet vrij in OSI-zin. Ofwel, de source is open, maar het is geen opensource.
Dat is op zichzelf geen doodzonde; bedrijven mogen een eigen licensing-strategie kiezen. Het probleem ontstaat wanneer marketing die nuance negeert en het project tóch als ‘opensource’ bestempelt. Dan schendt men niet alleen de community-normen, maar creëert men ook juridische risico’s voor integrators die de kleine lettertjes missen.
Copyleft als tegenwicht
Ironisch genoeg maakt deze wildgroei aan ‘open-washing’ dat klassieke copyleft-licenties, de GPL-familie, weer aantrekkelijk worden. Waar permissieve licenties (MIT, Apache 2.0) vooral vrijheid maximaliseren, dwingen copyleft-licenties reciprociteit af: iedereen mag jouw code gebruiken, ook commercieel, mits verbeteringen mee terugstromen. Wie binaries zonder bron uitdeelt, moet een schriftelijk aanbod voor de bron meeleveren en latere wederverkopers verplichten hetzelfde te doen.
Ja, dat is een ‘commerciële restrictie’ in die zin dat je proprietary forks nauwelijks kunt verbergen. Maar het is een restrictie die vooraf duidelijk is, voor iedereen geldt en niet discrimineert op bedrijfsmodel. Dat onderscheidt copyleft fundamenteel van Llama-achtige ‘non-commercial’ clausules die wél selectief zijn en daarom niet door de OSI worden goedgekeurd.
Waarom steeds meer bedrijven tóch voor source-available kiezen
Juridisch adviseurs signaleren een breed verschuivende licensing-trend: van opensource naar ‘source-available’ om investeerders meer grip te geven op ip en data-exclusiviteit. Vooral ai-bedrijven vrezen dat concurrenten met een simpele fork én goedkope gpu-tijd hun marktplannen ondermijnen. De reflex is begrijpelijk, maar het gevolg is een grijs gebied waarin termen als ‘community edition’, ‘ethical opensource’ en ‘commercial-friendly license’ rondzingen zonder uniforme definitie.
Wat betekent dit voor Nederlandse cio’s en ontwikkelteams?
- Lees de licentie, niet de persberichten. Vertrouw nooit op het label ‘opensource’ zonder de clausules te controleren . Zeker bij ai-modellen en agent-frameworks.
- Check op OSI-goedkeuring. Een OSI-ID garandeert dat de tien OSD-criteria zijn gehaald, inclusief vrije herdistributie en non-discriminatie.
- Weeg copyleft opnieuw af. De verplichting om aanpassingen terug te geven kan vervelend lijken, maar biedt wél contractuele zekerheid én voorkomt dat u later afhankelijk wordt van een leverancier die de regels bijstelt.
- Let op downstream-effecten. Integreert u code met een Llama-achtige clausule in uw saas, dan kan dat later onderhandelingen met partners, investeerders of overnemende partijen bemoeilijken.
Conclusie: duidelijk taalgebruik herstelt vertrouwen
Het opensource-ecosysteem ontleende zijn kracht altijd aan transparantie en eenduidige definities. Nu AI de hype-curve domineert, lijken marketing-afdelingen die spijkerharde spelregels te vergeten. Door copyleft en OSI-goedgekeurde permissieve licenties consequent tegenover ‘source-available’- en ‘proprietary’-oplossingen te blijven zetten, houden we het gesprek zuiver.
Computable-lezers hoeven geen jurist te worden, maar wél hun terminologie op orde te hebben. Noem Eigent gerust een interessant Brits agent-experiment, maar label het niet als ‘opensource’ zonder disclaimer. En als u de volgende keer een keynote hoort die Llama een ‘open model’ noemt, vraag dan rustig: ‘Onder welke OSI-licentie dan precies?’
Want echte opensource begint, en eindigt, bij de licentietekst.
Bart van Maarseveen is ceo van Outpacr, een Nederlands bedrijf gespecialiseerd in lokaal draaiende ai-stacks op basis van permissieve opensource.
Misschien moet er maar eens een rechtszaak uitgevochten worden wanneer een bedrijf het woord “open” of “open source” kan gebruiken?
Nu is het natuurlijk een wildgroei als iedereen roept dat hun software of A.I. open is maar er heel erg beperkende voorwaarden zijn in het gebruik ervan.
“Open source” lijkt een beschermde term omdat de Open Source Initiative (OSI) er een duidelijke definitie en set erkende licenties voor heeft, maar juridisch is het geen beschermd label of merknaam. Lastige situatie dus.
Inmiddels heeft OpenAI twee open source modellen uitgebracht die keurig een open source Apache 2.0 hebben. Hopelijk is dit soort concurrentie iets dat de bedrijven weer in het gareel krijgt.
Leesbare code zegt nog niks over de gebruiksrechten want de sluiproute van restrictieve licenties is er al heel lang als we kijken naar het fenomeen van intellectuele eigendommen. Computable-lezers moeten juist wel jurist worden om dit te begrijpen want hetzelfde geldt voor gratis content. Opensource-ecosystemen ontlenen namelijk vooral hun kracht aan de bijdragen want transparantie en eenduidige definities mis ik al meer dan 30 jaar in kermis van open source. De auteur vergist zich met de open standaarden die niet om een licentie gaan.
Goede aanvulling, dank. Je hebt gelijk dat leesbaarheid of beschikbaarheid van code op zich niks zegt over de gebruiksrechten, precies dáár begint de verwarring. Restrictieve licenties bestaan inderdaad al langer, maar werden niet vaak zo prominent als open source gepresenteerd. Daarom vind ik het zo belangrijk om nu het onderscheid scherp te maken.
Ik richt me in dit stuk bewust op de impact bij organisaties die AI inzetten in hun kernprocessen. Daar gaat het niet alleen om community-bijdragen, maar juist om juridische overdraagbaarheid en controle. Voor hen is het verschil tussen een permissieve OSI-licentie en een restrictief model cruciaal: het bepaalt of je iets echt kunt inzetten als IP of dat je feitelijk een dienst huurt.
Open standaarden zijn inderdaad een ander terrein, maar ook daar speelt hetzelfde spanningsveld: transparantie in definities versus marketingtaal. Mijn zorg is dat wanneer dit vaag blijft, de term “open” zijn waarde verliest, zowel voor juristen als voor engineers.
Naast de juridisch/technisch definitie van OSI zijn er nog de ideologische van een Free Software Foundation (FSF) en zo’n zeven anderen die de accenten net even anders leggen. Ik wees daaarom expliciet op de gedachte dat open source opgevat als het geheel van praktijken waarin de broncode kan worden gebruikt, bestudeerd, aangepast en verspreid vaak innovatiever is. Ook als de licenties niet strikt OSI-compatibel zijn. Open source gepresenteerd in hedendaagse discussie over soevereiniteit vraagt namelijk geen 100% OSI-compatibel licenties maar een groep mensen die verantwoordelijkheid neemt voor ontwikkeling en onderhoud. Een actieve gemeenschap die eigenaarschap en kennisdeling borgt gaat meer om de governance dan de licenties. Want open source gecombineerd met gesloten libraries is in de praktijk allang geen uitzondering meer.
waarden en opensource..
make opensource great again.
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
laat zien dat de (?) community (?) nog verdeelder is dan Europa.
“Customer collaboration over contract negotiation” wordt lastig als je elkaar niet vertrouwt.
Blijkbaar is werken met opensource ook niet zo agile.
Geen jurist zijn, maar er wel alles van moeten weten ?
Eigenaars borgen en kennisdeling borgen als eigenschappen van opensource ? Nu alleen nog er geld voor vragen 😛
De praktijk: Red Hat removed the “Shadowman” logo because it was perceived as “sinister, secretive, and sneaky” by many people, which contradicted the company’s values of openness and collaboration. The company underwent an “Open Brand Project” to modernize the logo and better reflect its identity as a leading open-source solutions provider
Als de leugen regeert, laat die explainable AI maar zitten straks.
Markt mechanisme impliceert perverse prikkels wat maakt dat het niet om de redelijkheid gaat maar om macht.
and you “opensource” don’t have the cards.
Niemand leest de voorwaarden omdat je voor de leesbaarheid ervan een jurist moet zijn. Ik las in de ‘shadowman’ van een logo daarom een hacktivistische onderstroom en vraag me af of de nu ‘gereguleerde rebel’ onder de hoed van IBM dat nog steeds is. En wat betreft het eigenaarschap wijs ik op de plotselinge veranderingen want eerder hadden we Oracle die met de overname van SUN opeens de eigenaar werd van JAVA en MySQL. Maar bovenal wil Dino niet ingaan op de vraag over de gesloten libraries bij 100% OSI compliant code die uiteindelijk een raakvlak hebben met open standaarden omdat ze de spelregels van toegang bepalen. Die spelregels zijn door geopolitieke omstandigheden de voorwaarden van gebruik als ik kijk naar minder efficiënte code door regulering om een brug naar soevereiniteit te slaan. Don’t have the card or don’t have the guts vanuit een hacktivistische onderstroom die soms tegen de stroom in gaat.
pff, ik zie door de licenties de code niet meer.
maar ja, dat is dan toch weer eenduidiger dan de reacties van oudlid.
zo zat er een vraag in verborgen ?
misschien is dit dan een overzichtelijk antwoord als de rendering het toelaat:
+———————-+—————————–+——————————-+
| License | Type | Can link with closed library? |
+———————-+—————————–+——————————-+
| MIT | Permissive | Yes, freely |
| BSD 2-Clause / 3-Clause | Permissive | Yes, freely |
| Apache 2.0 | Permissive with conditions | Yes, but must preserve notice |
| GPL v2 / GPL v3 | Strong copyleft | No, static linking usually |
| LGPL v2 / LGPL v3 | Weak copyleft | Yes, dynamic linking allowed |
| MPL 2.0 | Weak copyleft | Yes, under MPL conditions |
| EPL 2.0 | Weak copyleft | Yes, under EPL conditions |
+———————-+—————————–+——————————-+
maar ik mag mijn advocaat hier geen verdere uitspraken over doen.