Summary Under the proposed Cloud and AI Development Act (CADA), listing software in the EU Open Source Solutions Catalogue is merely the final step in a broader compliance chain. Union entities and public sector bodies must first actively encourage the use of open source over proprietary solutions based on objective criteria (Article 41). If they choose to share software, they must ensure it is hosted in a repository connected to the central catalogue (Article 42). Finally, they are expected to participate in a coordinated network of Open Source Programme Offices (OSPOs) to ensure consistent implementation (Article 44). These layered obligations, supported by Recital 84, aim to reduce vendor lock-in and strengthen technological sovereignty through structured assessment and cooperation, rather than a simple "publish and forget" approach.

Detail

The proposed CADA (COM(2026) 502 final) establishes a comprehensive framework for open source in the public sector, moving beyond passive adoption to active strategic management. The obligations are not isolated; they form a lifecycle of assessment, sharing, and institutional coordination.

1. Strategic Assessment and Encouragement (Article 41)

Article 41 imposes a proactive duty on Union entities and Member States. It requires them to "take the necessary measures to encourage Union entities and public sector bodies to use and facilitate the reuse of open standards and components released under an open source licence when building their cloud and AI ecosystem or stack."

This is not a blanket mandate to use open source for every project. Instead, it creates a duty of evaluation. The article explicitly states that this encouragement must take into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria."

For legal and procurement teams, this means:

  • Mandatory Evaluation: Before selecting a proprietary solution, the entity must document that open source alternatives were evaluated against the specific criteria of security, total cost of ownership (TCO), and functionality.
  • Justification of Outcome: If a proprietary solution is chosen, the entity must be able to demonstrate that the decision was based on "duly justified objective criteria" where open source was found lacking in specific areas (e.g., security or functionality).
  • Recital 84 Context: Recital 84 reinforces this by noting the necessity to set up the OSPO network "in order to ensure effective and consistent implementation across the Union of the obligations to conduct an open-source assessment." This confirms that the assessment is a formal, recurring obligation, not a one-time check. Future delegated acts may further specify the methodology for these assessments.

2. The "Gateway" Obligation for Shared Software (Article 42)

While the decision to share software developed by or for a public body is voluntary, the mechanism of sharing is strictly regulated. Article 42 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."

This creates a critical compliance "gateway":

  • No Isolated Repositories: An entity cannot simply host code on an internal GitLab instance or a disconnected GitHub organization and claim compliance. If the software is released under an open source licence for reuse, the hosting platform must be technically connected to the central EU Open Source Solutions Catalogue (established under Article 43).
  • Discoverability: The purpose is to prevent fragmentation. The central catalogue acts as a single point of discovery for all public sector open source, ensuring that "reuse" is actually possible across the Union.
  • Scope: This applies to software where the entity holds intellectual property rights. It does not apply to software merely used by the entity, but specifically to software developed by or for them that is being shared.

3. Institutional Coordination via the OSPO Network (Article 44)

Article 44 addresses the human and organizational infrastructure required to sustain the open source strategy. It mandates the Commission to "establish a network of Open Source Programme Offices (OSPO Network) to facilitate cooperation on the implementation of the obligations under this Chapter."

The obligations here are twofold:

  • Establishment of Local OSPOs: While the text says OSPOs "may request" to join the network, the preamble and the nature of the obligation imply that Member States and Union entities are expected to establish these offices at local, regional, or national levels to fulfill the "necessary measures" of Article 41.
  • Mandated Tasks: The network is tasked with:
    • Facilitating the exchange of information on licensing, security, maintenance, and procurement challenges.
    • Promoting the sharing and reuse of open-source software.
    • Contributing to the development of guidance, templates, and recommendations.
    • Collaborating on open-source projects of common interest.

This shifts open source from an ad-hoc IT decision to a governed function. Legal teams must ensure that their organization has a designated function or office capable of engaging with this network to access shared guidance and templates.

4. The Interplay of Obligations

The three articles function as a cohesive system:

  1. Article 41 drives the demand (evaluate and encourage open source).
  2. Article 42 manages the supply (ensure shared code is discoverable via the central hub).
  3. Article 44 provides the governance (OSPOs ensure consistent application and knowledge sharing).

Failure to connect a repository to the EU OSS Catalogue (violating Art 42) undermines the visibility goals of the Act. Failure to conduct a proper assessment (violating Art 41) leaves the entity vulnerable to challenges regarding the "duly justified" nature of their procurement choices. Lack of OSPO participation (Art 44) may lead to inconsistent implementation across the Union, potentially triggering Commission guidance or corrective measures.

What this means for you

For in-house counsel, procurement officers, and CIOs in the public sector or Union entities, the following actions are required to ensure compliance with the proposed CADA:

  • Formalize the Open Source Assessment: Update procurement guidelines to explicitly require an "open-source assessment" for all cloud and AI stack purchases. Document the evaluation of security, TCO, and functionality against open source alternatives. Retain these records to prove that decisions were based on "duly justified objective criteria" as required by Article 41.
  • Audit Repository Connectivity: Before releasing any software under an open source licence, verify that your chosen repository (e.g., GitHub, GitLab, Gitea) is technically capable of connecting to the EU OSS Catalogue. If your current infrastructure is isolated, you must migrate or integrate it to satisfy Article 42.
  • Establish or Designate an OSPO: Assess your organization's capacity to manage open source licensing, security, and reuse. If you do not have a dedicated Open Source Programme Office, consider establishing one or designating a specific team to act as your representative. Join the OSPO Network under Article 44 to access the Commission's guidance and templates.
  • Monitor Delegated Acts: Keep a close watch on the Commission's work on delegated acts. Recital 84 suggests that the methodology for "open-source assessments" may be further specified. Early adoption of a robust assessment framework will prevent compliance gaps when these rules are finalized.

Common misconceptions

"We must use open source for every project." No. Article 41 requires entities to encourage use and evaluate open source options. It does not mandate open source in every instance. If a proprietary solution offers superior security or functionality that cannot be matched by open source, the entity may choose it, provided the decision is based on "duly justified objective criteria" and documented. The obligation is on the process of evaluation, not the outcome.

"We can share software internally without listing it in the EU OSS Catalogue." If the software is made available for reuse under an open source licence, Article 42 requires it to be accessible through a repository connected to the EU OSS Catalogue. Internal-only sharing (where the code is not available for reuse by others) does not trigger this specific obligation. However, the moment the intent is "reuse" under an open source licence, the connectivity requirement applies.

"OSPO participation is optional, so we can ignore it." While individual OSPOs "may request" to join the network, the broader obligation for Member States and Union entities is to take "necessary measures" to facilitate the implementation of the Chapter. Ignoring the OSPO framework risks non-compliance with the goal of "effective and consistent implementation" mentioned in Recital 84. Furthermore, failing to participate means missing out on the shared guidance, templates, and legal support that the network is designed to provide.

"The EU OSS Catalogue is just a list of links." The Catalogue is a centralised, interoperable hub established under Article 43 and hosted on the Interoperable Europe portal. Its purpose is to ensure that software is not just listed, but discoverable and accessible across the Union. The "connection" requirement in Article 42 is a technical and legal gateway to ensure this interoperability.

Related

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