Summary Under the proposed Cloud and AI Development Act (CADA), the "open source first" principle applies prospectively to new developments, not retrospectively to existing legacy systems. Article 41 mandates that Union entities and public sector bodies encourage the use of open standards and components "when building their cloud and AI ecosystem or stack." This forward-looking phrasing means you are not required to immediately rip and replace existing proprietary infrastructure. However, the obligation is triggered the moment you initiate modernization, migration, or significant upgrades, as these activities constitute "building" a new or expanded stack.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a strategic shift in how the European Union and its Member States approach software procurement and architectural decisions in the public sector. Central to this shift is the "open source first" principle, designed to reduce vendor lock-in, enhance security through auditability, and strengthen technological sovereignty.

For Chief Technology Officers (CTOs), architects, and public procurement officers, the critical question is the temporal scope of this obligation: does it apply to the legacy systems currently running public services, or only to future projects? The answer lies in the specific wording of Article 41 and the legislative intent regarding the "ecosystem or stack."

The Scope of Article 41: A Forward-Looking Mandate

The legal basis for this obligation is found in Article 41 of the CADA proposal. The text states:

"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, taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

The operative phrase here is "when building their cloud and AI ecosystem or stack." This language is explicitly prospective. It targets the active process of construction, development, procurement, and architectural assembly. It does not contain language that would impose a retroactive mandate to decommission, rewrite, or replace existing proprietary systems that are already in service, provided those systems remain compliant with other applicable EU laws (such as the NIS2 Directive, GDPR, or the Cyber Resilience Act).

The legislative history and explanatory memorandum support this interpretation. The proposal aims to prevent future lock-in and foster a competitive European market for open technologies. It does not seek to destabilize current public services by forcing immediate migration of stable, albeit proprietary, legacy systems.

New Builds vs. Existing Systems: The Distinction

For existing systems, CADA does not impose a direct "open source first" compliance requirement. If a public sector body is currently operating a proprietary cloud or AI system that was procured before CADA's entry into force, there is no automatic obligation under Article 41 to replace it with an open-source alternative solely for the sake of compliance. The "grandfathering" of existing contracts is implicit in the forward-looking nature of the "when building" condition.

However, the distinction between "existing" and "new" is not a static wall; it is a dynamic boundary defined by the lifecycle of the technology. CADA recognizes that public sector IT is not static. When an existing system reaches end-of-life, requires significant upgrades, or needs to be integrated into a broader cloud strategy, those activities constitute "building" or expanding the ecosystem.

The Trigger: Modernization and Migration as "Building"

The "open source first" principle becomes legally and strategically relevant the moment a public sector body decides to modify its stack. This includes:

  • Major Upgrades: Replacing a core module of a legacy system.
  • Migration: Moving from on-premise infrastructure to the cloud, or from one cloud provider to another.
  • Integration: Connecting legacy systems to new AI tools or data spaces.
  • Greenfield Projects: Developing entirely new digital services.

In these scenarios, the public sector body is effectively "building" a new cloud and AI ecosystem or stack. At that point, the obligation under Article 41 kicks in. The decision to migrate is not merely a technical choice but a procurement decision subject to the "open source first" encouragement.

For example, if a ministry decides to migrate its citizen database from a proprietary on-premise solution to a cloud environment, the choice of the new database engine, the orchestration tools, and the AI models used for data processing must be evaluated against open-source alternatives. Choosing a proprietary solution would require a "duly justified objective criteria" justification, as detailed below.

The Role of Objective Criteria: It Is Not an Absolute Ban

Article 41 does not mandate open source in every single instance without exception. It requires public sector bodies to take measures to encourage its use, while "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

This creates a rebuttable presumption in favor of open source for new builds. The default position should be open source. However, the proposal explicitly allows for deviation if a public sector body can demonstrably justify that a proprietary solution offers:

  1. Superior Security: Where open-source alternatives cannot meet specific, high-risk security requirements (though this must be evidenced, not assumed).
  2. Lower Total Cost of Ownership (TCO): Where the proprietary solution is objectively cheaper when factoring in licensing, maintenance, and integration costs.
  3. Specific Functionalities: Where the required functionality is unique to a proprietary solution and no open-source equivalent exists.

