Summary Under the proposed Cloud and AI Development Act (CADA), the term 'open standard' is not defined by a standalone technical specification but is functionally inextricably linked to the use of components released under an 'open source licence' as defined in the Interoperable Europe Act. Article 41 obliges the Union and Member States to encourage 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 ecosystems. This requirement is designed to reduce vendor lock-in, enhance interoperability, and strengthen technological sovereignty. Crucially, the specific legal definition of what constitutes an 'open source licence' is imported from Regulation (EU) 2024/903 (the Interoperable Europe Act), ensuring a consistent legal framework across EU digital policy.

Detail

The Cloud and AI Development Act (CADA) positions open source not merely as a development methodology but as a strategic lever for European technological sovereignty. To understand what an 'open standard' means in this specific legislative context, one must analyze how CADA integrates with existing EU digital legislation, particularly regarding public sector procurement, software reuse, and the broader interoperability framework.

The Legal Basis: Article 41 and the "Open Source First" Principle

Article 41 of the CADA proposal, titled "Promoting open source solutions and open source first," establishes the core obligation for public sector adoption. The text mandates 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."

It is critical to note that Article 41 does not provide a standalone, technical definition of 'open standard' within the text of the regulation itself. Instead, it creates a functional dependency on the concept of open source licensing. The provision explicitly requires that this encouragement take into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria." This phrasing indicates that while open standards and open source components are the preferred route for building sovereign ecosystems, the decision-making process must remain holistic. Public bodies are not forced to adopt open standards blindly; they must weigh them against security requirements, total cost of ownership, and other objective factors. However, the default policy direction is clearly set towards openness to prevent fragmentation.

Defining 'Open Source Licence' via the Interoperable Europe Act

Because CADA refers to "components released under an open source licence," the legal definition of what constitutes such a licence is imported from another piece of legislation to ensure consistency across the EU digital acquis. Article 2(25) of CADA defines 'open source licence' by referencing Article 2, point (12), of Regulation (EU) 2024/903, known as the Interoperable Europe Act.

The Interoperable Europe Act defines an open source licence as a licence that allows the software to be freely used, studied, modified, and shared by anyone for any purpose. This definition aligns with the traditional "Open Source Definition" championed by the Open Source Initiative, ensuring that the term has a consistent legal meaning across EU digital policy. Consequently, under CADA, an 'open standard' is effectively a standard that permits the implementation and use of software components governed by these permissive licences. This linkage ensures that the underlying technology is not proprietary or restricted by closed-source terms that could hinder the auditability and reuse required for a sovereign cloud ecosystem.

Interoperability and the EuroCloud Federation

The push for open standards is not an isolated requirement; it is a cornerstone of CADA's broader interoperability strategy, which is essential for the functioning of the EuroCloud Federation. Article 34 establishes this federation as a mechanism for Union entities and public sector bodies to share data centre and cloud computing services on a voluntary basis.

For the EuroCloud Federation to function effectively, the services being shared must be interoperable. Proprietary, closed standards often create silos that prevent different cloud infrastructures from communicating or sharing resources seamlessly. By mandating the use of open standards and open source components, CADA ensures that the EuroCloud Federation can operate across different Member States and entities without being hindered by incompatible, vendor-locked technologies. The explanatory memorandum of the CADA proposal explicitly states that access to source code enables auditability, fosters collaboration, and reduces dependency on a single vendor.

Furthermore, Article 42 reinforces this interoperability goal by requiring that when Union entities or public sector bodies make software available for reuse under an open source licence, they must do so through a catalogue connected to the EU Open Source Solutions Catalogue (EU OSS Catalogue). This catalogue, maintained by the Commission, is hosted on the Interoperable Europe portal. This creates a centralized, discoverable repository of open standard-compliant software, making it easier for public bodies to find and reuse solutions that meet the CADA requirements. The existence of this catalogue is a direct implementation of the interoperability principles found in the Interoperable Europe Act, ensuring that the "open standards" promoted by CADA are practically discoverable and reusable.

Strategic Objectives: Sovereignty, Security, and Auditability

The rationale behind prioritizing open standards and open source is explicitly tied to sovereignty and security. The explanatory memorandum notes that access to source code enables auditability, which is critical for the "Union assurance levels" established in Title IV of CADA. These levels assess the sovereignty and security of cloud computing services, with higher levels (2, 3, and 4) requiring rigorous independent audits.

The ability to audit software supply chainsβ€”a requirement for Union assurance levels 2, 3, and 4β€”is significantly easier when the software is built on open standards and released under open source licences. Annex II to the CADA proposal details the criteria for these assurance levels, including requirements for a complete and up-to-date software bill of materials (SBOM) and the ability to audit source code. Open standards facilitate this by ensuring that the technical specifications are transparent and that the components implementing them are not obscured by proprietary restrictions. This transparency allows public sector bodies to verify the security of their cloud and AI stacks, ensuring that no hidden backdoors or malicious code are present, thereby strengthening the Union's strategic autonomy.

What this means for you

For CTOs, architects, and SMEs targeting the public sector or providing services to Union entities, the CADA proposal signals a clear shift in procurement preferences and technical architecture.

  1. Prioritize Open Standards in Architecture: When designing cloud and AI solutions for public sector clients, prioritize technologies that adhere to open standards. Ensure that your software stack relies on components with recognized open source licences as defined by the Interoperable Europe Act. This will make your solutions more attractive in public procurement processes that are increasingly influenced by CADA's "open source first" principle.
  2. Document Your Licensing: Be prepared to demonstrate that your components are released under a valid open source licence. This may involve maintaining clear licensing documentation and ensuring that any third-party libraries you use comply with the definitions in Regulation (EU) 2024/903.
  3. Leverage the EU OSS Catalogue: If you develop software that is open source, consider registering it with the EU Open Source Solutions Catalogue. This increases visibility and facilitates reuse by public sector bodies, aligning with Article 42's requirements and the broader goals of the Interoperable Europe Act.
  4. Focus on Interoperability: Design your systems to be interoperable with other open standards-based solutions. This is crucial for participation in the EuroCloud Federation and for meeting the broader interoperability goals of the Interoperable Europe Act.
  5. Prepare for Procurement Criteria: Public procurement procedures will increasingly include non-price award criteria related to European added value and the use of open standards (Article 32). Highlighting your use of open standards and open source components can improve your score in these evaluations, as these criteria are designed to reinforce the digital technology supply chain in the Union.

Common misconceptions

Misconception 1: "Open standard" means any publicly available specification. In the context of CADA, 'open standard' is functionally tied to the use of open source licences. It is not enough for a technical specification to be publicly readable; the components implementing that specification must be released under a licence that allows for free use, modification, and sharing. The definition is rooted in the licensing framework of the Interoperable Europe Act, not just in the availability of documentation.

Misconception 2: CADA forces all public sector software to be open source. Article 41 uses the term "encourage," not "mandate." While the proposal strongly promotes the use of open standards and open source components, it allows for exceptions based on "functionalities, including security, total cost, and other relevant, duly justified objective criteria." Public bodies can still choose proprietary solutions if they can justify it based on these objective factors, though the burden of justification will be higher.

Misconception 3: Open source automatically means secure. While open source allows for auditability, it does not guarantee security. CADA emphasizes that the use of open standards must be evaluated against security criteria. Public bodies are still responsible for ensuring that the open source components they use are maintained, patched, and secure. The proposal supports this by promoting the reuse of audited and verified open source solutions through the EU OSS Catalogue.

Related

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