Summary As proposed, the Cloud and AI Development Act (CADA) distinguishes sharply between the software developed by public bodies and the cloud infrastructure hosting it. The open-source obligations in Title IV apply specifically to software to which Union entities and public sector bodies hold intellectual property rights, requiring such software to be published in a connected catalogue. Article 41 encourages the use of open-source components when "building their cloud and AI ecosystem or stack," but this is a strategic preference for public authorities, not a mandate for commercial cloud providers to open-source their core services. Therefore, the rules target the code you build or commission, not the underlying cloud platform.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a specific "open source first" framework within Title IV. However, a precise reading of the text reveals that these obligations are narrowly scoped to software developed by or for the public sector, rather than the underlying cloud infrastructure, hardware, or commercial cloud services themselves. The legislation creates a two-tier approach: a strategic encouragement for ecosystem building and a mandatory publication rule for reusable software.

Article 41: The "Open Source First" Principle for Ecosystems

Article 41, titled "Promoting open source solutions and open source first," establishes the overarching policy direction for the Union and Member States. It mandates that authorities "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."

The phrasing "building their cloud and AI ecosystem or stack" is critical. It implies that when public sector bodies design, procure, or develop their digital infrastructure, they should prioritize solutions that allow for transparency, auditability, and vendor independence. The article explicitly states that this choice must take into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria."

Crucially, Article 41 does not impose a mandatory ban on proprietary cloud services or require cloud providers to release their infrastructure code. Instead, it creates a preference for open-source components within the layers of the stack that public authorities control or develop. This applies to the software layersβ€”such as middleware, application logic, management tools, and AI modelsβ€”rather than the physical hardware, the virtualization layer, or the core platform services provided by a third-party cloud provider. The provision is a directive to public buyers and developers to favor open standards when constructing their own digital assets.

Article 42: The Specific Obligation on Software

While Article 41 sets the strategic direction, Article 42 provides the concrete operational rule with a defined scope. It states: "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 referred to in Article 43."

This article clarifies the scope significantly through three limiting conditions:

  1. It applies to software: The subject of the obligation is explicitly "software," defined in the regulation as per Regulation (EU) 2024/2847. It does not extend to the cloud service itself, the data centre infrastructure, or the network layer.
  2. It applies to IP holders: The obligation triggers only when a public body holds the "intellectual property rights" to the software. If a public body merely licenses software from a vendor without owning the IP, this specific publication mandate does not apply to that vendor's code.
  3. It applies to reuse: The duty arises only when that software is "made available for reuse." Internal tools that are not shared or made available for reuse by other entities may not fall under this specific publication requirement, though the broader encouragement of open standards in Article 41 still applies.

This means that if a public sector entity commissions the development of a custom application, an AI model wrapper, or a specific data processing tool, and it owns the IP, it must publish that code in a repository connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue). However, this does not extend to the commercial cloud services themselves. A public body using a proprietary cloud platform from a third-country or EU provider is not required to open-source the cloud provider's underlying infrastructure code.

The Role of the EU OSS Catalogue (Article 43)

To support Article 42, Article 43 mandates the Commission to provide and maintain the EU OSS Catalogue. This catalogue serves as a centralized hub for software made available for reuse by Union entities and public sector bodies. It is hosted on the Interoperable Europe portal. The requirement is that any national or local catalogue used by a public body must be connected to this central EU catalogue. This ensures discoverability and prevents fragmentation, allowing other public bodies to find and reuse previously developed open-source solutions, thereby fostering a shared European digital commons.

Distinction from Cloud Service Providers

It is vital to distinguish between the users of cloud services (public sector bodies) and the providers of those services. CADA's Title IV focuses on the public sector's internal development and procurement practices. It does not impose direct open-source mandates on commercial cloud computing service providers (CCSPs) regarding their core service offerings.

However, the broader CADA framework, particularly the sovereignty framework in Title IV (Articles 16-24), indirectly influences cloud providers. To achieve higher Union assurance levels (especially Level 3 and 4), providers must demonstrate control over their software supply chains. Under Annex II, providers must provide a complete Software Bill of Materials (SBOM) and ensure no remote tampering features exist. While this requires transparency and auditability of the code to satisfy auditors, it does not equate to a requirement to release that code under an open-source licence. The sovereignty framework demands visibility into the supply chain, whereas the open-source provisions demand publication of public-sector IP.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the distinction between software and cloud services is critical for compliance and strategy.

For Public Sector CTOs and Architects:

  • Audit Your IP: Identify all software projects where your entity holds the intellectual property rights. If you plan to make this software available for reuse, you must prepare to publish it in a repository connected to the EU OSS Catalogue.
  • Adopt Open Standards: When designing new cloud or AI ecosystems, prioritize open standards and open-source components. This is not just a legal nudge but a strategic move to reduce vendor lock-in and increase interoperability, which aligns with the "AI first" and sovereignty goals of CADA.
  • Catalogue Integration: Ensure your internal software repositories are technically capable of syncing with the EU OSS Catalogue. This may require updates to your DevOps pipelines to automate metadata tagging and publication.

For SMEs and Cloud Providers:

  • No Direct Open-Source Mandate for Core Services: You are not required to open-source your core cloud infrastructure or proprietary cloud service code to comply with Articles 41-42. Your obligation remains focused on transparency (SBOMs) and sovereignty criteria if you seek to serve the public sector at higher assurance levels.
  • Opportunity in Open Source: SMEs that provide open-source components, middleware, or AI tools are well-positioned to benefit from the increased public sector demand for such solutions. The "open source first" principle creates a favorable market environment for vendors who offer transparent, auditable, and interoperable technologies.
  • Supply Chain Transparency: While you don't need to open-source your code, higher assurance levels under CADA's sovereignty framework will require you to provide detailed SBOMs and evidence of code integrity. Ensure your development processes can generate this documentation efficiently.

Common misconceptions

Misconception 1: CADA forces all cloud providers to open-source their code. This is incorrect. CADA's open-source provisions (Articles 41-44) apply to Union entities and public sector bodies regarding the software they develop or commission. Commercial cloud providers are subject to sovereignty and security audits, which require transparency into their code (e.g., for vulnerability scanning), but not necessarily the public release of that code under an open-source licence.

Misconception 2: "Open Source First" means proprietary software is banned. Article 41 encourages the use of open-source components but explicitly allows for the use of other solutions if justified by objective criteria such as security, total cost, or functionality. It is a preference, not an absolute prohibition.

Misconception 3: The rules apply to all software used by the public sector. The obligation to publish in the EU OSS Catalogue (Article 42) only applies to software made available for reuse by the public body. Internal tools that are not shared or reused outside the specific entity may not fall under this specific publication requirement, though the broader encouragement of open standards still applies.

Official sources

Related

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