Summary As proposed, the Cloud and AI Development Act (CADA) does not impose direct, standalone compliance obligations on private software vendors to open-source their proprietary code. The legal duties in Articles 41 and 42 fall exclusively on Union entities and public sector bodies to encourage open-source adoption and to publish software they develop. However, vendors are indirectly but significantly affected: public procurement rules will increasingly favor open standards, and contracts for software developed for the public sector may require IP clauses that allow the public body to release the code under an open-source license.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, establishes a comprehensive framework for open source in Title IV, Chapter V. A critical distinction must be made between the regulatory subjects (who the law binds) and the market subjects (who feels the economic impact). The text of the proposal is explicit: the obligations are directed at the public sector as buyers and developers, not at private vendors as a regulated class.

The Direct Obligations: Articles 41 and 42

Article 41 sets the strategic direction for public procurement and development. It 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."

This article imposes a duty of encouragement and facilitation on public authorities. It requires them to consider "functionalities, including security, total cost, and other relevant, duly justified objective criteria" when making choices. Crucially, the subject of the sentence is "The Union and Member States," acting through their entities and public bodies. There is no corresponding clause in Article 41 that mandates a private vendor to release their source code.

Article 42 addresses the specific scenario where the public sector acts as a developer. It provides: "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 obligation is triggered only when a public body holds the IP rights and decides to make the software available for reuse. It regulates the method of publication (via the EU OSS Catalogue) but does not compel the public body to open-source everything, nor does it compel a vendor to transfer IP rights unless such a transfer is agreed upon in the procurement contract.

Indirect Impact on Vendors via Procurement and IP

While vendors are not directly regulated by Articles 41 and 42, the proposal creates a powerful indirect mechanism that will reshape vendor behavior and contract terms.

1. Procurement of Innovation and IP Clauses The proposal links open source to the broader procurement framework. Article 33 sets an objective for Member States to award at least 25% of procurement for cloud computing services and AI systems to innovative SMEs. To achieve this, the proposal encourages "preliminary market consultations" and "development of public contract clauses that are favourable for innovative SMEs."

In practice, this means that when a public body procures software developed for them, the contract will likely include specific IP clauses. If the public body retains IP rights (or a broad license) to the software developed, Article 42 may subsequently require them to publish that software under an open-source license. Vendors bidding on such contracts must therefore be prepared to:

  • Accept IP transfer or licensing terms that allow the public sector to reuse and redistribute the code.
  • Structure their deliverables so that the code can be technically and legally separated for open-source release without compromising their proprietary core.
  • Understand that "software developed for" the public sector may become public domain or open-source, potentially creating a competitor or a baseline for future bids.

2. Union Added Value Criteria (Article 32) Article 32 empowers contracting authorities to include "Union added value" as a non-price award criterion. This includes evaluating the extent to which a tenderer "contributes to strengthening the digital technology supply chain in the Union" and "has integrated technologies developed in the Union."

While Article 32 does not explicitly mandate open source, Article 41's mandate to encourage open standards creates a strong interpretive link. Vendors who demonstrate that their solutions rely on open standards, integrate open-source components, or avoid vendor lock-in will likely score higher on these criteria. Conversely, vendors relying on closed, proprietary stacks may find themselves at a competitive disadvantage in public tenders, even if they are not legally "non-compliant."

3. The EU OSS Catalogue as a Market Signal Article 43 establishes the EU Open Source Solutions Catalogue. While vendors are not required to list their commercial products here, the catalogue will become the central hub for public-sector-developed software. As the catalogue grows, it will define the "standard" for interoperability and reuse in the EU public sector. Vendors whose products cannot easily interoperate with the software listed in the catalogue may face market exclusion, as public bodies will naturally prefer solutions that integrate seamlessly with the open ecosystem they are mandated to build.

What this means for you

For software vendors, cloud providers, and AI developers, the CADA proposal represents a shift in the rules of engagement for public procurement rather than a new compliance regime for your product code.

  • Re-evaluate IP Strategies: When bidding for public sector contracts, scrutinize the IP clauses. If the contract requires you to transfer IP or grant broad licenses, assess the risk that the public body will subsequently release your code under an open-source license pursuant to Article 42. You may need to negotiate "background IP" protections to ensure your core proprietary technology remains closed while only the "foreground" deliverables are open.
  • Adopt Open Standards: Align your product architecture with open standards. Article 41 creates a preference for open standards in the public sector. Vendors that can demonstrate seamless interoperability with open-source ecosystems and the ability to avoid vendor lock-in will be more attractive to contracting authorities.
  • Prepare for "Open by Default" Contracts: In sectors where the public body retains IP (e.g., custom AI models or specific data processing tools), expect contracts to be drafted with the assumption that the output will be published in the EU OSS Catalogue. Your legal and technical teams must be ready to deliver code that is clean, documented, and license-compatible with standard open-source licenses (e.g., Apache 2.0, MIT, EUPL).
  • Leverage the SME Advantage: If you are an SME, the proposal's focus on open source and innovation procurement (Article 33) is a strategic opportunity. Smaller players often have more agile open-source strategies. Highlighting your use of open standards and your ability to integrate with the EU OSS Catalogue can be a key differentiator against larger incumbents.

Common misconceptions

"CADA forces all vendors to open-source their code."

  • Reality: This is incorrect. Articles 41 and 42 apply to Union entities and public sector bodies. A private vendor selling a proprietary product is not legally required to release its source code. The law encourages public buyers to choose open source, but it does not mandate that vendors become open source.

"If I sell to the EU, my software will automatically be published in the EU OSS Catalogue."

  • Reality: No. The catalogue is for software developed by or for Union entities and public sector bodies where the public body holds the IP rights and decides to make it available for reuse. If you sell a standard off-the-shelf proprietary product where you retain all IP, it will not be published there. Only custom-developed software where the public body retains rights may be subject to this.

"CADA overrides existing intellectual property laws."

  • Reality: CADA operates within the existing IP framework. It does not invalidate proprietary licenses. It simply directs public spending and development practices. Any requirement to open-source code must be explicitly agreed upon in the procurement contract.

"Only large vendors are affected by these rules."

  • Reality: The proposal specifically targets SMEs through Article 33, aiming to award 25% of innovation procurement to them. The open-source focus is designed to lower barriers to entry, making it a significant opportunity for smaller, agile vendors to compete.

Related

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