Summary As proposed in COM(2026) 502 final, the Cloud and AI Development Act (CADA) would require the EU and Member States to take measures encouraging 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." Under Article 41, this "open source first" approach is not an absolute mandate but a strategic directive. Public bodies must prioritize open source solutions while considering functionalities, security, total cost, and other relevant, duly justified objective criteria. The provision aims to reduce vendor lock-in, enhance security through auditability, and strengthen the Union's digital autonomy by fostering a competitive, transparent technology landscape for AI development.

Detail

The Cloud and AI Development Act (CADA) introduces a structured push toward open source technologies within the public sector's technological infrastructure. This initiative is grounded in the belief that open source is a critical lever for boosting technological sovereignty, competitiveness, and security. The core legal mechanism for this shift is found in Title IV, Chapter V of the proposal, specifically Article 41, titled "Promoting open source solutions and open source first."

The Legal Basis: Article 41 and the "Cloud and AI Ecosystem or Stack"

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."

The phrase "cloud and AI ecosystem or stack" is significant. It implies that the obligation covers the entire technology stack, from the underlying infrastructure (cloud) to the application layer (AI models, frameworks, and tooling). For AI development, this means public bodies are encouraged to favor:

  • Open Models: Pre-trained AI models released under open licenses, allowing for inspection, modification, and fine-tuning without reliance on closed, black-box APIs.
  • Frameworks and Tooling: Libraries, development environments, and orchestration tools (e.g., for training, inference, and deployment) that are openly available and modifiable.
  • Middleware and Interfaces: The software layers that connect AI models to data and infrastructure, ensuring interoperability across the Union.

Crucially, the article qualifies this encouragement. It mandates that these entities must take into account specific criteria when making these choices, ensuring that "open source first" is interpreted as a strategic preference rather than a blind mandate. The criteria include:

  • Functionalities: The technical capability of the open source solution to meet specific requirements.
  • Security: The robustness, auditability, and safety of the codebase.
  • Total Cost: A holistic view of costs, likely including licensing, maintenance, support, integration, and potential security remediation, rather than just initial acquisition price.
  • Other relevant, duly justified objective criteria: This allows for flexibility to consider factors like performance, compatibility, and strategic alignment with Union objectives.

This framing prevents the adoption of open source solutions that are functionally inferior or insecure simply because they are open source. It ensures that procurement decisions remain grounded in technical and economic reality while steering the market toward open alternatives.

The Sovereignty Rationale: Recital 81

The motivation behind Article 41 is detailed in Recital 81 of the explanatory memorandum. The proposal argues that open source plays a vital role in ensuring transparency, security, and efficiency in the public sector's use of digital technologies. The recital highlights several key benefits that directly address the sovereignty gaps CADA seeks to fill:

  1. Auditability and Security: Access to the source code enables thorough auditing. This transparency fosters collaboration and reuse while reducing dependency on a single vendor. By limiting the risk of vendor lock-in, public bodies can maintain greater control over their critical infrastructure.
  2. Technological Autonomy: Promoting open source is described as essential to supporting innovation, ensuring better value for public expenditure, and strengthening the Union's digital autonomy.
  3. Strategic Implications: The recital notes that 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 emphasizes that reliance on proprietary software from non-European providers poses risks related to operational discontinuity and data sovereignty. By fostering an open source ecosystem, the EU aims to create a more resilient and self-sufficient digital infrastructure, reducing the leverage of third-country actors over critical public services.

Application to AI Development: Models, Frameworks, and Tooling

For AI development specifically, the "open source first" principle under CADA has profound implications for how public sector bodies build and deploy AI systems. The "stack" encompasses the full lifecycle of AI:

  • Open Models: Public bodies developing AI systems are encouraged to prioritize pre-trained models released under open licenses. This allows for the fine-tuning of models for specific public sector tasks (e.g., healthcare diagnostics, legal analysis) without being locked into a specific vendor's proprietary API. It also enables the verification of model behavior, reducing the risk of hidden biases or backdoors.
  • Frameworks and Tooling: The regulation encourages the use of open frameworks for model training, inference, and management. This includes libraries for data preprocessing, model optimization, and deployment orchestration. By standardizing on open tooling, the EU can ensure that AI systems are portable and interoperable across different cloud environments.
  • Datasets and Data Flows: While Article 41 focuses on software components, the "ecosystem" context implies that the data pipelines feeding these models should also benefit from open standards and interoperability, facilitating the reuse of public sector data for AI training in compliance with the GDPR and the Data Act.

