Summary Under the proposed Cloud and AI Development Act (CADA), public sector bodies must evaluate software choices based on "total cost" as a primary objective criterion, as explicitly mandated by Article 41. This provision requires moving beyond simple licence fees to account for the full lifecycle of software, including maintenance, support, and crucially, exit costs. By factoring in these long-term expenses, CADA aims to prevent vendor lock-in and ensure "better value for public expenditure," as highlighted in Recital 81. This approach does not mandate an "open source first" rule but demands a rigorous, objective comparison where open source often reveals superior economic efficiency over time.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, represents a strategic shift in how the EU public sector acquires digital technologies. While the Act addresses cloud sovereignty and data-centre capacity, a critical component of its "autonomy" pillar is the procurement of software. Article 41 establishes a specific framework for encouraging the use of open standards and open source components, but it does so through a lens of economic rationality rather than ideological preference.

The Mandate of Article 41: Total Cost as a Core Criterion

Article 41 of the CADA proposal places a clear obligation on the Union and Member States. It requires them 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. However, this encouragement is not unconditional; it is bound by the requirement to consider specific objective criteria.

The text of Article 41 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."

The inclusion of "total cost" alongside "functionalities" and "security" is a deliberate legislative choice. In traditional public procurement, the "lowest price" or "upfront acquisition cost" often dominates decision-making. This frequently leads to the selection of proprietary solutions with low entry prices but high long-term costs due to recurring licence fees, mandatory upgrades, and restrictive terms. By elevating "total cost" to a statutory criterion, CADA as proposed forces a shift toward Total Cost of Ownership (TCO) analysis.

Deconstructing "Total Cost" in the CADA Context

While Article 41 does not provide a granular definition of "total cost," the legislative intent and the broader context of the Act clarify that this refers to the comprehensive economic burden of a software solution over its entire lifecycle. This concept encompasses several distinct cost categories that are often overlooked in standard tender evaluations:

1. Beyond Licence Fees: The Hidden Costs of Proprietary Software

Proprietary software models often rely on "freemium" or low-entry pricing strategies to secure market share, only to recover costs through recurring subscription fees, mandatory maintenance contracts, and expensive upgrade paths. Under a TCO analysis mandated by CADA, these recurring costs are weighed against the one-time or lower recurring costs of open source alternatives.

  • Licence vs. Service: Proprietary costs are often tied to the number of users or cores, scaling linearly with growth. Open source costs, conversely, are often decoupled from usage volume, shifting the cost burden to implementation and support services rather than the software itself.
  • Upgrade Lock-in: Proprietary vendors may force upgrades to maintain security or compatibility, incurring significant migration and retraining costs. Open source solutions, by contrast, allow public bodies to control the upgrade cycle.

2. Maintenance and Support Costs

A critical component of TCO is the cost of keeping the software operational.

  • Vendor Support: For proprietary systems, this typically involves paying the vendor for support contracts, which can be expensive and subject to price hikes.
  • Internal/Third-Party Support: For open source, public bodies may choose to maintain the software internally or contract third-party support providers. CADA encourages evaluating which model offers greater stability and cost predictability. The "total cost" criterion requires buyers to compare the cost of a vendor-mandated support contract against the cost of a competitive market for open source support services.

3. Exit Costs and the Cost of Vendor Lock-in

Perhaps the most significant element of TCO under CADA is the cost of exit. Vendor lock-in occurs when a public body becomes so dependent on a specific vendor's proprietary format, API, or ecosystem that switching providers becomes prohibitively expensive or technically impossible.

  • Migration Costs: Leaving a proprietary ecosystem often requires complex data migration, retraining staff, and rewriting integrations.
  • Legal and Negotiation Costs: Exiting a contract may involve negotiating exit fees or navigating complex legal disputes.
  • The Open Source Advantage: Open source solutions, by definition, provide access to the source code and typically rely on open standards. This drastically reduces exit costs, as the public body retains the ability to switch providers or maintain the software in-house. Article 41 implicitly recognizes that the "total cost" of a proprietary solution must include the risk premium of being locked in.

Recital 81: The Economic Rationale for Better Value

The philosophical and economic justification for Article 41 is found in Recital 81 of the CADA proposal. This recital explicitly links the promotion of open source to the efficient use of public funds. It states:

"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. In that context, the choice of cloud computing services or software has significant implications not only for cost-efficiency, but also for security, interoperability, accountability and technological autonomy."

Recital 81 clarifies that "total cost" is not merely an accounting exercise but a strategic tool to achieve "better value for public expenditure." It argues that the benefits of open source extend beyond immediate cost savings to include:

  • Security: Through the ability to audit source code.
  • Interoperability: Through adherence to open standards.
  • Accountability: Through transparency in development.
  • Technological Autonomy: By reducing reliance on single vendors who may be subject to third-country control.

By mandating the consideration of "total cost," CADA ensures that public procurement decisions contribute to these broader strategic goals. A solution that is cheaper upfront but locks the public sector into a proprietary ecosystem fails the "total cost" test because it undermines long-term autonomy and creates hidden future liabilities.

