How should a public body release software for reuse under CADA?

Under the proposed Cloud and AI Development Act (CADA), Union entities and public sector bodies that voluntarily choose to make software available for reus

Summary Under the proposed Cloud and AI Development Act (CADA), Union entities and public sector bodies that voluntarily choose to make software available for reuse must do so under an open source licence and via a catalogue or repository connected to the EU Open Source Solutions Catalogue (Article 42). This is not a blanket mandate to open-source all software, but a strict harmonisation of how software is released when the decision is made to do so. The goal, as stated in Recital 83, is to overcome fragmentation where software is "made available and accessible in different repositories or catalogues, hampering searchability, discoverability and, ultimately, reuse." By linking to the central hub hosted on the Interoperable Europe portal, public bodies would maximise the value of public expenditure, reduce duplication, and strengthen the Union's digital autonomy.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a specific legal framework for the sharing and reuse of software developed by or for the public sector. While the decision to release software remains voluntary or driven by national policy, the mechanism for release is harmonised at the Union level to ensure interoperability and discoverability.

The Core Obligation: Article 42

Article 42 establishes the mandatory pathway for software reuse. The text is precise:

"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 provision creates a two-part condition for compliance:

Licence Requirement: The software must be released under an open source licence. This ensures that the software is free to run, study, share, and modify, aligning with the EU's broader strategy to foster innovation and reduce vendor lock-in.
Connectivity Requirement: The software cannot be hosted in isolation. It must be placed in a catalogue or repository that is technically and semantically connected to the EU OSS Catalogue. A simple public GitHub repository or an internal server, unless connected to this central hub, would not satisfy the proposal's requirements.

The scope of this obligation is limited to software to which the public body holds intellectual property rights. If the software was developed by a third-party contractor, the public body must ensure that the contract grants it the necessary rights to release the software under these conditions.

The Central Hub: Article 43 and the EU OSS Catalogue

Article 43 mandates the European Commission to provide and maintain the EU Open Source Solutions Catalogue (EU OSS Catalogue). This serves as the single point of entry for the Union's public sector software ecosystem.

Key characteristics of the EU OSS Catalogue, as defined in the proposal, include:

Centralisation: It aggregates software from Union entities and public sector bodies across all Member States, creating a unified search interface.
Hosting Location: The catalogue is hosted on the Interoperable Europe portal, ensuring alignment with the Interoperable Europe Act (Regulation (EU) 2024/903) and existing EU interoperability standards.
Accessibility: It is accessible electronically free of charge for any public administration or user.
Connection Mechanism: The Commission decides, based on objective and relevant criteria, whether a national or entity-specific catalogue or repository can be connected to the central EU OSS Catalogue. This ensures that only repositories meeting specific technical and metadata standards are federated.

Policy Context: Recital 83

Recital 83 of the explanatory memorandum provides the critical context for why Article 42 exists. It observes that while an increasing number of Union entities and public sector bodies are sharing software under open-source licences, this software is often "made available and accessible in different repositories or catalogues, hampering searchability, discoverability and, ultimately, reuse."

The proposal aims to solve this fragmentation by creating a "one-stop-shop." The policy objectives driving this requirement are:

Maximising Public Value: By making software easily discoverable across borders, the EU would reduce the duplication of effort and development costs. A solution developed in one Member State could be readily adopted by another.
Fostering Innovation: A larger, centralised pool of reusable, high-quality open-source software would accelerate innovation in the public sector.
Supporting Interoperability: Hosting the catalogue on the Interoperable Europe portal ensures that solutions are linked to further relevant information and training, directly supporting the goals of the Interoperable Europe Act.

Practical Steps for Public Bodies

For public-sector procurement officers, IT managers, and policy makers, implementing Article 42 involves a structured process. As CADA is a proposal, these steps represent the future compliance path once the regulation enters into force.

1. Assess Intellectual Property Rights

Before any release, the public body must confirm it holds the necessary intellectual property rights.

Internal Development: If the software was developed by civil servants, the body likely holds the rights.
Contracted Development: If a third-party contractor developed the software, the public body must verify that the contract includes clauses allowing for open-source release. If the contractor retains exclusive rights, the body cannot unilaterally release the software under Article 42 without renegotiating the contract or obtaining a licence.

