Summary As proposed, the Cloud and AI Development Act (CADA) establishes a strategic mandate for the Union and Member States to encourage public-sector bodies to prioritize open-source solutions and open standards when building their cloud and AI ecosystems. Article 41 requires authorities to "encourage" the use and reuse of open-source components, explicitly linking this to the reduction of dependency on single vendors and the strengthening of "technological autonomy." Recital 81 clarifies that access to source code is a critical sovereignty hedge: it enables auditability, fosters collaboration, and limits the risk of vendor lock-in. This approach is not a blanket ban on proprietary software but a targeted mechanism to ensure that critical public infrastructure remains transparent, interoperable, and resilient against foreign control or opaque supply chains.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, integrates open source not merely as a technical preference but as a foundational pillar of the EU's digital sovereignty strategy. While the Act's most visible mechanisms are the four-tier "Union assurance levels" for cloud services, the legislative text recognizes that true autonomy cannot be achieved if the underlying software stack remains opaque or controlled by a single proprietary entity.

The Mandate: Article 41 and the "Open Source First" Principle

The core obligation is found in Article 41, titled "Promoting open source solutions and open source first." This article imposes a binding duty 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, the text does not demand an absolute prohibition of proprietary software. Instead, it requires a balanced approach. The article stipulates that this encouragement must take into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria." This ensures that the push for open source does not compromise operational efficiency or security. Public bodies must weigh the benefits of open source against the specific needs of their services, but the default policy direction is to favor open standards and components where feasible.

The Rationale: Recital 81 and the Sovereignty Hedge

The legislative intent behind this mandate is explicitly detailed in Recital 81. The recital frames open source as a critical tool for mitigating the risks associated with the current concentration of the cloud market. It states that open source "plays an important role in ensuring transparency, security and efficiency in the use of digital technologies by the public sector."

The recital identifies three specific sovereignty benefits:

  1. Auditability: Access to the source code "enables auditability," allowing public authorities and independent experts to verify that the software does not contain backdoors, malicious code, or hidden mechanisms that could compromise security.
  2. Collaboration and Reuse: It "fosters collaboration and reuse," preventing the duplication of effort across different public administrations and allowing for the rapid iteration of secure solutions.
  3. Reducing Vendor Lock-in: Most significantly for sovereignty, it "reduces dependency on a single vendor, thereby limiting the risk of vendor lock-in."

Recital 81 further emphasizes that the choice of software has profound implications for "security, interoperability, accountability and technological autonomy." By relying on proprietary, closed-source solutions from a limited pool of third-country providers, the EU risks exposing its critical infrastructure to unilateral decisions by foreign actors. Open source acts as a "sovereignty hedge" by ensuring that the code governing public services is accessible, modifiable, and not held hostage by a single commercial entity.

Integration with the Broader Sovereignty Framework

CADA's open-source provisions are not isolated; they are deeply interwoven with the Act's broader sovereignty architecture, particularly the Union assurance levels defined in Annex II.

  • Supporting Assurance Levels 2, 3, and 4: The criteria for higher assurance levels (which are mandatory for public-order-relevant activities under Article 30) include strict requirements for software supply chain transparency. Annex II requires providers to demonstrate the absence of remote features that could "materially tamper with or disrupt a device, system, or software." Open source is the most effective mechanism to prove this, as it allows for independent verification of the code.
  • The EU Open Source Solutions Catalogue: Article 42 reinforces the ecosystem by requiring that when Union entities or public sector bodies make software available for reuse under an open-source license, they must do so via a catalogue connected to the EU Open Source Solutions Catalogue (established under Article 43). This creates a centralized, searchable repository of sovereign software, facilitating reuse across the Union and preventing the "reinvention of the wheel."
  • The OSPO Network: Article 44 establishes a network of Open Source Programme Offices (OSPOs) to facilitate cooperation, exchange best practices, and address common legal and technical challenges. This ensures that public bodies have the expertise necessary to navigate the complexities of open-source licensing and security.

