Summary Under the proposed Cloud and AI Development Act (CADA), open standards and open source are distinct but complementary mechanisms for strengthening Europe's digital autonomy. Open standards are technical specifications that ensure interoperability between systems, while open source refers to software code released under a licence that permits access, modification, and redistribution. Article 41 of the proposal explicitly encourages Union entities and public sector bodies to use and facilitate the reuse of both, requiring decision-makers to weigh them based on functionalities, security, and total cost to reduce vendor lock-in and enhance transparency.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, aims to reduce the European Union's dependence on third-country cloud providers by fostering a resilient, sovereign, and competitive domestic ecosystem. A cornerstone of this strategy is the promotion of openness in software and infrastructure. While the terms "open standards" and "open source" are often conflated in general technology discourse, CADA treats them as separate, complementary pillars of a sovereign stack.

The Legal Basis: Article 41

The primary provision governing this distinction is Article 41, titled "Promoting open source solutions and open source first." This article mandates that the Union and Member States take necessary measures to encourage Union entities and public sector bodies to:

  1. Use and facilitate the reuse of open standards.
  2. Use and facilitate the reuse of components released under an open source licence.

The article specifies that this encouragement applies "when building their cloud and AI ecosystem or stack." Crucially, it requires decision-makers to take into account specific criteria, including "functionalities, including security, total cost, and other relevant, duly justified objective criteria." This language ensures that the push for openness is pragmatic and not dogmatic, allowing for exceptions where proprietary solutions might offer superior security or cost-efficiency in specific contexts.

Defining the Distinction

To understand the practical impact of CADA, it is essential to distinguish between the two concepts as they function within the regulatory framework.

1. Open Standards (The "What" and "How") Open standards are publicly available specifications that define how systems should interact. They are protocol-agnostic and vendor-neutral. In the context of CADA, open standards ensure that different components of a cloud or AI stackβ€”whether developed by different providersβ€”can communicate seamlessly.

  • Role in CADA: They prevent fragmentation and ensure that the European cloud stack is interoperable. By adhering to open standards, public bodies ensure that their infrastructure is not tied to a single proprietary technology that might become obsolete or subject to unilateral changes by a third-country vendor.
  • Nature: They are the rules of the road. They define the interfaces, data formats, and communication protocols.
  • Example: An open standard might define the API structure for data exchange between a public health database and an AI diagnostic tool, regardless of which company built the database or the AI model.

2. Open Source (The "Code") Open source refers to software whose source code is made available to the public under a licence that permits its use, modification, and redistribution. CADA references "components released under an open source licence," drawing on the definition provided in Article 2(25), which refers to the definition in the Interoperable Europe Act (Regulation (EU) 2024/903).

  • Role in CADA: Open source provides auditability and transparency. It allows public authorities to inspect the code for security vulnerabilities, backdoors, or non-compliant data handling practices. It also enables "forking" or customisation if a vendor discontinues support, thereby mitigating operational continuity risks.
  • Nature: It is the implementation. It is the actual code that executes the logic defined by the standards.
  • Example: A Linux-based operating system or a specific open-source AI library used to train a public sector model.

Complementary Roles in Sovereignty

CADA does not view these two concepts in isolation. The explanatory memorandum and recitals highlight that open source is a "lever to boost technological sovereignty." However, open source alone is insufficient if the underlying protocols are proprietary. Conversely, open standards are ineffective if the implementations are closed and opaque.

Article 41 bridges this gap by requiring a holistic approach. When building a cloud or AI stack, public bodies are encouraged to look for solutions that are both standard-compliant and open-source licensed. This dual approach ensures:

  • Interoperability: Through open standards, ensuring different systems can talk to each other.
  • Transparency and Control: Through open source code, ensuring the logic is visible and modifiable.

The proposal explicitly recognises that these roles are complementary. Open standards ensure that the "plumbing" of the digital economy is universal, while open source ensures that the "machinery" running on that plumbing is transparent and controllable by the Union.

Practical Application in Procurement and Ecosystem Building

The proposal links these concepts to procurement practices and ecosystem development. While Article 41 uses the term "encourage," the broader context of Title IV (Autonomy) and the Cloud Computing Sovereignty Framework (Articles 16–33) creates a strong incentive for public bodies to prioritise open solutions.

For instance, Article 32 introduces "Union added value" criteria in public procurement. A tenderer's contribution to strengthening the digital technology supply chain in the Union can be evaluated. Solutions built on open standards and open source often score higher here because they demonstrate less reliance on single-vendor proprietary ecosystems and more integration with European technological capabilities.

Furthermore, Article 42 and Article 43 reinforce the open source aspect by requiring that when public bodies make software available for reuse, it must be done via a catalogue connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue). This creates a feedback loop where public sector investment in open source yields reusable assets for the wider ecosystem, provided they adhere to compatible standards.

Article 44 further establishes a network of Open Source Programme Offices (OSPOs) to facilitate the exchange of information and best practices, ensuring that the distinction between standards and code is managed effectively across the Union.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the distinction between open standards and open source is not just semanticβ€”it is strategic for compliance and market access.

1. Audit Your Stack for Both Dimensions When designing or offering cloud and AI services to the public sector, do not assume that being "open source" is enough. You must also demonstrate compliance with relevant open standards.

  • Action: Map your software components against recognized open standards (e.g., OGC standards for geospatial data, or W3C standards for AI ethics and transparency). Document how your open-source code implements these standards.

2. Prepare for "Total Cost" Justifications Article 41 explicitly mentions "total cost" as a criterion for choosing open standards and open source. Public sector buyers are moving away from looking solely at license fees.

  • Action: SMEs should prepare business cases that highlight the long-term cost savings of open solutions, such as reduced vendor lock-in costs, easier migration paths, and lower maintenance expenses due to community support.

3. Leverage the EU OSS Catalogue If you develop open-source software, ensure it is discoverable.

  • Action: Register your software in the EU Open Source Solutions Catalogue (as mandated for public bodies in Article 42). For private SMEs, this serves as a marketing tool to demonstrate compliance with the spirit of CADA and readiness for public procurement.

4. Focus on Interoperability in Proposals When bidding for public contracts, explicitly address how your solution supports the "open standards" requirement of Article 41.

  • Action: In technical proposals, include a section detailing the open standards your solution adheres to. This demonstrates alignment with CADA's goal of a cohesive European cloud stack.

Common misconceptions

Misconception 1: "Open Source automatically means Open Standards." This is incorrect. You can have open-source software that implements proprietary protocols. Conversely, you can have closed-source software that fully complies with open standards. CADA requires public bodies to consider both independently. A solution must be evaluated on its adherence to standards and its licensing model.

Misconception 2: "CADA mandates a 100% open-source strategy." Article 41 uses the language "encourage" and "facilitate," not "must exclusively use." It allows for exceptions based on "functionalities, including security, total cost, and other relevant, duly justified objective criteria." If a proprietary solution offers superior security or lower total cost of ownership in a specific context, it may still be procured, but the default preference shifts toward openness.

Misconception 3: "Open standards are only for network protocols." In the context of AI and cloud, open standards also cover data formats, API structures, and even ethical AI guidelines. CADA's focus on AI means that standards governing model transparency and data interchange are just as critical as traditional IT protocols.

Misconception 4: "Open source is just free software." Under CADA, open source is a strategic asset for sovereignty, not just a cost-saving measure. The focus is on the ability to audit, modify, and redistribute code to ensure the Union retains control over its digital infrastructure, as defined by the specific licence requirements referenced in Article 2(25).

Related

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