Summary Under the proposed Cloud and AI Development Act (CADA), public sector bodies must actively encourage the use of open standards and components released under open-source licenses when building their cloud and AI ecosystems. Article 41 establishes an "open source first" principle that is not a rigid ban on proprietary software, but a mandatory weighing exercise. Procurement officers must evaluate open-source options against functionalities, security, total cost of ownership, and other objectively justified criteria. This framework, reinforced by Recital 81, aims to mitigate vendor lock-in, enhance auditability, and strengthen the Union's digital autonomy. Public bodies must also prioritize reusing existing solutions via the EU Open Source Solutions Catalogue (Articles 42–43) and document any deviations from open-source preferences with "duly justified" objective reasoning.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, represents a strategic pivot in EU digital policy, moving beyond mere cybersecurity to address the structural dependencies of the cloud stack. For public sector bodies planning cloud migration, the most significant operational change lies in Article 41, titled "Promoting open source solutions and open source first."

The Legal Mandate: Article 41

Article 41 explicitly states that 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."

Crucially, the text of Article 41 qualifies this encouragement with a balanced assessment framework. It mandates that public bodies take into account:

  • Functionalities: Whether the open-source solution meets the specific technical and operational requirements of the migration.
  • Security: The ability to audit the code and verify the absence of vulnerabilities or backdoors.
  • Total Cost: The full lifecycle cost, not just initial licensing fees.
  • Other relevant, duly justified objective criteria: This allows for flexibility based on specific sectoral needs, such as interoperability or scalability.

This wording ensures that the "open source first" principle is a decision-making heuristic rather than an absolute prohibition. It requires public buyers to start with open-source options and only select proprietary alternatives if they can objectively demonstrate that the open-source route fails to meet the defined criteria.

Strategic Rationale: Avoiding Vendor Lock-In

The legislative intent behind this mandate is clearly articulated in Recital 81 of the explanatory memorandum. The Commission notes 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."

In the context of cloud migration, vendor lock-in is identified as a critical risk. Proprietary architectures often trap public bodies in specific ecosystems, making it difficult to switch providers or modify systems without incurring prohibitive costs or technical debt. By prioritizing open standards and open-source components, CADA aims to ensure that public authorities retain control over their data and applications. This aligns with the broader CADA objective of technological sovereignty, ensuring that the EU's digital infrastructure is not held hostage by the proprietary constraints of a single supplier.

Recital 81 further emphasizes that the choice of software has "significant implications not only for cost-efficiency, but also for security, interoperability, accountability and technological autonomy." Therefore, the "open source first" approach is a mechanism to secure better value for public expenditure and foster a competitive, innovative European market.

The Reuse Ecosystem: Articles 42, 43, and 44

To make the Article 41 mandate actionable, CADA establishes a robust infrastructure for software reuse:

  • Article 42 (Share and reuse of software): When Union entities or public sector bodies make software available for reuse under an open-source license, they must do so via a catalogue or repository connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue). This prevents the fragmentation of public code across disparate national or local repositories.
  • Article 43 (EU Open Source Solutions Catalogue): The Commission is mandated to provide and maintain this centralised catalogue, hosted on the Interoperable Europe portal. It serves as a "one-stop-shop" for public administrations to search for and access software made available for reuse. For cloud migration projects, this means the first step should be a search of the EU OSS Catalogue to identify vetted, existing solutions before commissioning new development.
  • Article 44 (Network of Open Source Programme Offices): To support implementation, CADA establishes a network of Open Source Programme Offices (OSPOs). These offices will facilitate the exchange of best practices, guidance on licensing, and technical challenges related to open-source procurement.

Interaction with Procurement and Sovereignty

The "open source first" principle interacts with CADA's broader procurement framework. Article 32 allows contracting authorities to include non-price award criteria evaluating a tenderer's contribution to the European cloud and AI ecosystem, such as the use of software designed or manufactured in the Union.

