Summary Under the proposed Cloud and AI Development Act (CADA), public authorities must prioritize open-source software and components when building their cloud and AI ecosystems, but this is not an absolute ban on proprietary technology. Article 41 establishes an "open source first" principle that requires a mandatory balancing test: proprietary solutions remain permissible if they are "duly justified" by objective criteria such as superior security, lower total cost of ownership, or specific functionalities that open-source alternatives cannot provide. This framework, grounded in Recital 81, aims to reduce vendor lock-in and enhance digital autonomy while preserving the flexibility needed for effective public service delivery.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a strategic shift in how European public authorities approach software procurement, specifically targeting the balance between open-source and proprietary solutions. While the Act does not mandate a 100% open-source stack, it fundamentally alters the default position of public procurement by establishing a presumption in favor of open standards and open-source components.

The Legal Basis: Article 41 and the Balancing Test

The core of this policy is found in Article 41 of the proposal, titled "Promoting open source solutions and open source first." This article imposes a specific obligation on the Union and Member States 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."

Crucially, Article 41 is not a rigid prohibition. It explicitly qualifies this encouragement by stating that it must be applied "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria." This phrasing creates a statutory balancing test. It acknowledges that while open source is the preferred baseline for sovereignty and interoperability, there are legitimate scenarios where proprietary software may be the superior choice for a specific public need.

The "duly justified" requirement is the key operational constraint. It means that a public authority cannot simply default to a proprietary vendor because of brand familiarity or convenience. If a procurement officer chooses a proprietary solution over an available open-source alternative, they must be prepared to document an objective justification based on one or more of the following pillars:

  1. Security: If a proprietary solution offers security features, certifications, or a threat-model response capability that is demonstrably superior to available open-source options, this constitutes a valid justification. The Act recognizes that in high-risk environments, the specific security posture of a solution may outweigh the transparency benefits of open source.
  2. Total Cost: The Act explicitly references "total cost." This requires a holistic analysis beyond simple licensing fees. If a proprietary solution, despite potential licensing costs, results in a lower total cost of ownership (TCO) due to reduced integration time, lower maintenance overhead, or faster time-to-market, it may be justified. Conversely, if an open-source solution requires prohibitively expensive customization or specialized talent that drives up the TCO, the proprietary option may be the objective choice.
  3. Functionality: If a specific public service requires unique capabilities, performance metrics, or interoperability features that only a proprietary solution can deliver, the "functionality" criterion allows for that choice. The justification must demonstrate that open-source alternatives cannot meet the specific functional requirements of the project.
  4. Other Relevant Criteria: This catch-all allows for flexibility regarding integration with legacy systems, specific regulatory compliance needs, or other objective factors relevant to the specific procurement context.

The Rationale: Recital 81, Vendor Lock-in, and Digital Autonomy

The driving force behind Article 41 is the need to address "vendor lock-in" and strengthen "digital autonomy," as detailed in Recital 81 of the explanatory memorandum. The Commission states that "access to the source code enables auditability, fosters collaboration and reuse and reduces dependency on a single vendor, thereby limiting the risk of vendor lock-in."

Recital 81 further explains that "promoting the use of open source is therefore essential to support innovation, ensure better value for public expenditure and strengthen the Union's digital autonomy." The text highlights that the choice of software has significant implications not only for cost-efficiency but also for "security, interoperability, accountability and technological autonomy."

The concern is that reliance on proprietary, closed-source ecosystems can lead to a situation where public authorities become "locked in" to a single provider. This lock-in creates a power imbalance where the vendor can dictate terms, raise prices, or discontinue support with little recourse for the public body. By mandating the use of open standards and open-source components, CADA aims to ensure that public authorities retain control over their digital infrastructure. If a proprietary vendor raises prices or discontinues support, a public entity relying on open standards and interoperable components can more easily switch providers or migrate to alternative solutions without losing functionality or data.

This approach aligns with the broader objectives of CADA to reduce critical external dependencies on non-European technology providers. By fostering a market where open-source solutions are the default, the Act seeks to create a more competitive and resilient European cloud and AI ecosystem.

The Ecosystem of Reuse: Articles 42, 43, and 44

CADA does not stop at procurement; it creates a framework for the lifecycle management of public software. Article 42 requires that when Union entities or public sector bodies make software available for reuse under an open-source license, they must do so through a catalogue or repository connected to the EU Open Source Solutions Catalogue (established under Article 43).

This centralization is designed to solve the "discoverability" problem. As noted in the proposal, software is often made available in different repositories, "hampering searchability, discoverability and, ultimately, reuse." By connecting these repositories to a central catalogue hosted on the Interoperable Europe portal, CADA ensures that a solution developed by one public body can be easily found and reused by another, reducing duplication of effort and maximizing the value of public expenditure.