This justification must be documented. It prevents arbitrary choices that favor incumbent vendors without technical merit. The burden of proof lies with the contracting authority to show that the open-source route was considered and rejected based on objective, not political or habitual, grounds.

Implications for Migration and Modernization Strategies

While existing systems are not immediately targeted, the "open source first" principle heavily influences migration strategies. As public sector bodies move from legacy on-premise infrastructure to cloud environments, or from proprietary AI models to new generative AI tools, they are effectively "building" a new stack.

In these migration scenarios, CADA encourages a "cloud and AI ecosystem" approach where open standards and open-source components are prioritized. This supports the broader CADA goal of reducing dependencies on third-country providers and ensuring interoperability.

Consider a scenario where a public health agency migrates its patient data analytics platform. Under Article 41, the agency must first assess whether an open-source analytics stack (e.g., using PostgreSQL, Apache Spark, and open-source AI models) can meet the security and functionality requirements. If they choose a proprietary vendor, they must document why the open-source option failed the "objective criteria" test. This process ensures that migration decisions are not just about moving data, but about building a sovereign, resilient future stack.

Connection to Article 42 and the Reuse Ecosystem

Article 41 works in tandem with Article 42, which deals with the sharing and reuse of software. Article 42 requires 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 powerful feedback loop:

  1. Article 41 drives the creation of new open-source solutions during "building" phases.
  2. Article 42 ensures these solutions are cataloged and made available for reuse.
  3. Article 43 provides the central repository (the EU OSS Catalogue) where other public bodies can find these vetted solutions.

As new open-source solutions are built and adopted under Article 41, they become available for reuse by other entities under Article 42, further strengthening the open-source ecosystem and reducing the need to "reinvent the wheel" in future projects.

What this means for you

For CTOs, architects, and SMEs evaluating the impact of CADA, the distinction between new and existing systems is crucial for strategic planning.

For Public Sector CTOs and Architects:

  • Audit Your Roadmap: Review your IT roadmap for the next 3–5 years. Identify all planned new builds, major upgrades, and migrations. For these projects, prepare to justify any choice of proprietary software against open-source alternatives using objective criteria (security, cost, functionality).
  • Document Justifications: Establish a process for documenting why a proprietary solution was chosen over an open-source one for new projects. This documentation will be essential for demonstrating compliance with Article 41.
  • Plan for Migration: When existing proprietary systems need replacement, prioritize open-source alternatives. This aligns with the "building" language of Article 41 and supports long-term sovereignty goals.
  • Leverage the EU OSS Catalogue: Use the EU Open Source Solutions Catalogue (mentioned in Article 43) to find vetted open-source solutions that meet public sector needs. This can reduce the risk associated with adopting open source.

For SMEs and Vendors:

  • Highlight Open-Source Offerings: If you provide cloud or AI services, highlight your open-source components or your ability to integrate with open-source stacks. Public sector buyers will increasingly prefer vendors that align with the open source first principle.
  • Prepare for Due Diligence: Expect public sector clients to ask for detailed comparisons between your proprietary solutions and open-source alternatives. Be ready to demonstrate clear, objective advantages in security, cost, or functionality.
  • Contribute to the Ecosystem: Consider contributing to open-source projects or making your own tools available under open-source licenses. This aligns with the broader CADA goals of fostering innovation and reducing dependencies.

Common misconceptions

Misconception 1: CADA requires immediate replacement of all proprietary software. This is incorrect. Article 41 applies "when building" new ecosystems or stacks. There is no mandate to retroactively rewrite or replace existing, functioning proprietary systems. The focus is on future procurement and development.

Misconception 2: "Open source first" means open source must always be chosen, regardless of merit. This is also incorrect. Article 41 allows for exceptions based on "functionalities, including security, total cost, and other relevant, duly justified objective criteria." Proprietary solutions can still be chosen if they are demonstrably superior in these areas, provided the justification is documented.

Misconception 3: Only new greenfield projects are affected. This is a dangerous oversimplification. While greenfield projects are clearly covered, any significant modernization, upgrade, or migration of existing systems involves "building" or modifying the stack. Therefore, the open source first principle applies to these activities as well.

Official sources

Related

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