Summary No, open source is not strictly mandatory under the proposed Cloud and AI Development Act (CADA). As proposed, Article 41 requires the Union and Member States to "encourage and facilitate" the use of open standards and open-source components, but it explicitly stops short of an absolute legal obligation. Procurement decisions must remain grounded in a balanced assessment of "functionalities, including security, total cost, and other relevant, duly justified objective criteria." This creates a strong preference for open source without banning proprietary alternatives where they offer superior value.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, represents a strategic shift in how the EU approaches its digital infrastructure. A central pillar of this strategy is the promotion of open-source software to reduce vendor lock-in, enhance transparency, and foster technological sovereignty. However, for public-sector procurement officers, legal counsel, and IT strategists, the precise legal weight of these provisions is critical. The proposal does not impose a "hard mandate" requiring the exclusive use of open source; rather, it establishes a "soft mandate" or a strong policy direction that must be weighed against practical operational realities.

The Legal Text: Article 41

The definitive provision governing this issue is Article 41 of the CADA proposal, titled "Promoting open source solutions and open source first." The full text of the article is precise in its wording:

"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 language is deliberately permissive rather than prohibitive. The use of the verb "encourage" signifies a policy direction rather than a rigid compliance rule. It obligates public authorities to actively promote and create conditions favorable for open-source adoption, but it does not strip them of the discretion to choose proprietary solutions. The phrase "open source first" in the article title reflects a presumption in favor of open source, but the operative text clarifies that this presumption is rebuttable.

Key Decision Criteria: The "Total Cost" and "Functionality" Test

Article 41 explicitly lists the factors that procurement officers must consider when deciding whether to adopt open-source solutions. These criteria ensure that the decision remains grounded in technical and economic reality rather than ideological preference. The proposal mandates that any decision to use open source (or to reject it) must be "duly justified" based on the following:

  1. Functionalities: The solution must meet the specific technical requirements of the project. Open-source software must be capable of delivering the necessary features, performance levels, and interoperability. If a proprietary solution offers a critical functionality that no open-source alternative can match, Article 41 permits the selection of the proprietary option.
  2. Security: Security is a paramount concern, particularly in the context of CADA's broader goals of sovereignty and data protection. While open-source solutions often benefit from community-driven auditing and transparency, the proposal recognizes that security is not exclusive to open source. Procurement officers must evaluate whether the open-source option meets the required security standards, which may sometimes be more easily certified or supported by a proprietary vendor.
  3. Total Cost: This refers to the Total Cost of Ownership (TCO), not merely the initial license fee. The proposal explicitly requires consideration of "total cost." While open-source software often has no upfront licensing cost, it may incur higher costs for specialized support, maintenance, integration, training, and long-term evolution. Conversely, proprietary solutions may offer bundled support that lowers the TCO. Article 41 ensures that the decision is based on a holistic financial analysis, not just the absence of a license fee.
  4. Other Relevant, Duly Justified Objective Criteria: This catch-all phrase allows procurement officers to consider other legitimate factors, such as time-to-market, vendor support availability, specific regulatory compliance requirements, or the need for specialized hardware integration. The key is that these criteria must be "duly justified" and "objective," preventing arbitrary decisions.

Contrast with Hard Procurement Mandates

It is crucial to distinguish CADA's approach from a "hard mandate." A hard mandate would require public bodies to purchase only open-source software, regardless of other factors, effectively banning proprietary solutions. CADA does not do this. Instead, it aligns with the broader EU public procurement framework, which emphasizes value for money, competition, and the best economic offer.

The proposal complements other EU laws, such as the Data Act and the Digital Markets Act, which focus on interoperability and reducing vendor lock-in. By encouraging open standards and open-source components, CADA aims to reduce dependencies on single vendors and enhance the resilience of the EU's digital ecosystem. However, it acknowledges that proprietary solutions may still offer unique advantages in certain contexts, such as specialized hardware integration, specific security certifications, or niche applications where the open-source ecosystem is not yet mature.

The Supporting Ecosystem: Catalogues and OSPOs