Furthermore, Article 44 establishes a network of Open Source Programme Offices (OSPO Network) to facilitate cooperation, exchange best practices, and contribute to the development of guidance on sharing and reusing open-source software. This institutionalizes the "open source first" mindset within the public sector administration.

What this means for you

For public-sector procurement officers, IT decision-makers, and legal counsel, the introduction of CADA's open-source provisions changes the procurement workflow and risk profile in several key ways:

1. The Burden of Justification Shifts

Under the proposed regime, the default assumption is that open source is the correct choice. If you choose a proprietary solution, the burden of proof shifts to you. You must maintain a clear, documented record of the "balancing test" performed. This documentation must explicitly evaluate the proprietary option against open-source alternatives regarding security, total cost, and functionality.

  • Actionable Step: Create a standard "Open Source Justification Form" for your procurement process. If a proprietary tool is selected, this form must detail the specific objective criteria (e.g., "Proprietary tool X offers a certified security module required for this specific regulation, which open-source alternative Y lacks") that justify the deviation from the open-source default.

2. Total Cost of Ownership (TCO) is the Metric

The Act explicitly mentions "total cost," not just "licensing cost." This requires a sophisticated financial analysis.

  • Actionable Step: When comparing solutions, do not just look at the license fee. Calculate the TCO, including:
    • Initial integration and customization costs.
    • Ongoing maintenance and support costs.
    • Training costs for staff.
    • Potential migration costs if the vendor changes terms.
    • The cost of "lock-in" risk (e.g., the potential price hike in 5 years).
    • If the proprietary solution has a lower TCO due to faster deployment or lower maintenance, document this clearly.

3. Leverage the EU OSS Catalogue

Before issuing a tender for a new software solution, you are expected to check the EU Open Source Solutions Catalogue (Article 43).

  • Actionable Step: Integrate a search of the EU OSS Catalogue into your pre-procurement market analysis. If a suitable open-source solution exists in the catalogue, the justification for choosing a proprietary alternative becomes significantly harder to defend. If no suitable solution exists, document the search results as part of your justification.

4. Reuse and Collaboration

Article 42 encourages the reuse of software developed by other public bodies.

  • Actionable Step: Before commissioning new software, investigate if a similar solution has already been developed by another Union entity or public sector body. If so, consider adapting and reusing it under an open-source license rather than building a proprietary solution from scratch. This aligns with the goal of reducing duplication and maximizing public value.

5. Strategic Planning for Legacy Systems

While the focus is on new ecosystems, the principle of reducing lock-in applies to digital transformation efforts.

  • Actionable Step: Review existing contracts and ongoing projects to assess the level of vendor lock-in. Consider strategies to introduce open-source components or interoperable standards that allow for easier migration in the future. This "open by design" approach can future-proof your infrastructure against the risks of proprietary dependency.

Common misconceptions

Misconception 1: CADA bans proprietary software in the public sector. This is incorrect. Article 41 encourages open source but explicitly allows proprietary solutions if they are "duly justified" by objective criteria such as security, total cost, or functionality. The goal is to reduce unnecessary dependency, not to eliminate proprietary technology entirely. The Act recognizes that in some cases, proprietary software may be the most effective tool for the job.

Misconception 2: Open source is always cheaper. While open source eliminates licensing fees, it may require higher initial investment in customization, integration, and support. CADA's balancing test requires a total cost analysis, recognizing that proprietary software might be more cost-effective in specific scenarios where development resources are limited, time-to-market is critical, or the proprietary solution offers a more efficient operational model. The "total cost" criterion is the safeguard against blindly choosing open source when it is not economically viable.

Misconception 3: Open source means less security. On the contrary, Recital 81 notes that open source enhances security through transparency and auditability. The ability to inspect the source code allows public authorities to verify security claims and identify vulnerabilities. However, this does not mean all open-source software is automatically secure. Public authorities must still conduct rigorous security assessments, regardless of the licensing model. The "security" criterion in the balancing test allows for proprietary choices only when they demonstrably offer superior security outcomes.

Misconception 4: Only new projects are affected. While the emphasis is on building new ecosystems, the principle of facilitating reuse and reducing lock-in applies to ongoing digital transformation efforts. Public authorities are encouraged to adopt open standards in their existing stacks to ensure long-term interoperability and autonomy. The "open source first" principle is a guiding philosophy for all public digital infrastructure, not just greenfield projects.

Misconception 5: The "Open Source First" principle is a vague recommendation. It is not. Article 41 uses the mandatory language "take the necessary measures to encourage," and the requirement for "duly justified objective criteria" creates a legal obligation to document the decision-making process. Failure to justify a proprietary choice with objective criteria could be seen as non-compliance with the proposed regulation.

Related

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