How does a public body apply CADA's open source first principle?

Under the proposed Cloud and AI Development Act (CADA), public bodies are legally required to encourage and facilitate the use of open standards and compon

Summary Under the proposed Cloud and AI Development Act (CADA), public bodies are legally required to encourage and facilitate the use of open standards and components released under open-source licences when constructing their cloud and AI ecosystems. Article 41 establishes an "open source first" principle, mandating that decision-makers weigh functionality, security, and total cost alongside other justified objective criteria, rather than defaulting to proprietary solutions. This obligation aims to reduce vendor lock-in, enhance transparency, and strengthen the Union's digital autonomy. As a proposal, these rules would apply once adopted, requiring public entities to integrate these criteria into procurement and development workflows immediately upon entry into force.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a transformative mandate for the public sector to prioritise open-source solutions within its digital infrastructure. This is not merely a soft recommendation but a binding obligation for Union entities and Member State public sector bodies, designed to shift the procurement and development culture towards greater transparency, interoperability, and strategic autonomy.

The Legal Basis: Article 41

The core provision governing this requirement is Article 41 of the CADA proposal, titled "Promoting open source solutions and open source first." The text explicitly states:

"The Union and Member States shall 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, taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

This article establishes a clear hierarchy of preference. When public bodies are designing, procuring, or developing their cloud and AI stacks, they must actively encourage the use of open standards and open-source components. The phrase "open source first" implies that open-source solutions should be the default starting point for consideration, rather than an afterthought or a niche alternative. The obligation applies to the entire "ecosystem or stack," covering everything from underlying infrastructure software to AI models and application layers.

Key Criteria for Evaluation

Article 41 does not demand the blind adoption of open-source software regardless of quality or suitability. Instead, it requires a balanced, evidence-based assessment. Public sector bodies must consider the following specific criteria when evaluating options:

Functionalities: The solution must meet the technical and operational requirements of the intended use case. The open-source option must be capable of performing the necessary tasks as effectively as proprietary alternatives.
Security: The security posture of the open-source component must be rigorously evaluated. This includes the ability to audit source code, the responsiveness of the maintainer community to vulnerabilities, the frequency of updates, and the overall resilience of the software against cyber threats. Security is explicitly listed as a primary factor, ensuring that openness does not come at the expense of safety.
Total Cost: This criterion is critical and goes beyond the initial acquisition price (which is often zero for open-source software). It encompasses the total cost of ownership (TCO), including costs for implementation, integration, training, maintenance, support contracts, and potential licensing fees for proprietary alternatives. The proposal explicitly requires weighing "total cost," acknowledging that while licence fees may be lower, support and integration costs must be factored in.
Other Relevant, Duly Justified Objective Criteria: This catch-all provision allows for considerations such as interoperability with existing systems, compliance with data sovereignty requirements (such as the Union assurance levels defined in CADA), sustainability, accessibility, and the availability of local talent or support ecosystems. Any deviation from the open-source preference must be based on these "duly justified" criteria.

Strategic Objectives

The rationale behind Article 41 is rooted in the broader goals of the CADA, particularly the need to reduce dependencies on critical technologies and strengthen the Union's technological sovereignty. The explanatory memorandum and recitals highlight several key benefits that this principle seeks to unlock:

Reducing Vendor Lock-in: Proprietary software often creates deep dependencies on specific vendors, making it difficult and expensive to switch providers or migrate data. Open-source solutions, by contrast, provide access to the underlying code, allowing public bodies to adapt, modify, or migrate services more freely, thereby preserving market contestability.
Enhancing Transparency and Security: Access to source code enables auditability. Public bodies can verify that the software does not contain backdoors, malicious code, or hidden functionalities that could compromise security or privacy. This is particularly crucial for cloud and AI systems that process sensitive data or support critical public functions.
Fostering Collaboration and Reuse: Open-source components encourage collaboration across the public sector. Solutions developed by one entity can be reused by others, reducing duplication of effort and maximizing the value of public expenditure. This aligns with the CADA's provisions on sharing and reusing software (Article 42) and the establishment of the EU Open Source Solutions Catalogue (Article 43).
Strengthening Digital Autonomy: By promoting open standards and open-source technologies, the EU aims to build a more resilient and autonomous digital ecosystem. This reduces reliance on non-EU providers and supports the development of a competitive European cloud and AI market, ensuring that the Union retains control over its digital destiny.

Implementation Measures

To ensure that Article 41 is effectively implemented, the CADA requires the Union and Member States to take "necessary measures." These measures may include:

Procurement Guidelines: Updating public procurement rules to include open-source criteria and to ensure that open-source solutions are treated fairly and equally with proprietary alternatives in tender evaluations.
Capacity Building: Providing training and resources to public sector staff to develop the skills needed to evaluate, implement, and maintain open-source solutions.
Support Structures: Establishing Open Source Programme Offices (OSPOs) within public bodies to manage open-source strategies, as outlined in Article 44. The OSPO network will facilitate the exchange of best practices and support the implementation of open-source obligations.
Catalogue Integration: Encouraging the listing of open-source software on the EU Open Source Solutions Catalogue (Article 43) to improve discoverability and reuse across the Union.

What this means for you

For public-sector and procurement officers, Article 41 introduces a significant shift in how cloud and AI projects are evaluated and procured. You are no longer permitted to default to proprietary solutions without a rigorous justification. Instead, you must actively consider open-source alternatives and demonstrate that your final decision is based on a holistic assessment of functionality, security, and total cost.

Practical Steps for Compliance

Integrate Open Source into Needs Assessment: From the outset of a project, identify whether open-source components can meet the functional requirements. Engage with technical experts to evaluate the maturity, security, and support ecosystem of potential open-source solutions. Do not assume proprietary is the only viable option.
Conduct Total Cost of Ownership (TCO) Analysis: When comparing open-source and proprietary options, calculate the full TCO. This includes costs for implementation, integration, training, maintenance, and potential commercial support contracts. Avoid focusing solely on licensing fees, as open-source software may have higher implementation costs but lower long-term ownership costs, or vice versa. The decision must be based on the total cost.
Evaluate Security Rigorously: Assess the security posture of open-source components. Look for active maintainer communities, regular security updates, and the availability of commercial support or indemnification if needed. Ensure that the open-source solution complies with the relevant Union assurance levels for cloud computing services, as required by other parts of the CADA.
Document Your Decision-Making: Keep detailed records of why a particular solution was chosen. If a proprietary solution is selected over an open-source alternative, you must provide a duly justified explanation based on the objective criteria outlined in Article 41 (e.g., specific functionality gaps, security risks, or prohibitive total costs). This documentation will be crucial for audits and compliance checks.
Leverage the OSPO Network: If your organisation has an Open Source Programme Office (OSPO), involve them early in the process. They can provide guidance on licensing, security best practices, and integration strategies. If you do not have an OSPO, consider establishing one or collaborating with existing networks to build internal expertise, as mandated by Article 44.
Check the EU OSS Catalogue: Before procuring new software, check the EU Open Source Solutions Catalogue (Article 43) to see if suitable open-source alternatives are already available and vetted. This can save time and resources while promoting reuse across the public sector.

Impact on Procurement Processes

Procurement procedures will need to be adapted to ensure that open-source solutions are not disadvantaged. Technical specifications should be written in a technology-neutral manner, focusing on functional requirements rather than specific proprietary features. Evaluation criteria should reflect the importance of openness, interoperability, and long-term sustainability. The "open source first" principle means that the burden of proof shifts: if a public body chooses a proprietary solution, it must demonstrate why an open-source alternative was not suitable based on the criteria in Article 41.

Common misconceptions

Misconception 1: Open source means free of charge. While many open-source licences allow for free use, "open source" refers to the availability of source code, not necessarily the price. Commercial support, hosting, and maintenance may incur costs. Article 41 requires considering the total cost, not just the license fee. A proprietary solution might be cheaper in the short term, but an open-source solution might offer lower total cost of ownership over time.

Misconception 2: Open source is less secure than proprietary software. This is a common but outdated belief. Open-source software can be more secure because its code is open to scrutiny by a global community of developers, who can identify and fix vulnerabilities quickly. However, security depends on active maintenance and proper management. Article 41 explicitly lists security as a key criterion to evaluate, ensuring that only robust open-source solutions are selected. If an open-source project is abandoned or poorly maintained, it may fail the security criterion.

Misconception 3: Open source first means you must always choose open source. Article 41 requires encouraging and facilitating the use of open-source solutions, but it also allows for exceptions based on "duly justified objective criteria." If a proprietary solution demonstrably offers superior functionality, security, or cost-effectiveness for a specific use case, it can be chosen. The key is to justify the decision objectively and document the reasoning. The principle is a presumption in favour of open source, not an absolute mandate.

Misconception 4: This only applies to new projects. While new projects are the primary focus, the obligation to encourage and facilitate reuse applies broadly. Existing systems should be evaluated for opportunities to migrate to open-source components where feasible, particularly when contracts are up for renewal or when significant upgrades are planned. The goal is to shift the entire public sector ecosystem over time.

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