Why CIOs Must Demand Ownership of Their AI Stack
CIOs can’t equate local hosting with ownership. Many “community” AI licenses restrict commercial use, transferability, or fork rights. True control requires OSI-approved licenses (with SPDX IDs) so AI can be transferred, audited, and treated as an asset.
Running locally ≠ owning it
More and more vendors publish their models as so-called community releases: you can download the weights, host them locally, and even fine-tune them, but the license includes clauses that conflict with the Open Source Initiative (OSI) definition of open source.
Meta’s Llama 3 Community License allows unlimited experimentation on your own hardware, but restricts commercial exploitation above a certain user threshold and says nothing about transferability in M&A. So the model may be physically on your servers, yet legally Meta still holds the keys.
RAIL licenses (Responsible AI licenses, used for example around Stable Diffusion) require every downstream user to comply with a revocable ethical policy. Again: you may host locally, but the right can still be withdrawn later.
SSPL or the Business Source License (MongoDB, HashiCorp) allows local operation, but requires any SaaS provider to release the entire codebase once it is offered commercially. A clause investors typically consider unacceptable.
For CIOs and CISOs the lesson is clear: technical autonomy is not enough. Control requires a license that explicitly permits transfer, unlimited commercial use, and fork rights, in other words, an OSI-approved license.
This article explains how IT leaders can recognize the difference between true open source, copyleft constructs, and “source-available” freeware, and why ownership is essential for strategic agility.
What is real open source?
The only universally accepted benchmark is approval by the Open Source Initiative. OSI uses 10 principles (freedom to use, distribute, create derivatives, non-discrimination by field of endeavor, etc.). Every license that passes this process gets an SPDX ID such as Apache-2.0, MIT, or GPL-3.0-only. If a license is not listed at opensource.org/licenses, then formally it is not open source.
Quick checklist
- Is the license on the OSI list? → yes/no
- Does the license have an official SPDX ID? → yes/no
(SPDX ID = Software Package Data Exchange Identifier = the exact open source license identifier) - Does the license contain competitive clauses (field-of-use restrictions, non-competes) or sector bans? → then it is by definition not OSI-compliant
If any of these answers is “no,” you are dealing with source-available or corporate freeware.
Copyleft versus permissive
Within the OSI universe there are two flavors:
Permissive (MIT, Apache 2.0, BSD)
- Free use, including in closed source
- No obligation to contribute modifications back
→ Ideal if you want independence and to build closed IP on top.
Copyleft (GPL, AGPL, LGPL)
- Requires derivative works to be shared under the same license
→ Encourages community contribution; limits integration into proprietary products.
For CIOs this matters in internal extensions: your own code may become “infected” if you statically link (GPL), but not necessarily for dynamic modules (LGPL).
If you operate a platform, you might deliberately choose copyleft to prevent others from creating vendor lock-in, but you must account for integration limitations in closed-source ecosystems.
Open washing in AI: Llama, RAIL & SSPL
Large model vendors increasingly position their licenses as “community” or “open,” while in practice they contain critical restrictions. Examples:
- Llama Community License: prohibits use by parties with more than 700M monthly active users and imposes a separate Acceptable Use Policy. Increasingly common are “modified” Apache 2.0 or MIT licenses: Modified with restrictions, and therefore no longer open source.
- RAIL (Responsible AI License): forces downstream users to comply with ethical rules, including a kill switch.
- SSPL / BSL (Server Side Public License, Business Source License): source code visible, but commercial SaaS operators must open their entire stack.
None of these licenses is on the OSI list. Anyone implementing them lives in an IP gray zone when it comes to transferability and due diligence.
Transferability: AI as a balance-sheet asset
More and more CFOs ask: “Can we capitalize our AI system as an intangible asset?” That only works if the underlying licenses allow legal transfer, a requirement under both IFRS 3 and ASC 805.
For transferability, there are three checkpoints:
- Technically restartable (carve-out ready)
- Extensive logging of versions, datasets, and fine-tunings
- Licenses free of transfer prohibitions
OSI-permissive licenses fit perfectly here; conditional terms do not.
If your system meets these conditions, it can be recognized as an asset on the balance sheet and valued cleanly during acquisitions.
A roadmap for CIOs
A. License due diligence
- Verify OSI approval + SPDX ID
- Have Legal check for usage restrictions, revenue share, non-transfer clauses
B. Contractual safeguards
- Require escrow or explicit self-hosting rights for tooling, prompts, or pipelines
- Specify that fine-tuned weights remain the property of your organization
C. Technical autonomy
Plan for a carve-out scenario: document build scripts, dependencies, and licenses so the complete model–logic–data package can run on new hardware within 24 hours, without relying on the original cloud or network environment.
D. Partner exit strategy
- Choose vendors offering permissive licenses
- Be cautious with “freemium” models that flip into BSL or SSPL after adoption
From hype to principle
AI in 2025 is what Linux was in 2005: the differentiating capability in the value chain. But only those who control the source code, weights, and license benefit sustainably.
The strategic choice:
- As-a-Service → speed, but continuous dependency
- Asset-based → higher upfront CAPEX and governance, but durable IP value and compliance control
Organizations that postpone freedom now will later pay multiples in exit costs, migration projects, and license renegotiations.
Conclusion
Open source is not a matter of emotion; it is legal specificity. For every AI offering, ask for the SPDX ID, check the OSI list, and test whether transfer is possible. Only then can organizations move from “renting AI” to “owning AI,” adding IP value, independence, and trust to their balance sheet.
Original article in Dutch
Redactie - 01 augustus 2025