However, Recital 67 clarifies that these "European added value" criteria must be "ancillary and not decisive in the award of the contract." They must remain subordinate to core technical and financial criteria. This ensures that the push for open source and sovereignty does not lead to the procurement of inferior solutions. The decision must always be grounded in the "duly justified objective criteria" required by Article 41.

Security and Auditability

A core pillar of the CADA open-source strategy is security. Recital 81 highlights that access to source code enables auditability. In a cloud migration context, this allows public sector bodies to verify that the underlying infrastructure does not contain hidden vulnerabilities or mechanisms that could compromise data confidentiality. This is particularly relevant given CADA's focus on mitigating risks from third-country control. Open-source components allow for independent security audits, ensuring that the cloud environment meets the highest standards of integrity and resilience.

What this means for you

For public-sector procurement officers, CIOs, and migration project managers, the "open source first" mandate under CADA requires a fundamental shift in strategy. Compliance is not about blindly adopting open source, but about rigorously documenting the decision-making process.

  1. Conduct a Comprehensive Total Cost of Ownership (TCO) Analysis: Article 41 explicitly requires weighing "total cost." Do not rely on initial licensing fees. Your analysis must include integration costs, training, maintenance, support contracts, and the potential costs of future migration. If an open-source solution has a lower license fee but requires significant internal expertise to maintain, this must be factored into the TCO. Conversely, if a proprietary solution offers a "total cost" advantage due to managed services, this must be documented.

  2. Prioritize Auditability and Security Verification: Use the open-source mandate to demand transparency. If a vendor proposes a proprietary solution, require detailed security audits, vulnerability disclosure policies, and evidence of code review. If an open-source solution is proposed, verify that the source code is accessible, the project is actively maintained, and the community is robust. Security is a weighted criterion in Article 41; you must assess the actual security posture, not assume open source is inherently superior.

  3. Mandatory Search of the EU OSS Catalogue: Before initiating a new procurement or migration project, you are expected to consult the EU Open Source Solutions Catalogue (Article 43). Reusing existing, vetted components accelerates migration, reduces costs, and ensures interoperability. Documenting this search is a key part of demonstrating compliance with the "reuse" aspect of Article 41.

  4. Engage with Open Source Programme Offices (OSPOs): If your organization lacks internal expertise, engage with the network of OSPOs established under Article 44. These bodies can provide guidance on licensing compatibility, security best practices, and procurement strategies for open-source software.

  5. Document "Duly Justified" Deviations: If you decide to procure a proprietary solution over an open-source alternative, you must document the decision based on "duly justified objective criteria." Your records must clearly explain why the open-source options failed to meet the required functionalities, security standards, or total cost thresholds. This documentation is your primary defense during audits.

  6. Plan for Interoperability and Exit Strategies: Use open standards and open-source components to ensure your cloud architecture is interoperable. This reduces the risk of vendor lock-in and facilitates future migrations or multi-cloud strategies, aligning with the strategic goals of CADA.

Common misconceptions

"Open source first" means we cannot use proprietary software.

  • Reality: Article 41 does not ban proprietary software. It mandates a weighing exercise. Proprietary solutions can be procured if they objectively demonstrate superior functionality, security, or total cost efficiency. The key is that the decision must be "duly justified" based on the criteria in Article 41.

Open source is always cheaper.

  • Reality: While open source often eliminates licensing fees, the "total cost" criterion in Article 41 includes maintenance, support, and integration. In some cases, the total cost of an open-source solution may be higher than a proprietary one if specialized expertise is scarce. The law requires a holistic cost analysis, not a focus on the sticker price.

Open source is inherently more secure.

  • Reality: Open source enables auditability, which is a security enabler, but it does not guarantee security. A poorly maintained open-source project can be less secure than a well-audited proprietary one. Article 41 requires weighing "security" as a specific criterion, meaning you must assess the actual security posture of the specific solution, regardless of its license type.

We must develop all our own open-source software.

  • Reality: Articles 42 and 43 emphasize reuse. Public bodies are encouraged to find and adapt existing solutions in the EU OSS Catalogue rather than building from scratch. The goal is to leverage collective public investment, not to duplicate efforts.

Related

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