Summary Under the proposed Cloud and AI Development Act (CADA), Article 42 establishes a mandatory routing requirement: when Union entities or public sector bodies voluntarily decide to make software available for reuse under an open-source licence, they must do so via a catalogue or repository that is "connected to, and made accessible through, the EU Open Source Solutions Catalogue (EU OSS Catalogue)" established in Article 43. This is not a suggestion to link externally; it is a structural obligation requiring technical integration. Article 43 empowers the Commission to maintain this centralised catalogue on the Interoperable Europe portal and to decide, based on "objective and relevant criteria," which external repositories may connect. Together, these articles create a unified "one-stop-shop" to prevent fragmentation, ensure findability, and maximise the reuse of publicly funded software across the Union.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a targeted framework to transform how the European public sector manages and shares software assets. While Article 41 sets the strategic "open source first" principle, Articles 42 and 43 provide the operational machinery to ensure that software released under open-source licences is not lost in siloed national or departmental repositories. These two articles function as a single, interlocking mechanism: one creates the obligation to connect, and the other builds the hub to which connection is required.

The Mandatory Routing Mechanism: Article 42

Article 42, titled "Share and reuse of software," addresses the critical issue of discoverability. It recognises that while many public bodies may already host software in their own repositories, these assets often remain invisible to other potential users across the EU.

The article imposes a specific condition on the act of sharing. It 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 contains three distinct legal elements:

  1. Voluntary Trigger: The obligation is triggered only when an entity decides to make software available. CADA does not force the release of all software; it respects the entity's discretion to keep certain software proprietary or internal.
  2. Mandatory Method: Once the decision to release is made, the method is no longer discretionary. The entity cannot simply publish the code on a standalone website, a private GitHub organisation, or an isolated internal server.
  3. The Connection Requirement: The software must be hosted in a catalogue that is technically "connected to" the central EU OSS Catalogue. The phrase "connected to, and made accessible through" implies a level of interoperability and data synchronization that goes beyond a simple hyperlink. It suggests that the central catalogue must be able to index, search, and potentially retrieve the software from the connected repository.

The Central Hub: Article 43

Article 43, titled "EU Open Source Solutions Catalogue," establishes the infrastructure required to satisfy Article 42. It designates the Commission as the steward of this central asset.

Key provisions of Article 43 include:

  • Centralisation: The Commission shall "provide and maintain an EU Open Source Solutions Catalogue (EU OSS Catalogue) as a centralised catalogue to access software made available for reuse by Union entities and public sector bodies."
  • Hosting and Access: The catalogue must be hosted on the Interoperable Europe portal (referencing Regulation (EU) 2024/903) and must be "accessible electronically free of charge." This ensures that the hub is integrated into the existing EU digital infrastructure and is open to all users without cost barriers.
  • Commission Authority: Crucially, Article 43(3) grants the Commission the power to manage the ecosystem's boundaries: "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 authority means that not every repository can automatically connect. Entities must apply, and the Commission will evaluate these requests against defined criteria to ensure the integrity, security, and interoperability of the central catalogue.

How Articles 42 and 43 Operate Together

The relationship between these articles is symbiotic and creates a closed loop of compliance. Article 42 creates the demand for a unified system by mandating that any shared software must flow through a connected channel. Article 43 creates the supply of that channel by establishing the central hub and the governance framework for connectivity.

Without Article 43, Article 42 would be unenforceable, as there would be no central standard to connect to. Without Article 42, Article 43 would be a passive directory with no guaranteed inflow of public-sector software.

This structure serves the broader objectives of CADA:

  • Preventing Fragmentation: By routing all shared software through a centralised point, the Act prevents the creation of thousands of disconnected "islands" of innovation.
  • Maximising Public Value: It ensures that software developed with public funds is findable and reusable by other public bodies, reducing duplication of effort and cost.
  • Enhancing Security and Trust: A centralised, auditable catalogue allows for better monitoring of software quality and security, supporting the "open source first" principle of Article 41.

What this means for you

For legal counsel, IT directors, and compliance officers within Union entities and public sector bodies, the interplay of Articles 42 and 43 introduces a new layer of software asset management obligations.

1. Audit Your Software Portfolio

You must first identify software developed by or for your organisation over which you hold intellectual property rights. Determine which assets are candidates for release under an open-source licence. While the decision to release remains voluntary, the consequence of that decision is strictly regulated.

2. Assess Your Current Repository Strategy

If your organisation currently hosts open-source software on an internal repository, a private GitLab instance, or a standalone website, you must evaluate whether this infrastructure can be "connected" to the EU OSS Catalogue.

  • Direct Upload: You may choose to upload software directly to the EU OSS Catalogue itself (if the Commission permits direct submissions).
  • Connected Repository: Alternatively, you may maintain your own catalogue but must apply to the Commission to have it connected. You cannot simply link to your repository; the repository itself must be technically integrated.

3. Prepare for Commission Criteria

Article 43(3) explicitly states that the Commission will decide on connection requests based on "objective and relevant criteria." These criteria are not yet defined in the proposal but will likely cover:

  • Technical Interoperability: Ability to exchange metadata and software packages via standard APIs.
  • Security Standards: Compliance with cybersecurity requirements for hosting and distributing code.
  • Licensing Compliance: Ensuring that all software in the connected repository adheres to valid open-source licences.
  • Maintenance: Proof that the repository is actively maintained and not abandoned.

4. Align with the Interoperable Europe Act

Since the EU OSS Catalogue is hosted on the Interoperable Europe portal (Regulation (EU) 2024/903), your compliance strategy must align with the interoperability standards of that regulation. This includes adherence to the European Interoperability Framework (EIF) and the use of common technical specifications for data exchange.

5. Monitor for Implementing Acts

The specific technical details of "connection" will likely be fleshed out in future implementing acts or guidance from the Commission. Legal teams should monitor these developments closely, as failure to meet the technical standards for connection could render a voluntary release non-compliant with Article 42.

Common misconceptions

Misconception 1: "We can just link to our own GitHub repository." Correction: No. Article 42 requires the software to be made available via a catalogue "connected to, and made accessible through" the EU OSS Catalogue. A simple hyperlink does not constitute a technical connection. The repository must be integrated into the central system to ensure the software is discoverable and accessible through the central portal.

Misconception 2: "We are forced to open-source all our software." Correction: Article 42 is triggered only when an entity "voluntarily decide[s] to make software... available for reuse." The Act does not mandate the release of all software. However, if you choose to release, you must use the connected catalogue mechanism.

Misconception 3: "The EU OSS Catalogue is just a list of links to external sites." Correction: The text describes it as a "centralised catalogue to access software." The requirement for repositories to be "connected to" and "made accessible through" it implies a functional integration where the central catalogue can index and potentially serve the software, rather than just acting as a directory of URLs.

Misconception 4: "This only applies to new software developed after the Act enters into force." Correction: Article 42 applies to software "developed by or for" Union entities and public sector bodies. It does not distinguish between new and legacy software. If you hold the IP rights to legacy code and decide to release it, the Article 42/43 connection requirement applies immediately.

Related

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