Summary No. As proposed, the Cloud and AI Development Act (CADA) does not impose a blanket legal obligation on public bodies to use open-source software exclusively. Article 41 obliges the Union and the Member States to "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 — and the same provision requires the choice to take account of functionalities (including security), total cost, and other relevant, duly justified objective criteria. It is an encouragement-and-enabling duty, not a mandatory procurement rule that overrides other decision-making factors. Public authorities retain discretion to choose proprietary solutions where objectively justified. CADA is still a proposal, so even these duties are not yet in force.
Detail
CADA (COM(2026) 502 final) places significant emphasis on open source as a lever for technological autonomy, but it distinguishes between encouraging adoption and mandating exclusivity. The relevant obligation is in Article 41, headed "Promoting open source solutions and open source first," within Chapter V of Title IV.
An obligation to encourage, not to compel
Article 41 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 when building their cloud and AI ecosystem or stack."
The provision then qualifies that encouragement: the choice must take account of "functionalities, including security, total cost, and other relevant, duly justified objective criteria." This confirms that open source is a promoted, default-first option — not an absolute requirement that displaces technical or economic rationality. A public body would not be obliged to choose an open-source solution where a proprietary alternative demonstrably offers superior functionality, better security outcomes or lower total cost of ownership, provided that justification is objective and documented.
Where the duty actually falls
The primary, binding duty under Article 41 falls on the Union and the Member States, not directly on the individual procurement officer in a rigid, binary way. They must "take the necessary measures" to create an environment in which open source is viable — which the proposal does not specify in detail, but which would plausibly include building capacity to maintain and secure open-source software, removing legal or bureaucratic barriers to reuse, and supporting enabling infrastructure (such as the EU OSS Catalogue under Article 43).
The recitals underpin this. Recital 81 identifies open source as a means to reduce vendor lock-in, enhance security through auditability and foster innovation, while noting that the choice of cloud services or software has implications "not only for cost-efficiency, but also for security, interoperability, accountability and technological autonomy." The framing is one of encouragement and enabling, not a one-size-fits-all mandate that could jeopardise critical services where no suitable open-source alternative exists.
Distinction from other CADA provisions
It helps to set Article 41 against neighbouring provisions:
- Article 42 (Share and reuse of software) is conditional. It applies only when a Union entity or public sector body holds IP rights in software and voluntarily decides to make it available for reuse under an open source licence; then it must do so via a catalogue connected to the EU Open Source Solutions Catalogue. This regulates the method of sharing — it is not a duty to open-source proprietary software.
- Article 32 (Union added value) is a separate procurement provision. It requires contracting authorities, in procurement for innovative cloud computing services and AI systems, to include non-price award criteria evaluating a tenderer's contribution to a European cloud and AI ecosystem. Crucially, Article 32(2)(d) requires those criteria to be "ancillary and not decisive in the award of the contract." Those criteria can favour, among other things, the use of software, tools or technology developed in the Union — which can intersect with open source — but they cannot, by their own terms, be decisive. This reinforces that technical performance and financial criteria remain paramount.
The "open source first" label
The phrase "open source first" in the heading of Article 41 reflects a policy preference and an order of consideration, not a strict legal hierarchy that guarantees an open-source outcome. In practice, a public body would assess open-source options early. If a robust, secure and cost-effective open-source solution exists, it should be given serious consideration. But where the assessment shows a proprietary solution is needed to meet functional or security requirements, selecting it would be consistent with Article 41, provided the decision rests on the "duly justified objective criteria" the Article names.
What this means for you
For in-house counsel and compliance officers, the practical takeaway is that CADA — if adopted — would introduce a procedural expectation to consider open source seriously, not a prohibition on procuring proprietary software. The focus should be on process, documentation and justification.
1. Update procurement guidelines. Build in a step where teams explicitly assess whether suitable open-source alternatives exist for new cloud and AI projects, evaluated against functionality, security and total cost. This does not mean rejecting proprietary bids; it means being able to show open source was genuinely evaluated.
2. Document objective criteria. Where a proprietary solution is chosen over an open-source alternative, support the decision with clear, objective documentation tied to Article 41's criteria — for example specific security certifications or support arrangements the open-source option lacks.
3. Watch for Member State measures. Because Article 41 obliges Member States to "take the necessary measures," national governments may issue further guidelines, targets or reporting requirements. Track national implementation as part of your broader compliance picture.
4. Mind the reuse channel. If you develop or commission software and choose to release it for reuse under an open source licence, Articles 42 and 43 require publication via a repository connected to the EU OSS Catalogue, hosted on the Interoperable Europe portal. Ensure IT and legal teams understand the connection process.
5. Keep security in the assessment. Article 41 names security as a criterion. "Open source first" should not lead to adopting unmaintained or insecure components; build vetting of open-source dependencies (known vulnerabilities, active support) into your process.
These remain proposed obligations; CADA must be adopted and apply before they take effect.
Common misconceptions
Misconception 1: CADA bans proprietary software in the public sector. No. Article 41 expressly allows the choice to turn on functionalities, security, total cost and other duly justified objective criteria. Proprietary software remains compliant where objectively better on those measures.
Misconception 2: Public bodies must open-source all their software. No. Article 42 applies only where a body voluntarily decides to make software it owns available for reuse, and then governs how it is published. There is no duty to open-source proprietary or custom-developed software.
Misconception 3: "Open source first" means open source must always win. "First" refers to the order of consideration, not the outcome. The final decision rests on a holistic assessment; a proprietary solution objectively better suited can be chosen without breaching Article 41.
Misconception 4: CADA replaces existing procurement law. No. CADA complements the EU public procurement directives. The Article 32 "Union added value" criterion is expressly "ancillary and not decisive," so the core principles of transparency, non-discrimination and proportionality remain intact.
Related
- CADA Open Source: Practical First Steps for Public Bodies
- CADA Article 42: What happens if a public body shares open source software outside the EU OSS Catalogue?
- What criteria can a public body use to NOT choose open source under Article 41?
- Does CADA require sharing software with the public or only other public bodies?
- What is a public sector body for CADA open source purposes?
This is general information about a draft EU regulation, not legal advice.