2. Select an Open Source Licence

The public body must choose a recognised open source licence. While CADA does not prescribe a specific licence, the choice should consider:

Compatibility: Does the licence work with the existing software stack?
Copyleft vs. Permissive: Does the body want to ensure derivatives remain open (e.g., GPL) or allow proprietary integration (e.g., MIT, Apache 2.0)?
Standardisation: Using standard, widely accepted licences facilitates easier adoption by other public bodies.

3. Prepare the Software for Release

The software must be "clean" and ready for public consumption.

Sanitisation: Remove all sensitive data, security vulnerabilities, and proprietary secrets not covered by the IP rights.
Documentation: Include a README file, the full text of the chosen licence, and contribution guidelines.
Metadata: Tag the software with appropriate keywords, descriptions, and technical specifications to ensure it is "findable" in the central catalogue.

4. Host in a Connected Repository

This is the critical compliance step. The software must be uploaded to a catalogue or repository that is connected to the EU OSS Catalogue.

National Repositories: If the Member State already operates a national repository connected to the EU OSS Catalogue, the software should be hosted there.
Establishing Connection: If the national repository is not yet connected, the public body must work with its national Open Source Programme Office (OSPO) to establish the technical connection. The Commission will decide on the connection based on objective criteria.
Isolated Hosting: Simply hosting code on a public GitHub or GitLab instance without a connection to the EU OSS Catalogue would not satisfy Article 42.

5. Ongoing Maintenance and Governance

While CADA focuses on the act of release, the sustainability of open-source projects often depends on continued maintenance. Public bodies should consider:

Community Support: Encouraging community contributions.
Official Maintenance: Designating internal teams or contractors to maintain the code.
OSPO Engagement: Utilising the network of Open Source Programme Offices established under Article 44 for guidance on licence selection, compliance, and best practices.

The Role of Open Source Programme Offices (OSPOs)

Article 44 establishes a network of Open Source Programme Offices (OSPOs) to facilitate cooperation on the implementation of these obligations. Public bodies are encouraged to engage with their national or local OSPO to:

Receive guidance on licence selection and legal compliance.
Ensure their repositories meet the technical criteria for connection to the EU OSS Catalogue.
Share best practices on software reuse and open-source governance across the Union.

What this means for you

For public-sector procurement officers, IT managers, and policy makers, Article 42 transforms software reuse from an ad-hoc activity into a structured, EU-wide process.

For Procurement Officers: When drafting contracts with software developers, you must include clauses that allow for the future open-source release of the developed software, provided it is not commercially sensitive. This future-proofs your procurement against CADA requirements and maximises the return on public investment. Without these clauses, you may hold IP rights that prevent you from complying with Article 42.
For IT Managers: You must ensure that your internal software repositories are compatible with the EU OSS Catalogue. If your national infrastructure is not yet connected, coordinate with your national OSPO to bridge this gap. Isolated repositories will fail to meet the CADA requirement for connected access.
For Policy Makers: CADA provides a legal basis for mandating open-source release of publicly funded software. Use this to develop national strategies that encourage reuse, reduce vendor dependency, and promote digital sovereignty. The proposal explicitly aims to "promote the sharing and reuse of open-source software by public sector bodies" (Article 44).

Common misconceptions

"All public software must be open-sourced." No. Article 42 applies when a public body decides to make software available for reuse. It does not mandate that all software must be released. However, it sets the strict standard for how it must be released if the decision is made to do so.

"Any public GitHub repository is sufficient." No. Simply hosting code on a public platform like GitHub does not satisfy Article 42 unless that repository is technically connected to and accessible through the central EU OSS Catalogue. The connection ensures uniform discoverability and metadata standards across the EU.

"The EU OSS Catalogue is only for EU institutions." No. The catalogue is designed for both Union entities and public sector bodies in Member States. National public administrations are encouraged to connect their national catalogues to the central EU hub to ensure their software is discoverable Union-wide.

"CADA replaces existing national open-source policies." No. CADA harmonises the mechanism of release (the connection to the central catalogue) but does not necessarily override national policies on whether to release software. It complements national strategies by providing a unified infrastructure for reuse.

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