Under CADA, public sector bodies are not just consumers but active participants in the open source ecosystem. They are encouraged to share their own developments, creating a virtuous cycle of innovation and reuse.

Supporting Mechanisms: The Ecosystem in Action

CADA does not leave the implementation of Article 41 to chance. It establishes a robust infrastructure to facilitate the practical application of open source principles:

  • EU Open Source Solutions Catalogue (Article 43): The Commission will maintain a centralized catalogue to access software made available for reuse by Union entities and public sector bodies. This improves discoverability and searchability, addressing the common pain point of fragmented repositories. The catalogue will be hosted on the Interoperable Europe portal, ensuring it is accessible and free of charge.
  • Network of Open Source Programme Offices (OSPOs) (Article 44): The proposal establishes a network to facilitate cooperation on implementing open source obligations. This network will promote the exchange of best practices, address common technical and legal challenges (such as licensing, security, and maintenance), and support the sharing and reuse of open-source software.
  • Sharing and Reuse (Article 42): When public sector bodies make software available for reuse under an open source license, they must do so through a catalogue connected to the EU OSS Catalogue. This ensures that publicly funded developments contribute back to the common pool, maximizing the value of public expenditure and preventing duplication.

What this means for you

For CTOs, architects, AI developers, and SMEs evaluating the practical impact of CADA, the "open source first" principle signals a significant shift in public procurement and technology strategy.

For Public Sector CTOs and Architects:

  • Strategic Alignment: You will need to align your technology roadmaps with the "open source first" directive. This means actively evaluating open source alternatives for new cloud and AI projects, particularly for the "stack" components.
  • Justification Requirements: If you choose a proprietary solution, you must be prepared to justify the decision based on functionalities, security, total cost, or other objective criteria. Documentation of this decision-making process will become increasingly important for compliance audits.
  • Governance: Establishing or strengthening an Open Source Programme Office (OSPO) within your organization will be crucial. The OSPO network proposed in Article 44 will serve as a key resource for guidance, legal compliance, and security best practices.

For SMEs and AI Providers:

  • Market Opportunity: There is a growing market for open source AI models, frameworks, and tooling that meet public sector requirements for security and interoperability. SMEs that develop or support such solutions will be well-positioned to benefit from increased public sector adoption.
  • Compliance and Support: Public sector buyers will demand robust support and security assurances for open source components. SMEs offering managed services, security audits, or custom development around open source AI tools will find increased demand.
  • Interoperability: Focus on ensuring your solutions are interoperable with existing open standards and can be easily integrated into the broader EU cloud and AI ecosystem.

For Developers:

  • Skill Development: Proficiency in open source AI frameworks and models will become more valuable. Understanding the legal and security implications of open source licensing is also critical.
  • Contribution: Contributing to open source projects that are relevant to public sector needs can enhance your visibility and credibility in the market. The "reuse" aspect of Article 41 means that code you contribute today could become the foundation for tomorrow's public sector AI systems.

Common misconceptions

  • "Open source first means mandatory open source."
    • Reality: Article 41 uses the term "encourage," not "mandate." Proprietary solutions can still be used if they offer superior functionality, security, or total cost of ownership, provided this is duly justified. The "total cost" criterion is a key safety valve.
  • "Open source is always cheaper."
    • Reality: While open source software often has no licensing fees, the "total cost" includes support, maintenance, integration, and potential security risks. Article 41 explicitly requires considering total cost, not just upfront price.
  • "Open source is inherently less secure."
    • Reality: Recital 81 highlights that open source enables auditability, which can enhance security. However, security depends on active maintenance and community support. The regulation encourages using open source that meets high security standards.
  • "This applies to all private sector companies."
    • Reality: Article 41 specifically targets Union entities and public sector bodies. However, the demand from the public sector can create spillover effects, influencing private sector practices, especially for companies that supply to the public sector.

Official sources

Related

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