What does CADA open source mean for developers?

Summary As proposed in COM(2026) 502 final, the Cloud and AI Development Act (CADA) establishes a strategic preference for open source in the public sector. Article 41 requires Union entities and public sector bodies to "encourage" the use of open standards and components released under an open source licence when building their cloud and AI ecosystems, subject to security and cost justifications. Article 42 mandates that when these bodies release software for reuse, they must do so via a repository "connected to" the central EU Open Source Solutions Catalogue. For developers, this means a structural shift toward interoperable, well-documented code and a new, centralized discovery channel for public-sector software, provided it meets specific licensing and connectivity criteria defined in Article 2(25).

Detail

The proposed Cloud and AI Development Act (CADA) addresses the fragmentation of public sector software and the risk of vendor lock-in by embedding open source principles directly into the regulatory framework for cloud and AI. While the Act covers broad infrastructure and sovereignty issues, its provisions on open source (Title IV, Chapter V) offer specific, actionable obligations for public bodies that directly impact the software development lifecycle.

The "Open Source First" Policy Direction (Article 41)

Article 41 sets the tone for public procurement and software development within the EU cloud and AI ecosystem. It states that the Union and Member States shall take 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 provision is not an absolute ban on proprietary software. The text explicitly qualifies this encouragement by requiring that decisions take into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria." This creates a "presumption in favour" of open source. Public bodies must start with open source options and can only deviate if they can objectively demonstrate that a proprietary solution is necessary for security, cost-efficiency, or specific functional requirements.

For the development community, this signals a market shift. Public authorities are now legally compelled to evaluate open source solutions as the default. This increases the strategic value of robust, secure, and well-maintained open source projects that can serve as the foundational building blocks for public cloud and AI infrastructure. Developers who can demonstrate that their open source solutions meet high security standards and offer a lower total cost of ownership (TCO) than proprietary alternatives will find a more receptive market.

Centralised Discovery and Mandatory Connectivity (Article 42)

Article 42 addresses the "discoverability" problem that has long plagued public sector software. Currently, code developed by public bodies is often scattered across disconnected internal repositories, making it difficult for other entities or private developers to find and reuse.

The Article imposes a clear obligation: when a Union entity or public sector body makes software available for reuse under an open source licence, it "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 creates a mandatory technical linkage. It is not sufficient to simply publish code on a public GitHub or GitLab instance; the repository must be technically integrated or connected to the central EU Open Source Solutions Catalogue. This catalogue, established under Article 43, will be hosted on the Interoperable Europe portal and maintained by the Commission. It will serve as a single, free, and electronically accessible hub for all public sector software released for reuse.

The practical implication for developers is twofold:

For those consuming public code: Finding government-developed tools will become significantly easier, as the central catalogue will aggregate software from across the Union.
For those contributing to public code: If you are a developer working with a public body, you must ensure the release process includes depositing the code in a repository that meets the connectivity requirements of the EU OSS Catalogue. This may involve adopting specific metadata standards or API integrations to facilitate the connection.

Defining "Open Source" in CADA (Article 2(25))

To ensure legal certainty and avoid fragmentation, CADA does not invent a new definition of open source. Instead, Article 2(25) defines an "open source licence" by cross-referencing Article 2, point (12), of Regulation (EU) 2024/903 (the Interoperable Europe Act).

This definition aligns with the Open Source Definition (OSD), requiring that the licence allows for free redistribution, access to the source code, and the right to create derivative works. Crucially, this definition excludes licences that restrict commercial use, impose field-of-use restrictions, or fail to provide full source code access.

For developers, this means that the "open source" label in CADA is a legal term of art. Licences that are "source-available" but restrict commercial use (e.g., certain SSPL variants or dual-licensing models that block commercial competitors) may not qualify under Article 41 and 42. To benefit from the "open source first" preference and the mandatory reuse channels, the software must be released under a licence that meets the Interoperable Europe Act's criteria.

Practical Developer Guidance

Navigating the open source provisions of CADA requires a shift in strategy for developers, architects, and CTOs working in or with the public sector.

Prioritize Interoperability and Standards: Since Article 41 explicitly encourages "open standards," developers should ensure their projects adhere to widely recognized technical standards. This increases the likelihood that public sector bodies will adopt the software as part of their compliant stack. Projects that are "standard-compliant" will have a distinct advantage over those that rely on proprietary protocols.
Document Security and Total Cost: Because public bodies can justify proprietary alternatives based on security and cost, open source projects must provide clear, auditable documentation on security features, maintenance requirements, and total cost of ownership. Demonstrating that an open source solution is secure and cost-effective compared to proprietary alternatives strengthens its position under Article 41.
Prepare for Centralized Discovery: If you are developing software for or with public sector bodies, ensure that the release process includes depositing the code in a repository connected to the EU OSS Catalogue. This may require adopting specific metadata standards or repository structures that facilitate integration with the central catalogue. Do not assume that a public GitHub repository is sufficient; verify the connectivity requirements with the contracting authority.
Licence Choice Matters: Ensure that your chosen licence is recognized as an "open source licence" under the Interoperable Europe Act. Common permissive licences (MIT, Apache 2.0) and strong copyleft licences (GPL, AGPL) are generally accepted, but novel or restrictive licences may face scrutiny. If a licence does not meet the definition in Article 2(25), the software may not be eligible for the "open source first" preference or the mandatory reuse channels.

What this means for you

For CTOs and Architects, CADA represents a significant opportunity to influence the technical direction of public sector digital transformation. By aligning your organization's open source strategy with the "open source first" principle of Article 41, you can position your products as preferred solutions for government cloud and AI projects. However, you must also prepare for increased scrutiny on security and cost justifications, as public bodies will need to document why they are choosing your open source solution over proprietary alternatives.

For SMEs, the mandate to connect repositories to the EU OSS Catalogue (Article 42) lowers the barrier to market entry for innovative public sector tools. Instead of navigating complex procurement processes to get your software noticed, you can leverage the central catalogue for discoverability. This is particularly beneficial for niche or specialized tools that may have been overlooked in traditional procurement channels.

For Developers, the emphasis on open standards and interoperability means that contributing to or building projects that adhere to these standards will yield higher returns in the public sector market. Additionally, the requirement for connected repositories means that code quality, documentation, and metadata will be more visible than ever, raising the standard for what constitutes "production-ready" open source software in the EU public sector.

Common misconceptions

Misconception 1: CADA forces all public software to be open source. Correction: Article 41 encourages the use of open source but allows for exceptions based on security, cost, and functionality. It is a preference, not an absolute mandate. Public bodies can still use proprietary software if they can provide a duly justified objective reason.

Misconception 2: Any public repository qualifies for the EU OSS Catalogue. Correction: Article 42 requires that software be released via a catalogue or repository "connected to" the EU OSS Catalogue. This implies a technical integration or linkage, not just any public GitHub or GitLab account. The Commission will likely specify technical requirements for this connectivity via implementing acts.

Misconception 3: CADA defines its own open source licence. Correction: CADA does not create a new definition of open source. Article 2(25) references the Interoperable Europe Act, ensuring alignment with existing EU digital policies. This avoids fragmentation and ensures that widely accepted open source licences are recognized.

Misconception 4: Only large enterprises will benefit from CADA's open source provisions. Correction: On the contrary, SMEs and individual developers stand to gain significantly from the increased visibility and standardized procurement processes. The central catalogue and "open source first" preference reduce barriers to entry for smaller players with high-quality, interoperable solutions.

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