Summary Under the proposed Cloud and AI Development Act (CADA), if a Union entity or public sector body holds the intellectual property rights to software and voluntarily decides to make it available for reuse, it must do so under an open-source licence. Crucially, as proposed in Article 42, this software must be published in a catalogue or repository that is connected to, and made accessible through, the EU Open Source Solutions Catalogue (EU OSS Catalogue). This requirement ensures that publicly funded software is findable, reusable, and contributes to the Union's digital sovereignty by preventing fragmentation across national borders.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, aims to strengthen the European cloud and AI ecosystem by reducing dependencies on third-country providers and fostering technological sovereignty. A key lever for achieving this is the promotion of open-source software, which enhances transparency, security, and interoperability while limiting vendor lock-in. Title IV, Chapter V of the proposal specifically addresses open source, establishing a framework for public administrations to share and reuse software effectively.

The Obligation to Share via the EU OSS Catalogue

Article 42 of the CADA proposal sets out a specific procedural requirement for public-sector bodies and Union entities that choose to release their software. The text 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 provision does not mandate that all public-sector software must be open-sourced. Rather, it regulates the mechanism of release when an entity voluntarily decides to share software it owns. The requirement ensures that any software released under an open-source licence is not siloed in internal or disconnected repositories, but is instead integrated into a centralised, Union-wide discovery platform.

The logic behind this rule is to create a "single source of truth" for public-sector code. Without this connectivity, software developed in one Member State might remain invisible to a public body in another, leading to duplicated efforts and wasted public funds. By mandating connection to the EU OSS Catalogue, CADA ensures that the "value of public expenditure" is maximised through reuse, as highlighted in the explanatory memorandum.

The Role of the EU OSS Catalogue

The EU Open Source Solutions Catalogue (EU OSS Catalogue), established under Article 43, serves as the centralised hub for accessing software made available for reuse by Union entities and public sector bodies. Hosted on the Interoperable Europe portal (as referenced in the proposal), the catalogue is designed to be electronically accessible free of charge. Its primary function is to improve the searchability and discoverability of public-sector software, thereby fostering innovation across the Union.

By mandating connection to this catalogue, CADA addresses a common fragmentation issue: software developed by public bodies is often stored in disparate locations, making it difficult for other administrations or private developers to find and reuse. Connecting local or national repositories to the EU OSS Catalogue creates a federated system where metadata and access points are standardised, allowing users to search across the entire Union's open-source assets from a single interface.

The Commission is empowered to decide on requests from any Union entity or public sector body to have their catalogue or repository connected to the EU OSS Catalogue, based on "objective and relevant criteria." This ensures that the central hub remains a curated, high-quality resource rather than a dumping ground for unverified code.

Intellectual Property and Voluntary Nature

It is important to note that Article 42 applies only to software "to which they hold intellectual property rights." This means the obligation to connect to the catalogue is triggered only when the public body owns the IP and chooses to release it. If a public body uses third-party proprietary software or open-source software where it does not hold the underlying IP rights for the core components, this specific article does not impose a sharing obligation.

Furthermore, the act of making software available must be "under an open source licence." This aligns with the broader CADA objective of promoting open standards and components to reduce dependency on single vendors. The choice of specific open-source licence (e.g., MIT, Apache 2.0, GPL) is not dictated by Article 42, but the licence must meet the standard definition of an open-source licence as defined in the Interoperable Europe Act (Regulation (EU) 2024/903), ensuring that the code can be freely accessed, used, modified, and redistributed.

Connection to the OSPO Network

While Article 42 focuses on the technical mechanism of publishing, the broader implementation of open-source strategies is supported by the network of Open Source Programme Offices (OSPOs), established under Article 44. The OSPO Network facilitates cooperation on the implementation of these obligations, promoting the sharing and reuse of open-source software by public sector bodies. Entities managing the release of software under Article 42 are encouraged to engage with their national or Union-level OSPO to ensure compliance with best practices regarding licensing, security, and maintenance.

The OSPO Network is tasked with facilitating the exchange of information, experience, and best practices between Member States and the Commission, particularly regarding licensing, security, and procurement of open-source software. This network serves as a critical support structure for public bodies navigating the new requirements of CADA.

What this means for you

For public-sector procurement officers, CIOs, and digital strategy leads, Article 42 introduces a compliance checkpoint for any initiative involving the release of in-house developed software. As CADA is a proposal, these steps represent the intended compliance path once the regulation is adopted.

  1. Audit Your Software Assets: Identify software projects where your organisation holds the intellectual property rights. Determine which of these projects are candidates for open-source release. Distinguish between software you own and software you merely license or use.
  2. Ensure Catalogue Connectivity: Before releasing any software under an open-source licence, verify that your existing software repository or catalogue is technically connected to the EU OSS Catalogue. If you do not have a connected catalogue, you must establish one or use an existing national repository that is already linked to the EU hub. You cannot simply host the code on a standalone GitHub or GitLab instance without this federation.
  3. Standardise Metadata: To ensure your software is discoverable, ensure that the metadata associated with your software in your local catalogue aligns with the standards required by the EU OSS Catalogue. This includes clear descriptions, licensing information, technical specifications, and contact details for maintainers.
  4. Leverage the OSPO Network: Engage with your national or Union OSPO (Article 44) for guidance on selecting appropriate open-source licences and managing the long-term maintenance of released software. The OSPO Network facilitates the exchange of best practices and can help streamline the process of making software available.
  5. Promote Reuse: When procuring new software solutions, consider whether existing open-source solutions available in the EU OSS Catalogue could meet your needs, thereby avoiding duplicate development costs and contributing to the circular economy of public-sector software. This aligns with the "open source first" principle encouraged under Article 41.

Common misconceptions

Misconception 1: CADA forces all public-sector software to be open-sourced. Reality: Article 42 applies only when a public body voluntarily decides to make software available for reuse. CADA encourages open source (Article 41) and sets rules for when it is released, but it does not mandate that all custom-developed public software must be open-sourced.

Misconception 2: You can host open-source software on any internal server. Reality: If you hold the IP and release the software under an open-source licence, Article 42 mandates that it must be done through a catalogue or repository connected to the EU OSS Catalogue. Isolated, unconnected repositories do not comply with this requirement. The goal is federation, not just publication.

Misconception 3: This applies to all software used by the public sector. Reality: The provision specifically targets software "to which they hold intellectual property rights." It does not apply to third-party commercial software or open-source software where the public body is merely a user and does not own the underlying IP.

Misconception 4: The EU OSS Catalogue replaces national software repositories. Reality: The EU OSS Catalogue is a centralised access point. It does not replace national or local repositories but requires them to be connected. Public bodies can maintain their local infrastructure, provided it is federated with the EU catalogue to ensure cross-border discoverability.

Misconception 5: CADA is already in force. Reality: CADA is currently a proposal (COM(2026) 502 final). It has not yet been adopted by the European Parliament and the Council. The obligations described here would apply only after the regulation enters into force and the relevant transition periods have elapsed.

Related

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