Summary Under the proposed Cloud and AI Development Act (CADA), the phrase "software developed by or for" a public body defines the scope of software subject to a specific sharing obligation. As proposed in Article 42, this obligation is triggered only when a Union entity or public sector body holds the intellectual property (IP) rights to the software and voluntarily decides to make it available for reuse. The wording, clarified in Recital 83, covers both in-house development ("developed by") and commissioned development ("developed for"), provided the public body retains the IP. If the public body does not hold the IP rights (e.g., in a standard licensing scenario), the Article 42 obligation does not apply.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a framework to strengthen the European cloud and AI ecosystem. A critical component of this framework is the promotion of open-source solutions to reduce vendor lock-in, foster innovation, and maximize the value of public expenditure. Article 42 serves as the procedural mechanism for the sharing and reuse of software assets held by the public sector.

The Trigger: Intellectual Property Ownership

The core condition for the application of Article 42 is explicitly stated in the text: the provision applies to "software to which they hold intellectual property rights." This creates a binary trigger based on legal ownership rather than mere usage or funding.

  • If the public body holds the IP: The entity has the legal capacity to license the software under an open-source license. If it chooses to make this software available for reuse, Article 42 mandates that it must do so via a catalogue or repository connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue).
  • If the public body does not hold the IP: The obligation does not arise. This is common in commercial off-the-shelf (COTS) purchases or specific commissioning contracts where the vendor retains ownership and grants the public body a perpetual or limited license. In such cases, the public body cannot unilaterally release the source code under an open-source license, as it lacks the necessary IP rights.

Defining "Developed By or For Them"

The phrase "developed by or for them" in Article 42 is not defined in the articles themselves but is contextualized by Recital 83 of the proposal. The recital observes that "an increasing number of Union entities and public-sector bodies are sharing software developed by or for them." This wording is intentionally expansive to capture the full spectrum of public sector software acquisition.

  1. "Developed by" (In-house): This refers to software created directly by the public body's own resources. This includes code written by internal civil servants, dedicated IT departments, or staff employed directly by the Union entity or public sector body. The public body naturally holds the IP rights in these scenarios unless specific employment contracts state otherwise (which is rare in the public sector context).

  2. "Developed for" (Commissioned): This refers to software created by external actorsβ€”such as private contractors, vendors, or service providersβ€”specifically for the public body. The critical distinction here lies in the procurement contract.

    • If the contract stipulates that the public body acquires the IP rights (a "work for hire" arrangement or explicit assignment of rights), the software is considered "developed for" the public body in the context of Article 42.
    • If the contract grants the public body only a license to use the software while the vendor retains the IP, the software is not subject to the Article 42 sharing obligation, even if the public body funded its creation.

The Procedural Obligation: Connection to the EU OSS Catalogue

Article 42 does not impose a blanket mandate that all public sector software must be open-sourced. Instead, it regulates the method of sharing when a public body makes the voluntary decision to release software.

The text states that when a Union entity or public sector body makes software available for reuse under an open-source license, it "shall do so using a catalogue or repository that is connected to, and made accessible through, the EU OSS Catalogue."

This requirement addresses the fragmentation identified in Recital 83, which notes that software is often made available in disparate repositories, "hampering searchability, discoverability and, ultimately, reuse." By mandating a connection to the central EU OSS Catalogue (hosted on the Interoperable Europe portal under Article 43), CADA aims to create a unified, searchable repository for public sector software, thereby maximizing the return on public investment and facilitating cross-border reuse.

Relationship with Article 41

It is essential to distinguish Article 42 from Article 41.

  • Article 41 is a policy encouragement. It requires Union entities and public sector bodies to "encourage and facilitate their use of open-source solutions" when building their cloud and AI ecosystems. It promotes the adoption of open source.
  • Article 42 is a procedural obligation. It applies only when a public body already holds the IP and decides to share that specific software. It governs the dissemination mechanism.

What this means for you

For legal counsel, procurement officers, and IT directors within Union entities and public sector bodies, the proposed Article 42 introduces specific due diligence requirements regarding software procurement and IP management.

1. Audit Procurement Contracts for IP Clauses

The most immediate impact of Article 42 is on how public bodies draft and negotiate software development contracts.

  • Review Existing Contracts: Identify projects where the public body commissioned software but the vendor retained the IP. In these cases, the public body cannot trigger the Article 42 sharing obligation, nor can it legally open-source the code.
  • Future Procurement Strategy: If the public body intends to retain the option of open-sourcing commissioned software in the future, procurement clauses must explicitly stipulate the transfer of intellectual property rights to the public body. Without this transfer, the software falls outside the scope of "software to which they hold intellectual property rights," rendering Article 42 inapplicable.

2. Prepare for the "Voluntary" Decision

Since Article 42 is triggered by the decision to make software available for reuse, public bodies must establish internal governance processes for this decision.

  • Decision Framework: Establish criteria for when software should be released. This could include software with high reuse potential, low security risk, or strategic value for the ecosystem.
  • Technical Readiness: Ensure that the IT infrastructure can support the connection to the EU OSS Catalogue. This may involve selecting or configuring code repositories (e.g., GitLab, GitHub Enterprise) that are technically capable of interoperating with the central catalogue as defined in future implementing acts.

3. Monitor Secondary Legislation

Article 43 empowers the Commission to maintain the EU OSS Catalogue and decide on requests to connect external repositories.

  • Implementing Acts: The specific technical standards, metadata requirements, and connection protocols for linking a national or local repository to the EU OSS Catalogue will be detailed in implementing acts. Legal teams should monitor these developments to ensure compliance with the technical "connection" requirement.
  • Timeline: As a proposal, CADA is not yet in force. However, once adopted, the transition period will require public bodies to align their repositories with the central catalogue.

4. Distinguish Between "Use" and "Release"

Teams must clearly differentiate between the use of open-source software (encouraged by Article 41) and the release of public-owned software (mandated by Article 42).

  • Buying Proprietary Software: Purchasing a proprietary solution does not trigger Article 42. The obligation only arises if the public body owns the code and chooses to share it.
  • Using Open Source: Using open-source components in a proprietary solution does not automatically trigger Article 42 for the entire solution, unless the public body holds the IP of the entire software product and decides to release it.

Common misconceptions

Misconception 1: "All software developed by or for a public body must be open-sourced." This is incorrect. Article 42 does not mandate open-sourcing. It only regulates the process if a public body voluntarily decides to make software available for reuse. A public body can legally choose to keep its custom software proprietary and closed, provided it does not decide to release it under an open-source license. If it does decide to release it, then the Article 42 procedural rules apply.

Misconception 2: "Developed for" means the public body automatically owns the IP." This is a dangerous assumption. "Developed for" simply describes the origin of the software (commissioned by the public body). It does not dictate ownership. If the procurement contract assigns IP to the vendor, the software is "developed for" the public body but the public body does not "hold intellectual property rights." Consequently, Article 42 does not apply, and the public body cannot release the code.

Misconception 3: "The rule applies to any software the public body uses." Article 42 is strictly limited to software "to which they hold intellectual property rights." It does not apply to software where the public body is merely a licensee (e.g., standard SaaS subscriptions, COTS software, or commissioned software where the vendor retains ownership). The trigger is ownership, not usage.

Misconception 4: "Public bodies can share software on any platform." If a public body decides to share software it owns, Article 42 mandates that it must use a repository "connected to, and made accessible through, the EU OSS Catalogue." Posting the code on a private GitHub repository or an isolated internal server without connecting it to the central catalogue would be non-compliant with the proposed regulation.

Related

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