Summary As proposed in the Cloud and AI Development Act (CADA), any Union entity or public sector body that owns or maintains a software catalogue or repository has the right to request that it be connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue). However, this connection is not automatic. Under Article 43(3), the European Commission must decide on each request based on objective and relevant criteria. The framework is designed to centralise discoverability while allowing public bodies to maintain their own repositories, creating a federated network of open-source solutions across the Union.

Detail

The proposed Cloud and AI Development Act (CADA) establishes a comprehensive framework to foster the sharing and reuse of open-source software within the European public sector. A critical component of this strategy is the creation of a centralised discovery point: the EU Open Source Solutions Catalogue. While Article 42 mandates that public bodies making software available for reuse must do so via a repository connected to this central catalogue, Article 43 defines the specific mechanism for how those repositories become connected.

The Legal Basis for Connection Requests

The right to request a connection is explicitly granted in Article 43(3) of the CADA proposal. The text states:

"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 clarifies three fundamental aspects of the process:

  1. Eligibility: The right to submit a request is limited to Union entities (EU institutions, bodies, offices, and agencies) and public sector bodies (as defined in Directive (EU) 2019/1024). Private sector entities, regardless of their contribution to open-source ecosystems, do not have a statutory right under this article to request direct connection of their commercial repositories.
  2. Ownership Requirement: The requester must be the entity that owns or maintains the catalogue or repository. This ensures that the entity submitting the request has the technical and legal authority to manage the connection and the content within the repository.
  3. Discretionary Approval: The Commission is not obliged to approve every request. It retains the authority to make a decision based on objective and relevant criteria. This prevents the catalogue from becoming a repository for non-compliant, insecure, or technically incompatible systems.

The Commission's Decision-Making Role

The phrase "on the basis of objective and relevant criteria" in Article 43(3) is the cornerstone of the connection process. While the proposal does not enumerate these specific technical criteria in the main text, the legislative intentβ€”supported by Recital 83β€”is to ensure the catalogue remains a high-quality, searchable, and interoperable resource.

The Commission's decision will likely evaluate:

  • Technical Interoperability: The repository must be capable of integrating with the EU OSS Catalogue's search and indexing mechanisms. This implies adherence to specific metadata standards and API protocols.
  • Data Quality and Completeness: The repository must provide sufficient metadata to ensure software is discoverable. This includes accurate licensing information, versioning details, and documentation, as required for effective reuse.
  • Accessibility and Security: The repository must be electronically accessible and free of charge, in line with Article 43(2). Additionally, it must demonstrate adherence to cybersecurity best practices to protect the integrity of the shared software.

If a request is denied, the entity would typically need to address the identified gapsβ€”such as improving metadata standards or security protocolsβ€”and reapply. Alternatively, the entity might choose to host its software in a repository that is already connected to the EU OSS Catalogue, thereby satisfying the obligation under Article 42 without needing a direct connection for its own infrastructure.

A Federated, Not Centralised, Model

A common misunderstanding is that the EU OSS Catalogue requires all public bodies to migrate their software to a single, Commission-managed database. Article 43 explicitly rejects this centralised model in favour of a federated approach.

Public bodies are permitted to maintain their own local, national, or regional repositories. The obligation is not to move the code, but to ensure that the repository is connected to and made accessible through the central EU OSS Catalogue. This "hub-and-spoke" architecture allows for:

  • Decentralised Management: Public bodies retain control over their own software lifecycles, update schedules, and hosting environments.
  • Centralised Discovery: Users across the Union can search and find software regardless of where it is physically hosted, as the central catalogue aggregates metadata from all connected repositories.
  • Scalability: The system can grow organically as more public bodies join, without requiring a massive central infrastructure expansion.

Hosting and Accessibility Requirements

While the connection process involves administrative approval, the end-user experience is designed to be seamless. Article 43(2) mandates that the EU OSS Catalogue itself shall be hosted on the Interoperable Europe portal (as referred to in Article 8 of Regulation (EU) 2024/903) and shall be accessible electronically free of charge.

This ensures that while the integration of a new repository requires a Commission decision based on technical criteria, the access to the software once listed is barrier-free for all users, including other public bodies, researchers, and the general public.

What this means for you

For public-sector IT managers, Open Source Programme Office (OSPO) leads, and procurement officers, Article 43 introduces a new compliance pathway for software reuse strategies.

  1. Identify Eligible Repositories: Conduct an audit of your organisation's software assets. Identify any internal or national repositories that host open-source software developed by or for your authority. If you intend to release this software for reuse, you must ensure it is hosted in a repository that can connect to the EU OSS Catalogue.
  2. Prepare for the Request Process: Since connection is not automatic, you must proactively prepare a request. Ensure your repository meets the likely "objective and relevant criteria" regarding metadata standards, API availability, and security protocols.
  3. Leverage the OSPO Network: Article 44 establishes a network of Open Source Programme Offices. Your national or regional OSPO will likely serve as a key resource for guidance on preparing your repository for connection. They may also facilitate aggregated requests for smaller local authorities that lack the resources to manage the process individually.
  4. Plan for Interoperability: If your current repository cannot immediately meet the connection criteria, consider partnering with a larger, already-connected national repository. This allows you to comply with Article 42 (the obligation to use a connected repository) while you upgrade your own infrastructure.
  5. Monitor Commission Guidance: As the proposal is a draft, the specific "objective and relevant criteria" for connection will likely be detailed in future implementing acts or guidance documents issued by the Commission. Stay informed on these developments to ensure your request is successful.

Common misconceptions

"Any open-source project can be listed in the EU OSS Catalogue." No. The catalogue is specifically designed for software made available for reuse by Union entities and public sector bodies. While the software itself may be used by anyone, the mechanism for adding a repository to the catalogue is restricted to public bodies under Article 43(3). Private companies cannot request to connect their commercial repositories to this specific public-sector hub.

"Connection is automatic once we publish code under an open-source licence." There is no automatic scraping or indexing of public code. The Commission must actively decide to approve the connection request. You must proactively apply, and the Commission will evaluate your repository against objective criteria before granting access.

"We must move all our code to the Commission's server." Incorrect. The model is federated. You can keep your code in your own repository (e.g., a national GitHub Enterprise instance or a ministry-specific GitLab), provided that repository is technically connected to the EU OSS Catalogue for search and discovery purposes. The goal is centralised discovery, not centralised storage.

"Only large national bodies can apply." The text of Article 43(3) refers to "any Union entity or public sector body." This includes local and regional authorities, provided they own or maintain a catalogue or repository. Smaller bodies may need to coordinate through their national OSPOs or join a national repository to meet the technical criteria.

Related

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