Integration with Broader CADA Procurement Measures

The "total cost" criterion in Article 41 does not operate in isolation; it is part of a cohesive procurement strategy within CADA.

  • Union Added Value (Article 32): Article 32 allows contracting authorities to include non-price award criteria that evaluate a tenderer's contribution to the European cloud and AI ecosystem. When combined with Article 41, public buyers can prioritize European open source solutions that offer both strategic sovereignty (Union added value) and economic efficiency (total cost).
  • Reuse and the EU OSS Catalogue (Article 42): Article 42 requires public sector bodies to make software available for reuse via the EU Open Source Solutions Catalogue. This directly impacts TCO by reducing the need to develop new software from scratch. Reusing existing, vetted open source solutions significantly lowers development and maintenance costs, improving the TCO for future projects.
  • Innovation Procurement (Article 33): CADA encourages the procurement of innovation, with a target of awarding at least 25% of relevant procedures to SMEs. Open source solutions, often developed by agile SMEs, are well-positioned to meet these targets while offering competitive TCO compared to large proprietary incumbents.

What this means for you

For public-sector procurement officers, IT directors, and policy makers, the proposed Article 41 of CADA requires a fundamental restructuring of how software tenders are designed and evaluated. The era of selecting software based solely on the lowest initial bid is over.

1. Redefine Evaluation Criteria

You must explicitly include "total cost" as a weighted criterion in your procurement documents. This means moving away from evaluating only the initial purchase price or annual licence fees. Your evaluation methodology must account for the entire lifecycle of the software, including:

  • Implementation costs: Customization, integration, and data migration.
  • Training costs: Staff upskilling for new interfaces or architectures.
  • Maintenance costs: Ongoing support, patches, and updates.
  • Exit costs: The estimated cost of migrating away from the solution in 5 or 10 years.

2. Conduct Rigorous Lifecycle Cost Analysis

When assessing bids, perform a detailed TCO analysis for both open source and proprietary options.

  • For Proprietary Solutions: Factor in the risks of price increases, mandatory upgrades, and the potential for vendor lock-in. Calculate the cost of being unable to switch providers.
  • For Open Source Solutions: Account for the costs of customization, internal resource allocation, and third-party support. Do not assume "free" means "zero cost"; assume "free" means "costs are shifted to services and expertise."
  • The Comparison: The goal is to identify which model offers greater long-term stability and cost predictability. Often, the open source option will show a lower TCO over a 5-10 year horizon, even if the upfront implementation cost is higher.

3. Prioritize Interoperability and Exit Strategies

Given the emphasis on reducing vendor lock-in, your procurement specifications should prioritize solutions that adhere to open standards and provide full access to source code.

  • Open Standards: Ensure the software uses open data formats and APIs to prevent data silos.
  • Exit Clauses: Include contractual clauses that guarantee data portability and the right to access source code in the event of vendor insolvency or contract termination.
  • Justification: If you choose a proprietary solution, you must be prepared to justify why its "total cost" (including exit risks) is lower than an open source alternative, based on "duly justified objective criteria."

4. Leverage the EU OSS Catalogue

Utilize the EU Open Source Solutions Catalogue to identify existing open source software that meets your needs. Reusing existing solutions can significantly reduce development and maintenance costs, improving the TCO of your project. Article 42 mandates that any software you develop and release as open source must be listed in this catalogue, facilitating future reuse by other public bodies and creating a virtuous cycle of cost reduction.

5. Document Objective Justifications

Article 41 requires that the choice between open source and proprietary software be based on "duly justified objective criteria." Ensure that your procurement decisions are well-documented, with clear evidence supporting the TCO analysis. This transparency will help defend your decisions against challenges and demonstrate compliance with CADA's objectives.

Common misconceptions

"CADA mandates 'Open Source First'."

  • Reality: CADA does not impose a strict "open source first" obligation. Article 41 encourages the use of open source but requires that decisions be based on objective criteria, including functionality, security, and total cost. Proprietary solutions can still be chosen if they demonstrably offer better value in these areas, provided the decision is objectively justified.

"Open source is always cheaper."

  • Reality: While open source often eliminates licence fees, it may require higher initial investments in customization, implementation, and internal expertise. CADA's focus on "total cost" acknowledges this by requiring a comprehensive lifecycle analysis, not just a comparison of upfront prices. The goal is to find the best value, not necessarily the cheapest option.

"Total cost only refers to financial expenses."

  • Reality: While financial costs are central, Recital 81 links cost-efficiency to security, interoperability, and technological autonomy. Therefore, "total cost" implicitly includes the risks and costs associated with vendor lock-in, security vulnerabilities, and lack of interoperability. A solution that is financially cheap but creates a strategic dependency may have a high "total cost" in the broader sense intended by CADA.

"Article 41 replaces existing procurement rules."

  • Reality: Article 41 complements existing EU public procurement directives. It adds specific criteria for evaluating open source solutions but does not override the general principles of transparency, non-discrimination, and proportionality required in public procurement. It refines how value is measured, not the fundamental rules of the game.

Related

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