Summary The proposed Cloud and AI Development Act (CADA) does not mandate that all public-sector software be open source. However, it establishes a strict "if you share, you must share openly" rule. Under Article 42, if a Union entity or public sector body decides to make software available for reuse, it must release it under an "open source licence" as defined in Article 2(25) (referencing the Interoperable Europe Act) and publish it via a repository connected to the EU Open Source Solutions Catalogue. For developers, this means proprietary or "source-available" licences are disqualified for this route. The choice between copyleft (e.g., GPL) and permissive (e.g., MIT, Apache) licences remains a strategic decision, but the licence must grant the fundamental freedoms to run, study, share, and modify the software.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a targeted framework to prevent vendor lock-in and foster a sovereign European cloud ecosystem. While the Act encourages the use of open source, its most binding provision for developers concerns the conditions under which public-sector software is released for reuse.

The Definition: Anchored in the Interoperable Europe Act

CADA does not create a bespoke definition of open source. Instead, it relies on existing EU law to ensure legal certainty and alignment with the broader Digital Decade strategy. Article 2(25) of the proposal explicitly defines the term:

"β€˜open source licence’ means open source licence as defined in Article 2, point (12), of Regulation (EU) 2024/903."

Regulation (EU) 2024/903 is the Interoperable Europe Act (IEA). Under the IEA, an open source licence is one that grants users the freedom to:

  1. Run the program for any purpose.
  2. Study how the program works and adapt it.
  3. Redistribute copies.
  4. Modify and distribute modified versions.

For developers picking a licence, this definition is a hard filter. Licences that are free of charge but restrict modification (e.g., "source available" licences like SSPL or certain proprietary "free" tiers) do not qualify under CADA. If a public body wishes to use the CADA mechanism for sharing software, the licence must be compliant with the IEA definition.

The Reuse Obligation: Article 42 and the Catalogue Route

The operational heart of CADA's open source policy is Article 42, titled "Share and reuse of software." This article creates a conditional obligation for Union entities and public sector bodies:

"When making software to which they hold intellectual property rights available for reuse under an open source licence, a Union entity or public sector body shall do so using a catalogue or repository that is connected to, and made accessible through, the EU OSS Catalogue referred to in Article 43."

This provision establishes a "gateway" mechanism. It does not force a public body to open-source everything it develops. However, if a decision is made to make software available for reuse by others, two conditions are triggered:

  1. Licence Requirement: The software must be released under a qualifying open source licence (as per Article 2(25)).
  2. Discovery Requirement: The software must be hosted in a catalogue or repository that is technically connected to the central EU Open Source Solutions Catalogue (EU OSS Catalogue).

The EU OSS Catalogue, established under Article 43, is designed to be hosted on the Interoperable Europe portal. Its purpose is to solve the "discoverability" problem where valuable public-sector code remains hidden in silos. By mandating connection to this central hub, CADA ensures that any software released for reuse is findable, accessible, and interoperable across the Union.

Licence Strategy: Copyleft vs. Permissive

While CADA mandates the use of an open source licence, it does not prescribe a specific licence (e.g., it does not say "use GPL-3.0"). The choice between copyleft and permissive licences remains a strategic decision for the public sector body and its developers, guided by the objectives in Article 41.

Article 41 states that Union entities and public sector bodies shall encourage the use of open source, "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria." This implies that the licence choice must be justified by the project's goals.

1. Copyleft Licences (e.g., GPL, AGPL)

Copyleft licences require that any derivative work (modifications or integrations) be released under the same licence terms.

  • Strategic Fit for CADA: This aligns strongly with CADA's goal of "strengthening the Union's technological sovereignty" and preventing vendor lock-in. If a public body develops a critical cloud component, a copyleft licence ensures that if a private vendor modifies it, those improvements must be shared back to the community. This prevents the "enclosure" of public assets by commercial entities.
  • Developer Consideration: Developers must be aware that integrating copyleft code into a larger proprietary system can force the entire system to become open source. This may deter some private sector adoption if the goal is to integrate the code into a closed commercial product.

2. Permissive Licences (e.g., MIT, Apache 2.0, BSD)

