Summary As proposed, Article 42 of the Cloud and AI Development Act (CADA) applies exclusively to software to which a Union entity or public sector body holds intellectual property rights (IPR). The rule mandates that when such entities voluntarily make this specific software available for reuse under an open-source licence, they must do so via a catalogue or repository connected to the central EU Open Source Solutions Catalogue. This obligation does not apply to proprietary software owned by third-party vendors, even if that software is used by the public sector. The key trigger is ownership: if the public body does not hold the IPR, Article 42 is inapplicable.

Detail

Article 42 of the proposed Cloud and AI Development Act (CADA) establishes a precise, conditional framework for the sharing and reuse of software within the public sector. To determine the scope of this obligation, one must analyze the intersection of three elements: the holder of the intellectual property, the origin of the software ("developed by or for"), and the voluntary nature of the release.

The Core Condition: Intellectual Property Ownership

The definitive criterion for the application of Article 42 is IP ownership. The text of the article 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 phrasing creates a strict boundary. The obligation is triggered only when the public sector body is the legal rights holder.

  • Scenario A (In Scope): A public authority commissions a software solution, and the procurement contract stipulates that the authority retains the copyright (e.g., "work for hire" or specific IP transfer clauses). If the authority later decides to release this software under an open-source licence, Article 42 applies.
  • Scenario B (Out of Scope): A public authority purchases a commercial off-the-shelf (COTS) product or commissions a vendor where the vendor retains the IPR. Even if the authority uses this software extensively, it cannot "make it available for reuse" under Article 42 because it does not hold the rights. The authority cannot unilaterally open-source software it does not own.

The "Developed By or For" Context

While Article 42 focuses on the rights holder, the legislative intent clarifies the typical origin of such software. Recital 83 of the CADA explanatory memorandum provides the necessary context: "An increasing number of Union entities and public-sector bodies are sharing software developed by or for them and making it available for reuse under an open-source licence."

This recital confirms that the regulation targets software where the public sector has been the primary driver of creation or the direct beneficiary of development, resulting in the public sector holding the IPR. It addresses the fragmentation caused when different public bodies develop similar tools in isolation, only to host them in disparate, inaccessible repositories.

The "Voluntary" Nature of the Obligation

It is critical to note that Article 42 does not mandate that public bodies must open-source their software. The obligation is procedural, not substantive regarding the decision to release.

  • The Trigger: The obligation arises only "when making software... available for reuse."
  • The Condition: If a public body decides to release software under an open-source licence, it must follow the Article 42 procedure.
  • The Alternative: If a public body decides to keep the software proprietary or closed, Article 42 imposes no requirement to change that decision.

This distinction is reinforced by the broader context of Article 41, which encourages the use of open source but does not impose a blanket "open-source first" mandate that overrides existing IP strategies. Article 42 simply ensures that if the choice is made to open source, the ecosystem remains unified.

The Connectivity Requirement: The EU OSS Catalogue

Article 42 does not stand alone; it functions as a gateway to the central infrastructure established in Article 43. The article mandates that the entity's chosen catalogue or repository must be "connected to, and made accessible through, the EU OSS Catalogue."

  • Federated Approach: Public bodies are not forced to migrate all software to a single central server. They may maintain their own national or local repositories.
  • Technical Linkage: However, these local repositories must be technically integrated with the central EU OSS Catalogue, which is hosted on the Interoperable Europe portal (as per Article 43(2)).
  • Purpose: This ensures that software released by a local authority in one Member State is discoverable and reusable by a Union entity or another Member State, preventing the "silo effect" where valuable public code remains hidden.

Definitions and Scope

To apply Article 42 correctly, one must rely on the definitions in Article 2:

  • Union Entities: Defined in Article 2(7) as "the Union institutions, bodies, offices and agencies set up by or pursuant to the Treaty on European Union, the Treaty on the Functioning of the European Union (TFEU) or the Treaty establishing the European Atomic Energy Community."
  • Public Sector Bodies: Defined in Article 2(6) by reference to Directive (EU) 2019/1024 (Open Data Directive). This includes bodies governed by public law, state, regional, or local authorities, and associations formed by such authorities.
  • Software: Defined in Article 2(13) by reference to Regulation (EU) 2024/2847 (Cyber Resilience Act), ensuring a consistent technical definition across EU digital law.
  • Open Source Licence: Defined in Article 2(25) by reference to Regulation (EU) 2024/903 (Interoperable Europe Act).

What this means for you

For in-house counsel, procurement officers, and IT directors in public sector bodies and Union entities, Article 42 introduces a specific compliance checkpoint for open-source releases.

1. Conduct an IP Ownership Audit

Before initiating any open-source release, you must verify your IP ownership status.

  • Review Contracts: Examine procurement contracts, development agreements, and licensing terms. Does the contract explicitly transfer IPR to the public body, or does the vendor retain it?
  • Determine Scope: If the vendor retains the IPR, Article 42 is irrelevant to that asset. You cannot comply with Article 42 for software you do not own.
  • Proceed Only if Owner: If the public body holds the IPR (e.g., through specific clauses ensuring the body owns the code developed "for" them), you must proceed to the next step if you intend to release it.

2. Ensure Repository Connectivity

If you plan to release software under an open-source licence, you cannot simply host it on an isolated internal server or a disconnected public GitHub repository.

  • Technical Integration: You must ensure your repository is technically connected to the EU OSS Catalogue. This may require integration with the Interoperable Europe portal.
  • Pre-Release Check: Compliance teams should coordinate with IT and the relevant Open Source Programme Office (OSPO) to verify that the technical linkage is established before the software is made public. A standalone repository that is not federated with the EU OSS Catalogue does not satisfy Article 42.

3. Engage with the OSPO Network

Article 44 establishes a network of Open Source Programme Offices (OSPOs). Compliance officers should engage with their national or entity-level OSPO to ensure that the release aligns with broader open-source strategies. The OSPO Network is tasked with facilitating the exchange of best practices and promoting the sharing and reuse of open-source software (Article 44(3)(b)).

4. Understand the Enforcement Landscape

Unlike the sovereignty framework in Title IV, Chapter V (Open Source) does not contain a specific penalty article (like Article 24). However, non-compliance with CADA obligations generally falls under the enforcement powers of national competent authorities or the Commission. For Union entities, relevant EU oversight bodies may enforce compliance. For Member States, national authorities will likely monitor adherence to the reuse obligations as part of broader digital transformation and interoperability mandates.

Common misconceptions

Misconception 1: CADA forces public bodies to open-source all software. Reality: Article 42 applies only to software that entities voluntarily decide to make available for reuse. CADA encourages open source (Article 41) but does not mandate that all public sector software must be open-sourced. The obligation is procedural, not substantive regarding the act of open-sourcing itself.

Misconception 2: It covers all software used by the public sector. Reality: It only covers software to which the public body holds intellectual property rights. Software licensed from private vendors, where the vendor retains IP, is excluded. This is a critical distinction for compliance teams managing complex procurement portfolios.

Misconception 3: Any public repository is sufficient. Reality: The repository must be "connected to, and made accessible through, the EU OSS Catalogue." A standalone repository that is not federated with the EU OSS Catalogue does not satisfy Article 42.

Misconception 4: This applies to private companies. Reality: Article 42 explicitly addresses "Union entities and public sector bodies." Private companies are not subject to this specific reuse obligation under CADA, though they may be subject to other open-source requirements in procurement contracts (Article 32).

Related

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