Avoiding Foreign Dependency

The push for open source is a direct response to the market realities described in the Explanatory Memorandum and Recital 4. The EU currently relies heavily on a "limited pool of third-country providers," with three non-EU hyperscalers controlling over 70% of the European cloud market. This dependence exposes the Union to risks of operational discontinuity and extraterritorial legal access.

By fostering a robust open-source ecosystem, CADA aims to:

  • Diversify the Supply Chain: Enable a wider range of European providers to compete, reducing the market share of non-EU incumbents.
  • Ensure Interoperability: Open standards prevent the "walled garden" effect of proprietary ecosystems, allowing public bodies to switch providers or adopt multi-cloud strategies more easily.
  • Enhance Resilience: As noted in Article 29, risk assessments for public procurement should consider multi-vendor strategies. Open source is a key enabler of such strategies, ensuring that no single vendor can disrupt service continuity.

What this means for you

For public-sector procurement officers, IT directors, and policy makers, CADA introduces a strategic shift in how software and cloud services are evaluated. You are no longer just buying a product; you are contributing to the EU's strategic autonomy.

  1. Prioritize Open Source in Tenders: When drafting procurement documents for cloud or AI systems, you must include criteria that favor open standards and open-source components. While you are not required to buy only open source, you must actively "encourage" its use. Justify your decisions based on the ability to audit code, the freedom to modify it, and the availability of the source code.
  2. Evaluate Vendor Lock-in Risks: Assess potential suppliers based on their openness. Proprietary solutions that restrict access to source code or impose restrictive licensing terms may pose higher sovereignty risks. Use the criteria in Article 41 to justify decisions that favor open-source alternatives, particularly when security and long-term autonomy are concerns.
  3. Utilize the EU OSS Catalogue: When developing or commissioning software for public use, consider releasing it under an open-source license. If you do, you must list it in the EU Open Source Solutions Catalogue (Article 42). This increases the value of public expenditure by allowing other public bodies to reuse your solutions.
  4. Engage with OSPOs: Connect with your national or local Open Source Programme Office (OSPO). Article 44 establishes a network of these offices to provide guidance on licensing, security, and procurement. They can help you navigate the legal and technical complexities of integrating open-source components into your cloud stack.
  5. Conduct Thorough Risk Assessments: When determining the appropriate Union assurance level for a cloud service (Article 29), consider how the underlying software's licensing and accessibility impact sovereignty. Open-source solutions may offer greater transparency and control, which can be a mitigating factor in your risk assessment.

Common misconceptions

"CADA bans proprietary software." This is incorrect. CADA encourages the use of open source but does not prohibit proprietary solutions. Article 41 requires authorities to encourage open source, taking into account functionalities, security, and cost. Proprietary solutions can still be procured if they offer superior functionality or security that cannot be achieved with open-source alternatives, provided this is "duly justified."

"Open source automatically equals sovereignty." Not necessarily. While open source reduces vendor lock-in and improves auditability, it does not automatically guarantee compliance with CADA's sovereignty assurance levels. A cloud service built on open-source components can still be controlled by a third-country entity, subject to foreign laws, or have data hosted outside the EU. Open source is a tool for sovereignty, but providers must still meet the specific criteria of the Union assurance levels (e.g., data localization, personnel citizenship) to be recognized as sovereign.

"Open source is always cheaper." While open source can reduce licensing costs, it may involve higher initial investment in customization, integration, and support. Article 41 explicitly requires authorities to consider "total cost" and other objective criteria. Procurement officers must evaluate the total cost of ownership, including support and maintenance, rather than assuming open source is inherently less expensive.

"I can use any open-source license." Public sector bodies must be careful with licensing. Some open-source licenses have copyleft requirements that may conflict with proprietary components or impose restrictions on redistribution. The OSPO network (Article 44) is designed to help navigate these complexities. Authorities should prefer licenses that are compatible with public sector reuse and do not create legal ambiguities.

Related

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