Summary Under the proposed Cloud and AI Development Act (CADA), the term "open source licence" is not defined in isolation but by explicit reference to the Interoperable Europe Act (Regulation (EU) 2024/903). Specifically, Article 2(25) of CADA defers to Article 2, point (12) of that Regulation. As proposed, a licence qualifies only if it grants the freedoms to use, study, modify, and redistribute the software without discrimination. This aligns with standard Open Source Initiative (OSI) criteria. Consequently, licences such as the EUPL, MIT, Apache 2.0, and GPL variants would count, while "source-available" licences that restrict commercial use, modification, or redistribution would not qualify.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, treats open source not merely as a development methodology but as a strategic lever for technological sovereignty. To ensure legal certainty and harmonisation across the Union, the proposal avoids creating a bespoke definition of "open source." Instead, it anchors the definition in existing EU law.

The Legal Definition: Article 2(25) and the Interoperable Europe Act

The definitive source for what constitutes an open source licence under CADA is Article 2(25) of the proposal. This article states:

"'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. Its definition in Article 2(12) establishes the functional criteria for a licence to be considered "open source." While the full text of the Interoperable Europe Act is not reproduced in the CADA proposal, the definition it incorporates is well-established in EU digital policy and aligns with the Open Source Definition (OSD).

For a licence to satisfy CADA's requirements, it must, as proposed, guarantee the following core freedoms:

  1. Free Use: The software can be used for any purpose, including commercial and research activities.
  2. Access to Source Code: The source code must be available, and the licence must allow distribution in source code form.
  3. Modification and Derived Works: Users must be permitted to modify the software and distribute derived works.
  4. No Discrimination: The licence must not discriminate against any person, group, or field of endeavour (e.g., it cannot forbid use in business, military, or specific industries).
  5. Technology Neutrality: The licence must not be tied to a specific distribution mechanism or technology.

This definition effectively excludes "source-available" licences that grant access to the code but restrict how it can be used or modified.

Which Licences Count as Open Source?

Based on the definition in the Interoperable Europe Act, the following categories of licences would be recognised as open source under CADA:

1. Permissive Licences

These licences impose minimal restrictions, allowing the software to be used, modified, and redistributed, often with only an attribution requirement. They are fully compliant with CADA's definition.

  • MIT Licence: Widely used for its simplicity and permissiveness.
  • Apache Licence 2.0: Includes an express grant of patent rights from contributors to users, ensuring legal clarity for commercial adoption.
  • BSD Licences (2-Clause and 3-Clause): Allow free use with minimal attribution requirements and no copyleft obligations.

2. Copyleft (Strong and Weak) Licences

These licences require that modified versions of the software be distributed under the same licence terms (or compatible terms), ensuring that improvements remain open.

  • GNU General Public Licence (GPL): Including GPLv2 and GPLv3. These are fully compliant as they allow modification and redistribution, provided the derivative works remain open.
  • GNU Lesser General Public Licence (LGPL): A weaker copyleft licence designed for software libraries, allowing linking with proprietary software under specific conditions.
  • Mozilla Public Licence 2.0 (MPL 2.0): A file-level copyleft licence that balances openness with flexibility.

3. The European Union Public Licence (EUPL)

The EUPL holds a special status in the context of CADA.

  • Explicit Alignment: The EUPL was explicitly designed to comply with the legal frameworks of the European Union and is fully compatible with the definition in the Interoperable Europe Act.
  • Public Sector Preference: CADA promotes the use of open standards and components released under open source licences. The EUPL is often the preferred choice for public sector software developed in the EU because it is multilingual, legally robust across Member States, and compatible with major copyleft licences like the GPL.
  • Interoperability: The EUPL facilitates the sharing and reuse of software across Union entities and public sector bodies, directly supporting the objectives of Article 42 of CADA.

Which Licences Do NOT Count?

Licences that restrict the rights defined in the Interoperable Europe Act do not qualify as open source under CADA. These include:

  • Source-Available Licences: Licences that provide source code but restrict commercial use, modification, or redistribution. Examples include the Business Source Licence (BSL) or certain Common Public Attribution Licences (CPAL) if they impose usage restrictions that violate the "no discrimination" principle.
  • Restrictive Open Core Licences: If a product is "open core," the proprietary portion is not open source. However, the open subset may qualify if it meets the definition independently.
  • Licences with Discriminatory Clauses: Any licence that prohibits use by specific groups, countries, or industries (e.g., "non-military use only" or "no use by competitors") would fail the CADA test.

CADA's Strategic Promotion of Open Source

Beyond mere definition, CADA actively mandates the promotion of open source to reduce dependency on third-country providers and enhance sovereignty.

Article 41 of the proposal states:

"The Union and Member States shall take the necessary measures to encourage 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 or stack..."

This article establishes a policy preference for open source in public procurement and infrastructure development. It is not a ban on proprietary software, but a directive to prioritise open source where feasible to ensure auditability, security, and interoperability.

Furthermore, Article 42 creates a mechanism for reuse:

"When making software to which they hold intellectual property rights available for reuse under an open source licence, a Union entity or public sector body shall do so using a catalogue or repository that is connected to, and made accessible through, the EU OSS Catalogue..."

This creates a centralised ecosystem (Article 43) where compliant open source software is discoverable, ensuring that the "open source" label under CADA translates into actual, usable assets for the public sector.

What this means for you

For CTOs, architects, developers, and SMEs, the implications of CADA's open source definition are practical and strategic:

  1. Audit Your Licence Stack: If you are a cloud provider, AI developer, or public sector body, you must verify that the software you rely on is licensed under a recognised open source licence (e.g., MIT, Apache 2.0, GPL, EUPL). If you are using "source-available" software with restrictive clauses, you may face compliance issues if you intend to participate in public procurement or benefit from CADA's support measures.
  2. Prefer EUPL for Public Sector Projects: If you are developing software for public sector bodies or participating in EU-funded projects, consider using the EUPL. It is fully compliant with CADA and the Interoperable Europe Act, and it is designed to integrate seamlessly with EU public sector requirements, reducing legal friction.
  3. Contribute to the Ecosystem: CADA encourages the sharing and reuse of software. By releasing your own tools or components under a recognised open source licence, you can contribute to the EU's technological sovereignty and potentially access new markets through the EU OSS Catalogue.
  4. Avoid Vendor Lock-in: CADA's promotion of open source is linked to reducing dependency on third-country providers. By adopting open source standards and licences, you enhance your ability to switch providers and maintain control over your digital infrastructure, aligning with the sovereignty goals of Article 16.

Common misconceptions

  • "Open Source means Free of Charge": While open source software is often free, the definition under CADA (via the Interoperable Europe Act) focuses on freedoms (use, modify, distribute) rather than price. You can sell open source software, and you can charge for support or hosting.
  • "All Licences with Source Code are Open Source": Providing source code is not enough. If the licence restricts modification or commercial use, it is not open source under CADA. "Source-available" licences are distinct from open source.
  • "CADA Bans Proprietary Software": CADA does not ban proprietary software. It encourages the use of open source, particularly in the public sector, and sets out criteria for sovereign cloud services. Proprietary software can still be used, but it may face higher scrutiny in public procurement and must meet specific sovereignty assurance levels.
  • "I Can Ignore Licence Compliance": Even under CADA, you must comply with the terms of the open source licence you use. Failure to comply (e.g., not providing source code for GPL-licensed software) can lead to legal risks and disqualification from public procurement processes.

Related

This is general information about a draft EU regulation, not legal advice.