Summary As proposed in the Cloud and AI Development Act (CADA), the EU Open Source Solutions Catalogue (EU OSS Catalogue) would function strictly as a centralised access point and federated aggregator, not as a primary code host. Article 43 mandates that Union entities and public sector bodies make software available in a catalogue or repository that is connected to and made accessible through the EU OSS Catalogue. This architecture ensures the actual source code remains stored in the original repositories owned and operated by the entities, while the EU OSS Catalogue provides the unified discovery layer hosted on the Interoperable Europe portal.

Detail

The Cloud and AI Development Act (CADA), as set out in COM(2026) 502 final, proposes a strategic shift in how public sector software is shared, discovered, and reused across the European Union. A core component of this strategy is the establishment of the EU Open Source Solutions Catalogue (EU OSS Catalogue), designed specifically to solve the fragmentation problem where public sector software is often scattered across disparate internal repositories, hampering searchability and reuse.

The legal architecture of this solution is defined by Article 42 and Article 43. It is critical to distinguish between hosting the code and connecting to the code. CADA does not mandate that the European Commission host the actual source code binaries, git histories, or repositories. Instead, it mandates a federated architecture where the catalogue acts as a directory.

The Federated Aggregator Model

The proposal explicitly rejects a centralised hosting model in favour of a federated one. Article 43(1) states that the Commission shall provide and maintain an EU OSS Catalogue as a "centralised catalogue to access software made available for reuse by Union entities and public sector bodies." The operative verb is "access," not "store" or "host."

This distinction is reinforced by the obligation placed on software providers in Article 42:

"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 legal phrasing establishes a clear division of responsibility:

  1. The Provider (Union Entity/Public Body): Retains full ownership and operational control of the software repository. They must host the code themselves (e.g., on GitHub, GitLab, or internal institutional servers) and ensure it is licensed openly.
  2. The Connection: The provider's repository must be technically "connected to" the EU OSS Catalogue. This implies an API integration, metadata harvesting, or federation protocol that allows the central catalogue to index the software without ingesting the code itself.
  3. The EU OSS Catalogue: Acts as the search engine and directory. It aggregates metadata from these connected repositories to provide a single pane of glass for discovery.

Technical Implementation and Hosting Location

Article 43(2) clarifies the physical location of the catalogue interface itself:

"The EU OSS Catalogue shall be hosted on the Interoperable Europe portal referred to in Article 8 of Regulation (EU) 2024/903 and shall be accessible electronically free of charge."

This confirms that the catalogue interface and its underlying database of metadata will be hosted by the Commission on the Interoperable Europe portal. However, the content (the source code) remains external to this portal.

Article 43(3) provides the governance mechanism for this federation:

"The Commission shall, on the basis of objective and relevant criteria, decide on the request of any Union entity or public sector body owning or maintaining a catalogue or repository to have that catalogue or repository connected to and made accessible through the EU OSS Catalogue."

This provision empowers the Commission to define the technical standards for "connection." In practice, this likely means adhering to open standards for repository metadata (such as those used by Open Source Guides or similar interoperability frameworks) so that the central catalogue can pull information without needing to ingest the code itself. The repositories remain with their owners, but they become visible through the central portal.

Why This Model Was Chosen

The explanatory memorandum accompanying the proposal highlights that software is often "made available and accessible in different repositories or catalogues, hampering searchability, discoverability and, ultimately, reuse" (Recital 83). By choosing a federated model over a centralised hosting model, CADA aims to:

  • Reduce Administrative Burden: Entities do not need to migrate code to a new EU server, avoiding the costs and risks associated with data migration.
  • Maintain Sovereignty and Control: Entities keep their code in their own infrastructure, maintaining their own contribution guidelines, issue trackers, and CI/CD pipelines.
  • Enhance Interoperability: Leveraging the Interoperable Europe portal ensures that the catalogue integrates with existing EU digital identity and interoperability standards, rather than creating a siloed hosting environment.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the distinction between hosting and linking has several operational implications.

For Public Sector CTOs and Architects

If you manage software assets for a Union entity or a Member State's public sector body, you are not required to migrate your codebases to a new EU-hosted platform. However, you are required to ensure your existing repositories are "connected" to the EU OSS Catalogue if you choose to release software under an open-source licence.

  • Action Item: Audit your current open-source release process. Ensure your repositories expose metadata in a format that can be harvested by the EU OSS Catalogue.
  • Infrastructure: You must maintain the hosting of the code. The EU will not provide storage for your binaries or git history.
  • Compliance: You must decide which of your repositories to connect. Not every internal script needs to be public, but any software you choose to release under an open-source licence for reuse must be routed through a connected catalogue.

For SMEs and Private Providers

While CADA primarily binds Union entities and public sector bodies, the ripple effects are significant for the private sector.

  • Discoverability: The EU OSS Catalogue will become the primary discovery layer for public-sector open source. If you are an SME building solutions that integrate with or extend public sector software, you should monitor the catalogue to identify potential integration points.
  • Partnerships: The catalogue may highlight public sector projects that are looking for commercial support or maintenance. Being visible in the ecosystem (even if you are not a public entity) can create business opportunities.
  • Standards Alignment: The "objective and relevant criteria" for connection (Article 43(3)) will likely establish de facto standards for open-source metadata in the EU. Aligning your internal repository metadata with these standards now will make future integration easier if you ever partner with public bodies.

For Developers and Contributors

The user experience will change from searching multiple government websites to searching one central portal. However, when you click through from the EU OSS Catalogue, you will be redirected to the original repository (e.g., a GitHub org or a national government's GitLab). You will contribute, raise issues, and fork the code in the original location, not in the EU OSS Catalogue itself.

Common misconceptions

Misconception 1: The EU will take over hosting of all public open-source code.

  • Reality: No. Article 43 explicitly states that entities use a catalogue or repository connected to the EU OSS Catalogue. The source code remains with the original owner. The EU hosts the directory, not the code.

Misconception 2: All public sector software must be published on the EU OSS Catalogue.

  • Reality: Article 42 applies to software that entities voluntarily decide to make available for reuse under an open-source licence. It does not force every piece of internal software to be open-sourced. However, if you do open-source it, you must do so via a connected repository.

Misconception 3: The EU OSS Catalogue is a new Git hosting service like GitHub Enterprise.

  • Reality: It is a discovery and metadata aggregation layer hosted on the Interoperable Europe portal. It does not provide version control, issue tracking, or pull request management. Those functions remain with the underlying repository hosts.

Misconception 4: Private companies can upload their code to the EU OSS Catalogue.

  • Reality: Article 43(1) limits the scope to "software made available for reuse by Union entities and public sector bodies." Private companies cannot directly upload to the catalogue. However, they can collaborate with public entities who may then host and connect the resulting software.

Related

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