Summary The proposed Cloud and AI Development Act (CADA) does not impose a blanket mandate to use open-source software. Instead, Article 41 requires Union entities and public sector bodies to encourage and facilitate the use of open-source solutions when building their cloud and AI ecosystems, subject to a structured evaluation of functionalities, security, and total cost. If a public body voluntarily decides to make software available for reuse under an open-source licence, Article 42 mandates that it must be shared via a catalogue connected to the central EU Open Source Solutions Catalogue. To ensure consistent implementation of these assessment and sharing obligations, Recital 84 establishes the Network of Open Source Programme Offices (OSPO Network), which facilitates the exchange of best practices and guidance across the Union.

Detail

The proposed CADA (COM(2026) 502 final) introduces a strategic framework to reduce vendor lock-in and strengthen technological sovereignty by integrating open-source principles into public-sector software procurement and development. The regime is defined by a balance between encouraging open-source adoption and maintaining operational flexibility, supported by a new governance network.

The "Open-Source Assessment" under Article 41

The term "open-source assessment" in the context of CADA refers to the mandatory evaluation process required by Article 41. This provision obliges the Union and Member States to take 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.

Crucially, Article 41 does not impose an absolute prohibition on proprietary software. Instead, it requires decision-makers to weigh open-source options against specific, duly justified objective criteria. The text explicitly lists the following factors that must be taken into account:

  • Functionalities: Whether the open-source solution meets the technical requirements of the project.
  • Security: The robustness of the solution against cyber threats, including auditability of the source code.
  • Total Cost: A comprehensive assessment of costs, including acquisition, maintenance, integration, and long-term support.
  • Other Relevant, Duly Justified Objective Criteria: This allows for flexibility to address specific operational needs, provided the justification is documented and objective.

Recital 81 provides the rationale for this obligation, noting that access to source code enables auditability, fosters collaboration and reuse, and reduces dependency on a single vendor. By mandating a structured evaluation rather than a "open-source first" ban on proprietary tools, CADA seeks to balance innovation with the imperative of technological autonomy.

Mandatory Reuse via the EU OSS Catalogue (Article 42)

While Article 41 governs the selection of software, Article 42 governs the sharing of software developed or acquired by public bodies. The obligation here 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.

If such a decision is made, the public body must ensure the software is made available using a catalogue or repository that is:

  1. Connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue) established under Article 43.
  2. Made accessible through this centralised portal, which is hosted on the Interoperable Europe portal.

Recital 83 identifies the problem this solves: software is often made available in disparate repositories, hampering searchability, discoverability, and ultimately, reuse. By linking all national and Union catalogues to the central EU OSS Catalogue, CADA aims to create a "one-stop-shop" for public-sector software, maximising the value of public expenditure and fostering innovation across the Union.

The OSPO Network: Ensuring Consistent Implementation (Article 44 & Recital 84)

To prevent fragmented implementation of these obligations, Article 44 establishes the Network of Open Source Programme Offices (OSPO Network). Recital 84 explicitly links this network to the consistent application of the Regulation, stating that it is necessary to ensure effective implementation of the obligations to conduct an open-source assessment (under Article 41) and to make software available for reuse (under Article 42).

The OSPO Network brings together offices established by public sector bodies at local, regional, or national levels, as well as those established by Union entities. Its core tasks include:

  • Facilitating the exchange of information, experience, and best practices.
  • Discussing common technical, legal, and organisational challenges, including licensing, security, maintenance, and procurement of open-source software.
  • Promoting the sharing and reuse of open-source software.
  • Contributing, on a voluntary and non-binding basis, to the development of guidance, templates, or recommendations.

The Commission supports and coordinates this network, convening meetings at least twice a year. This structure provides a direct channel for guidance, helping public bodies navigate the complexities of the "open-source assessment" and ensuring that the criteria in Article 41 are applied consistently across the single market.

Interaction with Procurement and Sovereignty

The open-source provisions in Chapter V (Articles 41–44) operate alongside CADA's broader sovereignty framework. While Article 41 focuses on the technical and economic evaluation of software, Article 32 requires contracting authorities to include Union added value criteria in public procurement, which can include the use of software designed or manufactured in the Union. The open-source assessment under Article 41 thus becomes a critical tool for demonstrating how a procurement decision contributes to the EU's digital supply chain and reduces dependencies on third-country providers.

What this means for you

For in-house counsel, compliance officers, and IT procurement teams in the public sector, CADA introduces a new layer of procedural rigor into software lifecycles.

1. Documented Justification is Mandatory If your organisation opts for a proprietary software solution over an available open-source alternative, you must be prepared to document the justification. Under Article 41, the decision must explicitly consider functionalities, security, and total cost. "Habit," "legacy integration," or "vendor preference" alone may not suffice as a "duly justified objective criterion" if a comparable open-source solution exists that meets security and functional requirements at a lower total cost. Compliance teams should implement a scoring matrix for software evaluations to ensure this obligation is met audibly.

2. The "Voluntary" Trap in Article 42 Be aware that the obligation to connect to the EU OSS Catalogue is triggered the moment a public body decides to share software. If your entity develops custom software (e.g., internal AI models, management tools) and decides to release it as open source, you cannot simply publish it on a private GitHub repository or a disconnected national portal. Article 42 requires that the catalogue used is connected to the central EU OSS Catalogue. Legal and IT teams must collaborate to ensure that the technical infrastructure for software release supports this interoperability requirement.

3. Leverage the OSPO Network Compliance officers should identify or establish an Open Source Programme Office (OSPO) within their organisation. Article 44 invites these offices to join the EU-wide network. Participation is the primary mechanism for receiving guidance on how to interpret the "open-source assessment" requirements and best practices for licensing and security. Ignoring this network may lead to fragmented implementation and missed opportunities for software reuse.

4. Strategic Procurement Alignment Public procurement procedures for cloud and AI services must reflect these open-source preferences. While CADA does not ban proprietary vendors, the evaluation criteria in tenders should explicitly account for the availability of open-source components and the long-term strategic benefits of open standards. This aligns with the broader CADA goal of reducing dependencies on third-country providers and strengthening the EU's digital supply chain.

Common misconceptions

"CADA bans proprietary software." This is incorrect. Article 41 encourages the use of open-source solutions but allows for exceptions based on functionalities, security, and total cost. Proprietary software remains permissible if it offers superior value or meets specific security/functional requirements that open-source alternatives cannot, provided this is duly justified.

"All public software must be made open source." Article 42 applies only when a Union entity or public sector body voluntarily decides to make software available for reuse. There is no blanket obligation to open-source all internally developed software. However, if the decision is made to share, the strict condition of connecting to the EU OSS Catalogue applies.

"The 'open-source assessment' is a one-time compliance check." The assessment under Article 41 is an ongoing part of the procurement and development lifecycle. Furthermore, the OSPO Network (Article 44) is designed to facilitate continuous exchange of best practices, implying that open-source governance is a dynamic function, not a static box-ticking exercise.

"Only the Commission manages open-source policy." While the Commission maintains the central EU OSS Catalogue (Article 43), the implementation is decentralised through the OSPO Network (Article 44). National and local authorities play a critical role in establishing their own OSPOs and connecting their catalogues, creating a federated model of open-source governance.

Related

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