Summary Under the proposed Cloud and AI Development Act (CADA), the open source chapter (Articles 41–44) would shape public-sector cloud, AI and software buying in ways that affect providers. Article 41 sets an "open source first" preference — a duty on the Union and Member States to encourage open standards and open-source components, weighed against functionalities (including security), total cost and other duly justified objective criteria. It does not ban proprietary software; proprietary solutions must compete on merit. Article 43 would create a centralised EU Open Source Solutions Catalogue of reusable public-sector software, adding a new competitive reference point. For providers, the practical shift is towards competing on service, support, security and interoperability. CADA is still a proposal, so none of this is yet in force.
Detail
CADA (COM(2026) 502 final) is a Commission proposal aimed at strengthening the EU's technological autonomy, reducing vendor lock-in and fostering a competitive European cloud and AI market. For cloud service providers, data centre operators and software vendors, the most relevant open source provisions sit in Chapter V of Title IV — chiefly Articles 41 and 43.
The "open source first" assessment (Article 41)
Article 41 establishes the principle of promoting open source solutions and "open source first." It provides 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." The binding duty runs to the Union and the Member States to encourage and facilitate — it is not a hard rule directed at each buyer.
It is not an absolute mandate to use open source. Article 41 requires the choice to take account of:
- Functionalities — the capabilities the use case needs;
- Security — the solution's cybersecurity posture and resilience;
- Total cost — overall cost of ownership, not just the licence fee; and
- Other relevant, duly justified objective criteria.
So open source is the default to consider first, but proprietary software remains viable where a provider can show superior functionality, security or lower total cost of ownership. The provision's purpose is to limit vendor lock-in by favouring open standards and components and the interoperability they bring.
The EU Open Source Solutions Catalogue (Article 43)
Article 43 creates a centralised infrastructure for software reuse: the EU Open Source Solutions Catalogue (EU OSS Catalogue). The Commission would provide and maintain it as a centralised catalogue to access software made available for reuse by Union entities and public sector bodies. Key features:
- Centralised access — it brings together reusable software that would otherwise sit in scattered repositories;
- Free access — hosted on the Interoperable Europe portal (Article 8 of Regulation (EU) 2024/903) and accessible electronically free of charge; and
- Connection model — under Article 42, a body that chooses to make software it owns available for reuse under an open source licence must publish it through a catalogue or repository connected to the EU OSS Catalogue.
For commercial providers, the catalogue is a new competitive reference point: a searchable pool of public-sector-developed solutions, some of which may offer a no-licence-fee alternative to commercial products.
Open standards and components
Beyond licences, CADA emphasises open standards and specifications. Recital 15 notes that the Cloud and AI Leadership Initiatives should promote technologies relying on open standards, open specifications and open source. For providers, this signals that closed protocols and ecosystems may face higher barriers in public procurement, and that interoperability with open standards is increasingly valuable even where the core product is proprietary.
Competing alongside reusable public software
The combination of Article 41's preference and Article 43's catalogue creates a new dynamic. As public bodies share more reusable software, commercial providers may find themselves competing not only with other vendors but with no-licence-fee public-sector solutions. The practical consequences:
- More competition — including from reusable public software with zero licensing cost;
- A value-proposition shift — the differentiators become service, support, security and integration (managed services, SLAs, advanced security) rather than software cost alone; and
- Interoperability expectations — proprietary solutions that cannot interoperate with open-source components are less attractive to procurers.
Procurement: Union added value (Article 32)
For providers bidding for public contracts, a separate provision is relevant. Article 32 ("Union added value") requires contracting authorities, in procurement for innovative cloud computing services and AI systems, to include non-price award criteria evaluating the tenderer's contribution to a European cloud and AI ecosystem. Critically, Article 32(2)(d) requires those criteria to be "ancillary and not decisive in the award of the contract." The criteria can favour, among other things, the use of tools developed in the Union, including software — which intersects with open source — but they cannot, by their own terms, dominate the award. (Note that Article 32 is a procurement provision, distinct from the open source chapter.)
In drafting proposals, providers should:
- Highlight open-source compatibility — if your product uses open-source components or adheres to open standards, say so;
- Justify proprietary choices — where proposing proprietary software, address the Article 41 criteria (functionality, security, TCO) directly; and
- Track the catalogue — monitor the EU OSS Catalogue for relevant solutions and consider integration or complementary offerings.
What this means for you
For cloud service providers and data centre operators, CADA's open source provisions — if adopted — would warrant a review of your portfolio and sales strategy.
1. Audit your stack. Identify proprietary versus open-source elements. Heavy reliance on closed protocols may be a risk in procurements that value open standards; consider supporting open standards or open-sourcing non-core components.
2. Strengthen your service layer. Where the software itself may be free, compete on managed services, support, security monitoring and integration expertise — the operational burden you remove for the buyer.
3. Prepare for the EU OSS Catalogue. Monitor its development. If you complement public-sector software, position your product as a best-of-breed integration or support layer.
4. Address the Article 41 criteria in proposals. Where you propose proprietary software, compare against open-source alternatives on security, functionality and total cost, and emphasise the open standards you support.
5. Engage with the OSPO Network. Article 44 would create the OSPO Network. While aimed at public bodies, its non-binding guidance and best practices can help you anticipate public-sector expectations.
These are proposed measures; CADA must be adopted and apply before they take effect.
Common misconceptions
Misconception 1: CADA bans proprietary software. No. Article 41 does not prohibit proprietary software. It frames a preference to consider open source first, while allowing proprietary solutions where justified on functionality, security or total cost.
Misconception 2: All public software must be open-sourced. No. Article 42 governs how software is published only where a body voluntarily decides to make software it owns available for reuse under an open source licence. There is no duty to open-source all public software.
Misconception 3: Open source always means lower cost. Licence fees may be zero, but total cost of ownership includes implementation, maintenance, security and support; a proprietary option can sometimes have lower TCO. Article 41 requires considering total cost, not just licence fees.
Misconception 4: The EU OSS Catalogue is only for public bodies. The catalogue is maintained by the Commission and populated by public bodies, and it is freely accessible. Private providers can use it to identify reusable components and market gaps and to position complementary offerings.
Related
- How does CADA open source affect open source software providers' business models?
- CADA Open Source Assessment: Obligations, OSPO Network & Reuse Rules
- What is an 'open standard' under CADA's open source rules?
- CADA Article 42: What happens if a public body shares open source software outside the EU OSS Catalogue?
- What does CADA's open source chapter mean for public-sector buyers?
This is general information about a draft EU regulation, not legal advice.