Summary As proposed, the Cloud and AI Development Act (CADA) defines the scope of software reuse in Article 42, which mandates that any Union entity or public sector body making software available for reuse under an open-source licence must do so through a catalogue or repository connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue). This obligation applies strictly to software where the entity holds intellectual property rights and is triggered only when the entity voluntarily decides to release that software. The provision, supported by Recital 83, aims to prevent fragmentation, maximize the value of public expenditure, and ensure discoverability across the Union, without compelling public bodies to release all software as open source.

Detail

The Cloud and AI Development Act (CADA), proposed by the European Commission on 3 June 2026 (COM(2026) 502 final), establishes a comprehensive framework to strengthen Europe's cloud and AI ecosystem. A critical pillar of this framework is the promotion of open source to enhance technological sovereignty, transparency, and security. While Article 41 encourages the adoption of open-source solutions, Article 42 specifically governs the output and sharing of software developed by the public sector.

The Operative Scope of Article 42

Article 42, titled "Share and reuse of software," establishes a procedural obligation rather than a substantive mandate to open-source. 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 definition of scope relies on two cumulative conditions that must be met for the obligation to trigger:

  1. Intellectual Property Ownership: The entity must hold the intellectual property rights to the software. If the software was developed by a third-party contractor who retains the IP, or if the rights are subject to complex joint-ownership arrangements where the public body does not hold the necessary rights to license the software, Article 42 does not apply.
  2. Voluntary Decision to Share: The entity must have made a decision to make the software available for reuse under an open-source licence. The proposal does not force public bodies to release proprietary software or software kept internal for security, operational, or strategic reasons.

When these conditions are satisfied, the scope of "reuse" is strictly defined by the method of distribution. The entity cannot simply host the code on an internal intranet, a standalone public repository (e.g., a generic GitHub organization page), or a disconnected external server. The software must be made available via a catalogue or repository that is technically connected to, and made accessible through, the EU OSS Catalogue.

This requirement ensures that the software is not merely "public" but "discoverable" within a unified Union-wide ecosystem. The connection to the central catalogue is the defining feature of the reuse scope under CADA.

The Rationale: Preventing Fragmentation (Recital 83)

The legislative intent behind this specific scope is detailed in Recital 83 of the explanatory memorandum. The Commission observes that while an increasing number of Union entities and public-sector bodies are sharing software, this activity is currently fragmented. Software is often "made available and accessible in different repositories or catalogues," which "hamper[s] searchability, discoverability and, ultimately, reuse."

By narrowing the scope of reuse to a connected catalogue, the proposal addresses three key policy failures:

  • Maximizing Public Value: Software developed with public funds often remains siloed. By mandating connection to the EU OSS Catalogue, the proposal ensures that such assets are easily found and reused by other administrations, thereby reducing duplication costs and maximizing the return on public investment.
  • Fostering Innovation: A centralized hub encourages collaboration, allowing developers and public bodies to build upon existing solutions rather than reinventing the wheel.
  • Ensuring Interoperability: The EU OSS Catalogue is hosted on the Interoperable Europe portal (as established by Regulation (EU) 2024/903). This integration links software solutions to relevant information, training, and other interoperability assets, ensuring that reused software aligns with broader EU digital standards.

Interaction with Related Provisions

Article 42 does not operate in isolation; it is part of a broader open-source architecture within CADA:

  • Article 41 (Promoting Open Source): While Article 42 governs the sharing of output, Article 41 encourages Union entities and public sector bodies to use open standards and components released under open-source licences when building their cloud and AI ecosystems. Article 41 sets the input preference; Article 42 sets the output channel.
  • Article 43 (EU OSS Catalogue): This article establishes the central catalogue itself, mandating that the Commission provide and maintain it on the Interoperable Europe portal. It also empowers the Commission to decide on requests from other entities to connect their repositories to this central hub.
  • Article 44 (OSPO Network): To support the implementation of Article 42, this article establishes a network of Open Source Programme Offices (OSPO Network). This network facilitates the exchange of best practices, guidance on licensing, and technical support, ensuring that public bodies can effectively navigate the requirements of making software available via the EU OSS Catalogue.

What this means for you

For in-house counsel, compliance officers, and IT directors within Union entities and public sector bodies, Article 42 introduces a specific compliance checkpoint in the software lifecycle management process.

1. Verify IP Ownership Before Release

The first step in determining if Article 42 applies is a rigorous audit of intellectual property rights. The obligation applies only to software "to which they hold intellectual property rights."

  • Action: Review contracts with third-party vendors, contractors, and joint-venture partners. If a vendor retains the IP, Article 42 does not trigger. If the IP is jointly owned, ensure the public body has the legal authority to license the software under an open-source licence before proceeding.

2. Ensure Technical Connectivity to the EU OSS Catalogue

If your organization decides to release software, you cannot simply publish it to a public repository without further action.

  • Action: Coordinate with your IT and legal teams to ensure your chosen hosting platform (whether an internal repository or a public platform like GitLab/GitHub) is technically connected to the EU OSS Catalogue. This may involve:
    • Implementing APIs or data feeds to allow the EU OSS Catalogue to index your software.
    • Ensuring metadata standards align with the catalogue's requirements.
    • Verifying that the connection is maintained and that the software remains "accessible through" the central catalogue.

3. Leverage the OSPO Network

Article 44 creates a support structure for these obligations.

  • Action: If your entity does not already have an Open Source Programme Office (OSPO), consider establishing one or joining the network. The OSPO Network will provide guidance on licensing, security, and maintenance, helping to ensure that your reuse activities comply with CADA and broader EU data protection and cybersecurity standards.

4. Monitor for Delegated and Implementing Acts

The Commission is empowered to adopt delegated acts to update criteria and procedures, and implementing acts to specify technical details.

  • Action: Stay informed about secondary legislation that may define the precise technical specifications for "connection" to the EU OSS Catalogue. These details will determine the exact technical compliance requirements for your organization.

Common misconceptions

Misconception 1: CADA forces all public software to be open source. Reality: Article 42 is conditional. It applies only when a Union entity or public sector body voluntarily decides to make software available for reuse under an open-source licence. It does not compel the release of proprietary software or software that is kept internal for security, operational, or strategic reasons.

Misconception 2: Any public repository is sufficient. Reality: Hosting code on a standalone public repository (e.g., a generic GitHub organization page) is not enough if it is not connected to the EU OSS Catalogue. The proposal explicitly requires the use of a catalogue or repository "connected to, and made accessible through, the EU OSS Catalogue" to ensure discoverability and interoperability.

Misconception 3: This applies to private companies. Reality: Article 42 specifically targets "Union entities and public sector bodies." Private companies are not subject to this obligation. However, private entities may choose to contribute to the EU OSS Catalogue voluntarily, and they may benefit from the increased availability of high-quality open-source tools developed by the public sector.

Misconception 4: The EU OSS Catalogue is a new, separate platform. Reality: The EU OSS Catalogue is not a new standalone system. It is hosted on the existing Interoperable Europe portal (Regulation (EU) 2024/903), integrating software solutions into the EU's broader interoperability infrastructure.

Related

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