Waarom CIO’s eigenaarschap moeten eisen over hun AI-stack
Steeds vaker publiceren leveranciers hun modellen als zogenoemde community releases: je kunt de gewichten downloaden, lokaal hosten en zelfs finetunen, maar de licentie bevat clausules die haaks staan op de open-sourcedefinitie van de OSI zo schrijft Bart van Maarseveen, CEO van Outpacr.

Llama 3 Community License laat onbeperkt experimenteren op eigen hardware toe, maar verbiedt commerciële exploitatie boven een gebruikersdrempel én regelt niets over overdraagbaarheid bij M&A. Het model staat dus fysiek bij jou, maar juridisch blijft Meta aan de knoppen zitten.
RAIL-licenties (De Responsible AI licentie zoals o.a. bij Stable Diffusion) verplichten iedere downstream-gebruiker zich aan een intrekbare ethische policy te houden. Ook hier geldt: lokaal hosten mag, maar het recht kan later alsnog worden ingetrokken.
SSPL of Business Source License (MongoDB, HashiCorp) laat lokaal draaien toe, maar eist dat een SaaS-provider de volledige codebase vrijgeeft zodra hij het commercieel aanbiedt, een clausule die investeerders doorgaans onacceptabel vinden.
Voor CIO’s en CISO’s is de les helder: technische autonomie is niet genoeg. Controle vereist een licentie die overdracht, onbeperkt commercieel gebruik en fork-rechten expliciet toestaat, kortom een door de OSI goedgekeurde licentie.
Dit artikel schetst hoe IT-leiders het verschil herkennen tussen échte open source, copyleft-constructies, en “source-available” freeware, en waarom eigenaarschap cruciaal is voor strategische wendbaarheid.
Wat is écht open source?
De enige universeel geaccepteerde maatstaf is goedkeuring door de Open Source Initiative. OSI hanteert 10 principes (vrijheid van gebruik, distributie, afgeleide werken, sectorneutraliteit, etc.). Iedere licentie die door die ballotage komt, krijgt een SPDX-ID zoals Apache-2.0, MIT of GPL-3.0-only. Staat een licentie niet op https://opensource.org/licenses, dan is hij formeel géén open source.
Snelle checklist
- Staat de licentie op de OSI-lijst? → ja/nee
- Heeft de licentie een officiële SPDX-ID? → ja/nee. (SPDX-ID = Software Package Data Exchange Identifier = de exacte open source licentie)
- Bevat de licentie wedstrijdbepalingen (field-of-use restrictions en non-compete) of sectorverboden? → dan is het per definitie niet OSI-compliant
Wordt op één van deze vragen “nee” geantwoord, dan spreken we van source-available of corporate freeware.
Copyleft versus permissief
Binnen het OSI-universum bestaan twee smaken:
Permissief (MIT, Apache 2.0, BSD):
Vrij gebruik, ook in closed source.
Geen verplichting om aanpassingen terug te geven.
→Ideaal als je onafhankelijkheid wilt én closed IP erbovenop bouwt.
Copyleft (GPL, AGPL, LGPL):
Verplicht afgeleide werken onder dezelfde licentie te delen.
→ Bevordert community-teruglevering; beperkt integratie in proprietary producten.
Voor CIO’s relevant bij in-house uitbreidingen: eigen code wordt besmet als je statisch linkt (GPL), maar niet per se bij dynamische modules (LGPL).
Wie een platform aanbiedt, kan bewust voor copyleft kiezen om vendor lock-in van anderen te voorkomen, maar moet rekening houden met integratiebeperkingen in closed source ecosystemen.
Open washing in AI: Llama, RAIL & SSPL
Grote modelleveranciers positioneren hun licenties als ‘community’ of ‘open’ terwijl ze in feite kritieke restricties bevatten. Voorbeelden:
Llama Community License; verbiedt gebruik door partijen met > 700 M actieve gebruikers en legt een aparte Acceptable Use Policy op. Sterk in opkomst zijn de ‘modified version’ Apache 2.0 of MIT licenses. Modified met restricties en dus niet meer open source. [https://opensource.org/blog/metas-llama-2-license-is-not-open-source]
RAIL (Responsible AI Licence); verplicht downstream gebruikers zich aan ethische regels te houden, inclusief kill-switch.
SSPL / BSL (Server Side Public License, Business Source License); broncode zichtbaar, maar commerciële SaaS-operatoren moeten hele stack openstellen.
Geen van deze licenties staat op de OSI-lijst. Wie ze implementeert, leeft in een grijs gebied qua IP-overdracht en due-diligence.
Transferability: AI als balanspost
Steeds meer CFO’s vragen: “Kunnen wij ons AI-systeem activeren als immaterieel actief?” Dat kan alleen als de onderliggende licensties juridische overdraagbaarheid toestaan, een vereiste in zowel IFRS 3 als ASC 805. Voor overdraagbaarheid gelden drie checkpunten:
Technisch restartable (carve out), extensieve logging van versies, datasets en fine-tunings en licenties die vrij zijn van overdracht-verboden. OSI-permissive licenses passen hier perfect in; voorwaardelijke termen niet.
Voldoet je systeem k aan deze voorwaarden, dan kan hij als actief op de balans en bij overnames netjes worden gewaardeerd.
Roadmap voor CIO’s
A. Licentie-due-diligence
Verifieer OSI-goedkeuring + SPDX-ID
Laat Legal checken op gebruiksbeperkingen, revenue-share, non-transfer
B. Contractuele borging
Eis escrow of self-hosting-recht in de overeenkomst op de tooling, prompts of pipelines
Leg vast dat fine-tuning weights eigendom van jouw organisatie blijven
C. Technische autonomie
Voorzie in een carve-out-scenario: documenteer build-scripts, dependencies en licenties zó, dat het complete model–logic–data-pakket binnen 24 uur op nieuwe hardware kan draaien, zonder afhankelijk te zijn van de oorspronkelijke cloud- of netwerkomgeving.
D. Exit-strategie met partners
Kies vendors die permissieve licenties aanbieden
Wees terughoudend met ‘freemium’ modellen die na adoptie omslaan in BSL of SSPL
Van hype naar principe
AI is in 2025 wat Linux was in 2005: hét differentiërende vermogen in de value chain. Maar alleen wie de broncode, weights én licentie in eigen hand heeft, profiteert duurzaam. De keuze is strategisch:
As-a-Service → snelheid, maar continue afhankelijkheid.
Asset-gebaseerd → hogere initieel CAPEX en governance, maar blijvende IP-waarde en compliance-controle.
Bedrijven die vrijheid nu uitstellen, betalen straks een meervoud in exit-kosten, migratie-projecten en licentie-heronderhandelingen.
Conclusie
Open source is geen kwestie van emotie, maar van juridische specificiteit. Vraag bij elke AI-aanbieding om het SPDX-ID, check de OSI-lijst, en toets of overdracht mogelijk is. Pas dan kunnen organisaties de stap zetten van “AI huren” naar “AI bezitten” en daarmee IP-waarde, onafhankelijkheid en vertrouwen aan hun balans toevoegen
Bart van Maarseveen is CEO van Outpacr