To support the implementation of Article 41 without imposing a rigid mandate, CADA introduces complementary mechanisms:

  • The EU Open Source Solutions Catalogue (Article 43): This centralized catalogue, hosted on the Interoperable Europe portal, will list software made available for reuse by Union entities and public sector bodies. While not mandatory, this catalogue serves as a practical tool for procurement officers to discover vetted, reusable open-source solutions, thereby reducing duplication of effort and fostering innovation.
  • Open Source Programme Offices (OSPOs) (Article 44): CADA establishes a network of OSPOs to facilitate cooperation on the implementation of open-source obligations. These offices will promote the sharing and reuse of open-source software, provide guidance on licensing, security, and procurement, and help public bodies navigate the complexities of open-source adoption. Their function is advisory and facilitative, not regulatory.

What this means for you

For public-sector procurement officers, legal advisors, and IT strategists, the implications of Article 41 are significant but nuanced. You are not required to reject proprietary solutions outright, but you must demonstrate that open-source options were seriously considered and evaluated against the criteria set out in the proposal.

Practical Steps for Procurement Officers

  1. Conduct a Balanced Assessment: When drafting procurement specifications, explicitly include open-source options as viable alternatives. Evaluate them alongside proprietary solutions based on functionalities, security, TCO, and other objective criteria. Do not assume open source is automatically the best choice; let the data drive the decision.
  2. Document Your Decision-Making: If you decide to procure a proprietary solution, ensure that your decision is "duly justified." Document why the open-source alternatives did not meet the required functionalities, security standards, or cost-effectiveness. This documentation will be crucial for compliance audits and potential challenges. The burden of proof lies in showing that the "total cost" or "functionalities" criteria favored the proprietary option.
  3. Leverage the EU OSS Catalogue: Use the EU Open Source Solutions Catalogue to identify reusable software components that can be integrated into your projects. This can reduce development costs and time-to-market while aligning with CADA's goals.
  4. Engage with OSPOs: Collaborate with your national or organizational Open Source Programme Office to gain insights into best practices for open-source procurement, licensing, and security. OSPOs can provide valuable guidance on navigating the complexities of open-source adoption.

Strategic Implications

CADA's approach to open source is part of a broader strategy to enhance technological sovereignty and reduce dependencies on non-European providers. By encouraging the use of open standards and open-source components, the EU aims to foster a more competitive and resilient digital ecosystem. For procurement officers, this means that open-source solutions will likely become increasingly prominent in public-sector IT projects. However, the final decision will always depend on a careful assessment of the specific needs and constraints of each project. The "open source first" principle is a starting point for analysis, not a final verdict.

Common misconceptions

Misconception 1: CADA bans proprietary software. This is incorrect. Article 41 encourages the use of open-source solutions but does not prohibit proprietary software. Procurement officers can still choose proprietary solutions if they offer better value in terms of functionality, security, or total cost, provided the decision is duly justified.

Misconception 2: Open source is always cheaper. While open-source software often has no upfront licensing cost, the total cost of ownership can be higher due to expenses related to support, maintenance, integration, and training. Article 41 explicitly requires procurement officers to consider the "total cost," not just the initial price. A proprietary solution with a license fee might actually be cheaper in the long run if it includes comprehensive support and reduces integration time.

Misconception 3: Open source is inherently more secure. Open-source software can be highly secure due to its transparency and community-driven auditing. However, it is not inherently more secure than proprietary software. Security depends on various factors, including the quality of the code, the responsiveness of the maintainer community, and the implementation of security best practices. Article 41 requires procurement officers to evaluate security as a key criterion, regardless of the licensing model.

Misconception 4: CADA requires all public software to be open-sourced. Article 42 encourages the sharing and reuse of software developed by or for Union entities and public sector bodies under an open-source licence. However, this is not an absolute mandate. Public bodies are encouraged to make their software available for reuse, but they are not required to do so in every case. The decision to open-source software should be based on a careful assessment of the public interest, intellectual property rights, and other relevant factors.

Official sources

Related

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