Summary As proposed, Article 42 of the Cloud and AI Development Act (CADA) imposes a strict procedural obligation: when Union entities and public sector bodies make software available for reuse under an open-source licence, they must do so using a catalogue or repository that is "connected to, and made accessible through, the EU Open Source Solutions Catalogue (EU OSS Catalogue)." Sharing software via an isolated or unconnected repository constitutes a breach of this obligation. While CADA does not list a specific fixed fine for this exact violation in the text, non-compliance exposes the public body to national penalties defined under Article 24, which Member States must ensure are "effective, proportionate and dissuasive." The legislative intent, articulated in Recital 83, is to prevent fragmented repositories that "hamper searchability, discoverability and, ultimately, reuse."

Detail

The proposed Cloud and AI Development Act (CADA) seeks to transform the public sector's approach to software development from isolated silos into a cohesive, sovereign ecosystem. A critical component of this strategy is the mandatory centralisation of open-source releases. This section details the specific obligations under Article 42, the rationale provided in Recital 83, and the legal consequences of failing to connect to the EU OSS Catalogue.

The Mandatory Connection Obligation (Article 42)

Article 42, titled "Share and reuse of software," establishes a conditional but mandatory requirement for public entities. The provision 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 text creates a clear "if-then" legal trigger:

  1. Condition: The public body voluntarily decides to make software available for reuse under an open-source licence.
  2. Obligation: If the condition is met, the body shall (must) use a specific technical channel: a catalogue or repository connected to the EU OSS Catalogue.

The obligation does not force public bodies to open-source their software; they retain the discretion to keep software proprietary. However, the moment they choose to release it as open source, the method of release is strictly regulated. Hosting code on a public platform (e.g., a generic GitHub or GitLab instance) is insufficient unless that specific instance or the specific catalogue hosting the code is formally connected to the central EU OSS Catalogue.

The Rationale: Solving the Discoverability Crisis

The necessity of this centralisation is explicitly explained in Recital 83 of the proposal. The Commission identified a systemic market failure where public sector software is scattered across disparate platforms. The recital notes:

"However, software is often made available and accessible in different repositories or catalogues, hampering searchability, discoverability and, ultimately, reuse."

Without a centralised entry point, valuable public investments in software remain invisible to other administrations, leading to duplicated efforts and wasted resources. Article 43 empowers the Commission to maintain the EU OSS Catalogue as a "centralised catalogue to access software made available for reuse by Union entities and public sector bodies," hosted on the Interoperable Europe portal.

By mandating connection to this central hub, CADA ensures that:

  • Solutions are easily linked to further relevant information and training.
  • Searchability is maximised across the Union.
  • The value of public expenditure is maximised through increased reuse.

Consequences of Non-Compliance

If a public body shares open-source software via an unconnected repository, it fails to meet the requirement of Article 42. The legal consequences are derived from the enforcement framework of Title IV, Chapter I, Section 4 of CADA.

Article 24, "Penalties and compensation," sets the standard for enforcement. While the primary focus of Article 24(1) is on cloud computing service providers, the broader regulatory framework of Title IV applies to the ecosystem of autonomy and public procurement. Crucially, Article 24(1) mandates:

"Member States shall lay down the rules on penalties applicable to infringements of this Chapter... The penalties provided for shall be effective, proportionate and dissuasive."

Member States are required to notify the Commission of these rules and any subsequent amendments. Therefore, while the specific monetary amount of a fine for a public body violating Article 42 is not fixed in the CADA text itself, the national transposition laws must impose penalties that meet the EU standard of being "effective, proportionate and dissuasive."

Furthermore, Article 24(2) provides a non-exhaustive list of criteria Member States must consider when imposing penalties, including:

  • The nature, gravity, scale, and duration of the infringement.
  • Any action taken to mitigate or remedy the damage.
  • Any previous infringements.
  • Financial benefits gained or losses avoided.
  • The infringing party's annual turnover.

Although Article 24(3) specifically grants recipients of cloud services the right to seek compensation from providers, the principle of effective enforcement under Article 24(1) extends to the obligations placed on public bodies within the sovereignty framework. A public body that bypasses the EU OSS Catalogue undermines the single market's interoperability goals and risks administrative sanctions from its national competent authority.

What this means for you

For legal counsel, compliance officers, and Open Source Programme Office (OSPO) leads within Union entities and public sector bodies, the proposed CADA requires immediate operational adjustments.

1. Audit Your Release Channels

Conduct a comprehensive inventory of all software developed by or for your entity that is currently released or planned for release under an open-source licence. Identify the specific repositories (e.g., internal GitLab instances, public GitHub organizations) used. If these repositories are not technically connected to the EU OSS Catalogue, they are non-compliant with Article 42 as proposed.

2. Verify Technical Connectivity

Compliance is not just about hosting code; it is about connectivity. Article 43(3) states that the Commission shall decide on the request of any Union entity or public sector body to have their catalogue or repository "connected to and made accessible through the EU OSS Catalogue."

  • Action: Coordinate with your IT and legal teams to apply for this connection if you host your own repository.
  • Action: If you do not host your own repository, migrate your releases to a platform that has already secured this connection.

3. Update Internal Governance Policies

Revise your internal software release policies to explicitly state that any voluntary decision to release software under an open-source licence must utilize a connected repository. This should be a mandatory checkpoint in your Software Development Lifecycle (SDLC) before any public release. Failure to include this step could be deemed a procedural breach of Article 42.

4. Monitor National Transposition

As CADA is a proposal, the specific administrative fines will be defined by Member States during transposition. Monitor the legislative procedure closely. Ensure your compliance framework is robust enough to withstand scrutiny under the "effective, proportionate and dissuasive" standard required by Article 24.

5. Leverage the OSPO Network

Article 44 establishes a network of Open Source Programme Offices (OSPO Network). Engage with this network to exchange best practices on repository management and connection procedures. The network facilitates the exchange of information on technical, legal, and organisational challenges, including licensing and security, which can help mitigate compliance risks.

Common misconceptions

Misconception 1: CADA forces all public software to be open-source. Correction: CADA does not mandate that public bodies must open-source their software. Article 42 applies only "when making software... available for reuse under an open source licence." The obligation is conditional on the voluntary decision to share. However, Article 41 encourages the use of open standards, and once the decision to share is made, the method is strictly regulated.

Misconception 2: Any public GitHub or GitLab repository is sufficient. Correction: Hosting code on a public platform is not enough if that specific repository or organization is not connected to the EU OSS Catalogue. Article 42 requires the catalogue or repository to be "connected to, and made accessible through, the EU OSS Catalogue." Isolated public repositories fail the discoverability requirement of Recital 83 and the connectivity requirement of Article 42.

Misconception 3: There are no penalties for public bodies. Correction: While Article 24 explicitly mentions "cloud computing service providers" in paragraph 1, the framework of Title IV creates a binding regulatory environment for the entire ecosystem, including public bodies acting as software providers. Member States are required to implement effective penalties for infringements of the Chapter. Assuming immunity from penalty is a significant compliance risk.

Misconception 4: The EU OSS Catalogue is optional for discoverability. Correction: Recital 83 explicitly states that fragmented repositories "hamper searchability, discoverability and, ultimately, reuse." The Commission is tasked with maintaining the EU OSS Catalogue as the centralised catalogue (Article 43). Using disconnected channels undermines the legislative goal of a unified European open-source ecosystem and exposes the entity to compliance failures under Article 42.

Related

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