Summary Under the proposed Cloud and AI Development Act (CADA), both permissive licences (such as MIT, Apache 2.0 and BSD) and copyleft licences (such as the GPL family) would generally count as open source, because each grants the freedoms to use, study, modify and redistribute the software. CADA does not write its own definition: Article 2(25) defines "open source licence" by reference to Article 2, point (12), of Regulation (EU) 2024/903 — the Interoperable Europe Act. Source-available licences that restrict redistribution or field of use would typically fall outside that definition.
Detail
CADA anchors its open-source concept in existing EU interoperability law rather than creating a standalone test. The relevant provision is Article 2(25):
"'open source licence' means open source licence as defined in Article 2, point (12), of Regulation (EU) 2024/903."
Regulation (EU) 2024/903 is the Interoperable Europe Act (IEA). Its definition is not reproduced in the CADA corpus, so the precise wording should be read from that Regulation. In substance, an open-source licence under that framework is understood as one that grants users the freedom to use the software for any purpose, to study and adapt it, and to redistribute it (including modified versions) — the freedoms that characterise open-source software generally.
Why permissive and copyleft both fit
Because the test is about granting those freedoms rather than naming specific licences, both major families generally qualify:
- Permissive licences (MIT, Apache 2.0, BSD). They allow almost any use, including incorporation into proprietary software, subject to attribution and notice conditions. They grant the relevant freedoms and would be treated as open source.
- Copyleft licences (GNU GPL, AGPL, MPL). They require derivative works or redistributed copies to remain under the same terms. That is a condition on how you redistribute, not a removal of the freedom to redistribute — so they too would generally meet the definition.
The edge case: source-available is not the same as open source
A frequent point of confusion is the status of source-available licences with field-of-use restrictions — for example, licences that permit internal use but prohibit commercial resale or use by competitors. Where a licence restricts the freedom to use or redistribute the software, it would generally fail the open-source test the IEA definition embodies. Such software would not benefit from CADA's open-source-specific provisions.
Why the distinction matters for CADA
CADA would actively promote open source as a lever for technological sovereignty:
- Article 41 requires the Union and Member States to take measures encouraging Union entities and public sector bodies to use and facilitate the reuse of open standards and components released under an open source licence when building their cloud and AI ecosystem, taking into account functionality, security, total cost and other justified criteria.
- Article 42 provides that when a Union entity or public sector body makes software it owns available for reuse under an open source licence, it must do so via a catalogue or repository connected to, and accessible through, the EU Open Source Solutions Catalogue.
- Article 43 requires the Commission to provide and maintain that EU Open Source Solutions Catalogue, hosted on the Interoperable Europe portal and free of charge.
Software under a restrictive source-available licence falls outside this framework: it would not qualify for the open-source reuse mechanisms, and it could not be shared under the open-source provisions of Articles 41–43.
What this means for you
For CTOs, architects and SMEs:
1. Procurement and public-sector access. Public bodies would be encouraged to prioritise open source. Using a recognised permissive or copyleft licence keeps your software eligible for those preferences; a restrictive source-available licence may not.
2. The EU OSS Catalogue. If you are a public-sector developer (or contributing software a public body will reuse), Articles 42–43 require an open-source licence within the IEA meaning to use the catalogue route. A restrictive licence would keep your software out of it.
3. Supply-chain consistency. Open cloud computing stacks are supported under Article 4(2)(a). Keeping components under recognised open-source licences reduces licensing friction across the stack; note that even open-source software is subject to specific controls in Annex II (for example, Section 2.1(j) requires documented controls against remote features that could tamper with or disrupt the service).
4. Strategic licensing. If maximising EU public-sector adoption is the goal, recognised open-source licences are the safe path. Open-core or source-available models with commercial restrictions would generally not be classified as open source under CADA.
Common misconceptions
Misconception 1: "Copyleft isn't open source because it's restrictive." False. Copyleft imposes conditions on how you redistribute, not whether you can. It grants the core freedoms and would generally count as open source.
Misconception 2: "If I provide source code, it's open source." False. Providing source is necessary but not sufficient. The licence must grant the freedoms the IEA definition embodies. Source-available-but-restricted licences would generally not qualify.
Misconception 3: "CADA maintains its own list of approved licences." False. CADA defers to the IEA definition (Article 2(25)); it does not publish a whitelist. OSI approval is a strong practical signal, but the legal test is the IEA definition referenced by CADA.
Related
- Does an open-weight AI model under a restrictive licence count as open source under CADA?
- What is an open source licence under CADA?
- Which bodies count as contracting authorities for CADA procurement rules?
- Does my SaaS product count as a cloud computing service under CADA?
- Does my chatbot or automation count as an AI agent under CADA?
This is general information about a draft EU regulation, not legal advice.