Summary Under the proposed Cloud and AI Development Act (CADA), Union entities and public sector bodies must list software made available for reuse on a catalogue connected to the central EU Open Source Solutions Catalogue (EU OSS Catalogue). Article 43(3) empowers the Commission to decide on connection requests based on "objective and relevant criteria," which will likely mandate specific metadata to ensure discoverability and interoperability. While the proposal does not list fixed metadata fields, Recital 83 clarifies that the catalogue must enable solutions to be "easily linked to further relevant information and training." Consequently, the required records will focus on standard identifiers, licensing clarity, and technical documentation to facilitate reuse across the public sector, rather than a rigid, static list defined in the primary text.

Detail

The Cloud and AI Development Act (CADA) introduces a mandatory framework for the sharing and reuse of software developed by or for Union entities and public sector bodies. This mechanism is designed to maximize the value of public expenditure, reduce duplication costs, and foster innovation by preventing software from being siloed in disparate repositories.

The Legal Obligation to Connect

The core obligation is established in Article 42 of the proposal, which states that when a Union entity or public sector body makes software available for reuse under an open-source licence, it must do so using a catalogue or repository that is connected to, and made accessible through, the EU OSS Catalogue.

The EU OSS Catalogue itself is established by Article 43(1) as a centralised catalogue to access software made available for reuse by these entities. Article 43(2) mandates that this catalogue be hosted on the Interoperable Europe portal (established under Regulation (EU) 2024/903) and be accessible electronically free of charge.

Criteria for Catalogue Connection and Metadata Implications

The proposal does not prescribe a rigid, static list of metadata fields in the enacting text. Instead, it delegates the technical and operational standards to the Commission through a gatekeeping mechanism. Article 43(3) 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 is critical for CTOs and architects because it implies that the "metadata requirements" are effectively the "connection criteria." To have a national or organizational repository connected to the central EU OSS Catalogue, the repository's data structure must meet these objective and relevant criteria.

While the specific criteria are to be defined in secondary legislation (likely implementing acts or delegated acts, as referenced in Article 46), the recitals provide strong guidance on what these criteria will entail. Recital 83 explains the rationale:

"Software is often made available and accessible in different repositories or catalogues, hampering searchability, discoverability and, ultimately, reuse. It is therefore necessary to require Union entities and public-sector bodies that voluntarily decide to make software available for reuse to do so in a catalogue or repository that is connected to EU Open Source Solutions Catalogue..."

Consequently, the metadata requirements will be designed to solve the problems of "searchability" and "discoverability." Based on the alignment with the Interoperable Europe Act (IEA), which mandates the sharing and reuse of interoperability solutions (Article 4 of Regulation (EU) 2024/903), the metadata will likely need to include:

  1. Standardized Identifiers: Unique identifiers for the software package to prevent duplication in the central index and ensure precise tracking.
  2. Licensing Information: Clear, machine-readable declarations of the open-source licence used, ensuring compliance with the definition of "open source licence" in Article 2(25) of CADA.
  3. Technical Specifications: Metadata describing the software's functionality, dependencies, and compatibility with other public sector systems to enable interoperability.
  4. Contact and Support Details: Information on the maintaining entity to facilitate collaboration and troubleshooting.
  5. Links to Further Resources: Recital 83 explicitly notes that hosting the catalogue on the Interoperable Europe portal will ensure that solutions can be "easily linked to further relevant information and training." This suggests metadata fields for documentation, tutorials, or training materials will be required or strongly encouraged to enhance usability and adoption.

The Role of the OSPO Network

To support this metadata standardization, Article 44 establishes a network of Open Source Programme Offices (OSPO Network). This network is tasked with facilitating the exchange of information and best practices, including those related to licensing, security, and maintenance. It is likely that the OSPO Network will develop the technical guidelines for the metadata schemas that satisfy the "objective and relevant criteria" of Article 43(3).

What this means for you

For CTOs, architects, and SMEs providing software to the public sector, this framework shifts the burden from simple code hosting to structured data management.

  • For Public Sector IT Leaders: You cannot simply push code to a private GitHub repository and claim compliance. You must ensure your internal repository is structured to allow connection to the EU OSS Catalogue. This means investing in metadata management tools that can extract and format software details according to the forthcoming Commission criteria. Failure to connect may mean your software is not legally "made available for reuse" in the manner intended by the Regulation, potentially exposing your entity to non-compliance risks.
  • For SMEs and Vendors: If you develop software for a public sector client that is then released as open source, you need to understand the metadata standards early. The "objective and relevant criteria" will likely favor standardized, machine-readable metadata formats (such as those compatible with the Interoperable Europe portal's APIs). Designing your software packages with clear, automated metadata extraction from the start will reduce integration costs.
  • Discoverability as a KPI: Since the goal is to maximize reuse, the quality of your metadata directly impacts the visibility of your software. Poorly tagged software will not be found, negating the strategic value of the open-source release. Focus on clear descriptions, accurate licence tagging, and comprehensive documentation links.

Common misconceptions

  • "The Commission will define every metadata field in the primary law." This is incorrect. The primary law (CADA) sets the framework and the authority (Article 43(3)) but leaves the specific technical metadata schema to secondary legislation. The criteria will be "objective and relevant," meaning they will evolve with technological standards.
  • "Only the code matters; documentation is optional." Recital 83 explicitly links the catalogue to "further relevant information and training." Metadata that fails to link to documentation, training, or usage guides will likely fail the "relevant criteria" test for connection, as it hampers discoverability and reuse.
  • "Private companies must list their proprietary software." The obligation in Article 42 applies to "Union entities and public sector bodies" making software they hold intellectual property rights to available for reuse. It does not mandate that private vendors open-source their proprietary tools, though they may need to provide metadata for any open-source components they contribute to public sector projects.
  • "Any open-source repository will suffice." No. The repository must be connected to the EU OSS Catalogue. This connection is not automatic; it requires a decision by the Commission based on the criteria in Article 43(3). A standalone internal Jira or GitLab instance will not comply unless it is technically integrated into the central catalogue ecosystem.

Related

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