Permissive licences allow users to do almost anything with the code, including incorporating it into proprietary software, without requiring the derivative work to be open sourced.

  • Strategic Fit for CADA: This aligns with the objective of "fostering the uptake of cloud computing services" and encouraging SMEs to build commercial products on top of public assets. It lowers the barrier to entry for private companies, potentially accelerating innovation and adoption.
  • Developer Consideration: While this maximizes adoption, it does not guarantee that improvements made by private entities will be shared back. A public body choosing a permissive licence accepts the risk that its code could be used to build a proprietary product that competes with the public sector's own offerings without contributing back.

The Support Structure: Article 44 and the OSPO Network

To help developers navigate these choices, CADA establishes a Network of Open Source Programme Offices (OSPOs) under Article 44. These offices will:

  • Facilitate the exchange of best practices on licensing and security.
  • Contribute to the development of guidance and templates for sharing software.
  • Provide a forum for discussing common challenges, such as licence compatibility and maintenance.

For developers, this means that the choice of licence will not be made in a vacuum. The OSPO network is intended to provide the technical and legal guidance necessary to select the most appropriate licence for a specific project, ensuring compliance with CADA while meeting strategic objectives.

What this means for you

For CTOs, software architects, and developers working with or for the public sector, the proposed CADA framework changes the workflow for software release.

1. For Public Sector Developers and Architects

  • The "Share" Decision is Binary: You must decide early if software will be released for reuse. If the answer is "yes," you cannot use a proprietary or "source-available" licence. You must select an IEA-compliant open source licence.
  • Catalogue Integration is Mandatory: Releasing code on a private GitHub repository is insufficient. You must ensure your repository is connected to the EU OSS Catalogue. This requires planning for API integration and metadata standards.
  • Justify Your Licence Choice: Under Article 41, your licence selection should be documented based on objective criteria (security, cost, strategic value). If you choose a permissive licence for a critical security tool, you must be prepared to justify why you are not using copyleft to ensure improvements are shared back.

2. For SMEs and Private Sector Providers

  • New Opportunities: The EU OSS Catalogue will become a central repository of public-sector code. If you are an SME, you can search this catalogue for components to integrate into your solutions.
  • Licence Compliance is Critical: If you integrate code from the catalogue, you must strictly adhere to the licence terms. If the code is copyleft (e.g., GPL), your derivative work may need to be open sourced. If it is permissive, you have more flexibility but must still respect attribution and warranty disclaimers.
  • Competitive Advantage: Familiarity with CADA's open source framework and the ability to contribute to public projects will be a key differentiator when bidding for public contracts, especially those involving the "Union added value" criteria in Article 32.

3. Strategic Planning

  • Assess the "Sovereignty" Goal: If your project is critical to public order or national security, a copyleft licence might be the safer choice to ensure the code remains under public control.
  • Assess the "Adoption" Goal: If your project is a generic utility (e.g., a data visualization tool) where widespread adoption is the priority, a permissive licence may be more effective.

Common misconceptions

"CADA forces all public sector software to be open source." No. CADA does not mandate that all software developed by public bodies must be open source. It only applies when a public body decides to make software available for reuse. Proprietary software can still be developed and used internally or under closed contracts. The obligation is conditional: "When making software... available for reuse...".

"Any 'free' licence counts as open source under CADA." Incorrect. The definition in Article 2(25) is strict. It requires the four fundamental freedoms (run, study, share, modify). Licences that are free of charge but restrict modification or redistribution (often called "source available") do not qualify. Using such a licence would violate Article 42 if the software is shared via the CADA mechanism.

"The EU OSS Catalogue is a code hosting platform like GitHub." No. The catalogue is a discovery and access tool, not a development environment. It is a central index hosted on the Interoperable Europe portal. Developers must still host their code in their own repositories (e.g., GitLab, GitHub) but must ensure those repositories are connected to the catalogue so the software is discoverable.

"CADA dictates whether I should use GPL or MIT." No. CADA sets the minimum requirement (an open source licence) and the process (catalogue connection). It leaves the specific choice of licence (copyleft vs. permissive) to the public body, provided the choice is justified by objective criteria under Article 41.

Official sources

Related

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