Summary The proposed Cloud and AI Development Act (CADA) does not provide a standalone definition for "open source licence." Instead, Article 2(25) of the CADA proposal explicitly imports the definition from Article 2, point (12), of Regulation (EU) 2024/903 (the Interoperable Europe Act). Consequently, the legal meaning of an open source licence under CADA is entirely dependent on the criteria established in the Interoperable Europe Act, which focuses on the freedom to use, study, modify, and distribute software and components without restrictive conditions. This cross-reference ensures legal consistency across the EU's digital acquis and prevents fragmentation in how public sector bodies interpret open-source obligations.
Detail
The Cloud and AI Development Act (CADA), proposed by the European Commission on 3 June 2026 (COM(2026) 502 final), establishes a comprehensive framework for strengthening Europe's cloud and AI ecosystem. A central pillar of this framework is the promotion of open-source technologies to enhance technological sovereignty, security, and interoperability. To achieve this, CADA mandates that Union entities and public sector bodies encourage the use of open standards and components released under open source licences (Article 41).
However, the CADA proposal itself does not contain an original, self-contained definition of the term "open source licence." This is a deliberate legislative drafting choice to ensure alignment with existing EU digital policy. Specifically, Article 2(25) of the CADA proposal 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. By referencing this regulation, the CADA proposal ensures that the definition of open source remains consistent across different EU digital initiatives, avoiding the risk of contradictory standards emerging in different legislative silos. The definition in the Interoperable Europe Act generally aligns with established international open-source standards, requiring that the licence allows users to freely access, use, modify, and redistribute the software or data, including modified versions, without undue restriction.
This legislative technique serves two primary purposes. First, it avoids redundancy and potential contradictions between different EU regulations governing digital infrastructure. Second, it leverages the specific policy goals of the Interoperable Europe Act, which aims to ensure that public sector digital solutions are interoperable and not locked into proprietary vendor ecosystems. The Interoperable Europe Act was designed to foster a common digital space, and by importing its definition, CADA ensures that the "open source" it promotes is the same "open source" that underpins the EU's broader interoperability strategy.
For in-house counsel and compliance officers, this cross-reference is critical. It means that when assessing whether a software component qualifies as "open source" for the purposes of CADA complianceβsuch as for the mandatory sharing of software developed by public bodies under Article 42 or for inclusion in the EU Open Source Solutions Catalogue under Article 43βyou must look to the criteria set forth in the Interoperable Europe Act, not just general industry definitions like the Open Source Initiative (OSI) definition, although they are closely aligned.
The CADA proposal emphasizes open source as a lever for sovereignty. Recital 81 of the CADA explanatory memorandum notes that access to source code enables auditability, fosters collaboration, and reduces dependency on a single vendor. Therefore, the precise legal definition matters significantly for determining which assets must be made available for reuse and which procurement preferences apply. The definition in the Interoperable Europe Act is the sole legal benchmark for CADA compliance regarding open-source licensing.
What this means for you
For in-house counsel and compliance officers within Union entities or public sector bodies, the reliance on the Interoperable Europe Act definition has several practical implications for compliance strategies, particularly regarding Articles 41, 42, and 43 of the CADA proposal.
1. Verification of Licence Status When your organization develops or commissions software, you must verify that the licence used meets the definition in Article 2(12) of Regulation (EU) 2024/903. If a licence restricts the ability to modify or redistribute the code, it may not qualify as an "open source licence" under CADA. This affects your ability to:
- Share and Reuse: Article 42 requires that when you make software available for reuse under an open source licence, you must do so via a catalogue connected to the EU Open Source Solutions Catalogue. If your licence does not meet the statutory definition imported from the Interoperable Europe Act, you cannot claim compliance with this sharing obligation.
- Procurement Preferences: Article 41 encourages the use of open-source components. Compliance officers should ensure that procurement specifications clearly define "open source" according to the Interoperable Europe Act to avoid ambiguity in vendor bids. Relying on a vendor's self-declaration of "open source" without verifying it against the Interoperable Europe Act definition could lead to non-compliance.
2. Catalogue Integration Article 43 establishes the EU Open Source Solutions Catalogue, hosted on the Interoperable Europe portal. Public sector bodies must connect their internal repositories to this central catalogue if they hold intellectual property rights to software they wish to share. Your IT and legal teams must ensure that the metadata associated with each software release accurately reflects its licence type according to the referenced definition. Misclassification could lead to non-compliance with the transparency and reuse obligations. The catalogue is designed to be a centralised access point, and its integrity depends on the accurate application of the Interoperable Europe Act definition.
3. Risk Management and Auditability The CADA proposal links open source to security and sovereignty. By using licences that meet the Article 2(25) definition, you ensure that the source code is accessible for audit. This is crucial for the "Union assurance levels" framework (Articles 16β24), where auditability of software supply chains is a key criterion for higher assurance levels. Compliance officers should document how the use of open-source components (as defined by the Interoperable Europe Act) contributes to the security and sovereignty assessments required for cloud services. The ability to audit the code is a direct consequence of the licence granting the necessary freedoms.
4. Deadlines and Reporting While the CADA proposal is still in the legislative procedure, the requirement to adopt national strategies (Article 7) and establish Open Source Programme Offices (Article 44) suggests a timeline for implementation. Member States must establish national cloud and AI strategies within one year of the regulation's entry into force. These strategies should include measures to support open-source development. Compliance teams should begin mapping their current software assets against the Interoperable Europe Act definition to prepare for future reporting and catalogue integration requirements. The definition serves as the baseline for all future national strategies and reporting mechanisms.
Common misconceptions
Misconception 1: CADA defines "open source" using the Open Source Initiative (OSI) definition. While the EU's approach is aligned with the OSI definition, CADA does not explicitly cite the OSI. It cites Article 2(12) of Regulation (EU) 2024/903. Compliance officers should not assume that any licence approved by the OSI automatically satisfies the CADA definition without verifying that it also meets the specific wording of the Interoperable Europe Act, although in practice, they are nearly identical. The legal obligation is to the text of the Interoperable Europe Act, not the OSI list.
Misconception 2: "Open source" only applies to software code. The Interoperable Europe Act, and by extension CADA, covers "components," which can include data and other digital assets. Article 2(25) of CADA refers to the broader definition in the Interoperable Europe Act, which may encompass more than just traditional software code. Compliance teams should review data licensing agreements to ensure they meet the open-source criteria if they intend to share data sets under CADA's reuse provisions. The definition is technology-agnostic in its application to digital components.
Misconception 3: Using an open-source licence exempts you from all CADA obligations. Using an open-source licence does not exempt a provider from the cybersecurity, sovereignty, or auditing requirements of CADA. In fact, for Union assurance levels 2, 3, and 4 (Annex II of CADA), providers must demonstrate specific controls over open-source components, such as preventing remote tampering and ensuring supply chain transparency. The licence defines the rights of use, but CADA imposes additional operational and security obligations on how those components are managed and audited. The definition of the licence is just the starting point for a broader compliance regime.
Related
- Who must promote open source under CADA? Article 41 explained
- CADA Article 42: What happens if a public body shares open source software outside the EU OSS Catalogue?
- CADA Open Source for Developers: Licence Selection and Reuse Rules
- What criteria can a public body use to NOT choose open source under Article 41?
- Is open source mandatory under CADA? Article 41 explained
This is general information about a draft EU regulation, not legal advice.