Summary Under the proposed Cloud and AI Development Act (CADA), the primary duty to promote open source lies with the Union and the Member States. Article 41 explicitly mandates that these entities "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. This creates a shared EU/national responsibility to shift public procurement and internal development toward open source, provided that decisions also account for security, total cost, and other objective criteria.
Detail
The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, identifies open source as a critical lever for achieving technological sovereignty, reducing vendor lock-in, and enhancing the security and transparency of the EU's digital infrastructure. Unlike previous initiatives that merely suggested open source as an option, CADA as proposed establishes a binding framework where the Union and Member States must actively foster its adoption within the public sector.
The Core Obligation: Article 41
The central provision governing this shift is Article 41, titled "Promoting open source solutions and open source first." The text of the proposal 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."
This single paragraph establishes three critical pillars of the regulation:
- The Duty Bearers: The obligation falls squarely on "the Union and Member States." This is not a voluntary guideline for individual IT managers; it is a legislative requirement for the EU institutions themselves and for the national governments of the Member States. They are required to enact the "necessary measures" to ensure compliance.
- The Target Beneficiaries: The measures must be directed at "Union entities" (EU institutions, bodies, offices, and agencies) and "public sector bodies" (as defined in Directive (EU) 2019/1024). These are the organizations responsible for building, procuring, and operating the cloud and AI infrastructure that underpins public services.
- The Scope of Action: The requirement applies when these bodies are "building their cloud and AI ecosystem or stack." This covers the entire technology lifecycle, from procurement of third-party services to the development of custom software and the integration of existing components.
Shared EU and National Responsibility
CADA as proposed does not centralize this responsibility solely in Brussels. Instead, it establishes a shared responsibility model that requires coordinated action at both the European and national levels.
- At the EU Level: The Union is tasked with setting the strategic framework and leading by example. This includes the establishment of the EU Open Source Solutions Catalogue (Article 43) and the Network of Open Source Programme Offices (OSPO Network) (Article 44). The Commission must provide and maintain the central catalogue, hosted on the Interoperable Europe portal, to ensure that software developed by Union entities is discoverable and reusable. The OSPO Network will facilitate the exchange of best practices, legal guidance, and technical expertise across the Union.
- At the National Level: Member States must transpose these obligations into their national legal and administrative frameworks. They are required to take measures to encourage their own public sector bodiesβsuch as ministries, regional authorities, and local municipalitiesβto adopt open standards and open-source components. This involves aligning national procurement strategies, IT policies, and funding mechanisms with the "open source first" principle.
The "Objective Criteria" Caveat
While Article 41 promotes an "open source first" approach, it does not impose an absolute ban on proprietary software. The provision includes a crucial safeguard: decisions must be made "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."
This means that the preference for open source is a presumption, not an absolute rule. Public bodies must still conduct a rigorous assessment of their needs. If a proprietary solution offers superior security, a lower total cost of ownership (TCO), or essential functionalities that an open-source alternative cannot provide, it may be selected. However, the burden of proof lies with the decision-maker to provide a "duly justified" explanation based on these objective criteria. The default position, absent such justification, must be to favor open standards and open-source components to prevent vendor lock-in and enhance interoperability.
The Ecosystem: Articles 41, 42, and 43
Article 41 functions as the engine of a broader ecosystem designed to maximize the value of public investment in software. It works in tandem with two other key articles:
- Article 42 (Share and reuse of software): This article creates a feedback loop. When Union entities or public sector bodies develop software and hold intellectual property rights, and they choose to make it available for reuse under an open-source licence, they must do so via a catalogue or repository connected to the EU OSS Catalogue. This ensures that public funds generate public assets that can be reused by others.
- Article 43 (EU Open Source Solutions Catalogue): This article mandates the Commission to provide and maintain the centralised catalogue. Hosted on the Interoperable Europe portal, it serves as the single point of access for public administrations to search for, discover, and reuse software developed by other Union entities and public sector bodies.
Together, these articles create a virtuous cycle: public bodies are encouraged to use open source (Article 41); if they develop software, they are required to share it via the central catalogue (Article 42); and other public bodies can then discover and reuse that software (Article 43), reducing duplication, lowering costs, and accelerating innovation.
What this means for you
For public-sector procurement officers, IT managers, and policy makers, Article 41 of the proposed CADA signals a fundamental shift in how cloud and AI projects must be evaluated and executed.
- Re-evaluate Procurement Strategies: When drafting tenders for cloud computing services or AI systems, you must explicitly include criteria that favor open standards and open-source components. Bids should be evaluated not just on price and performance, but on the extent to which the solution relies on open, interoperable technologies that prevent vendor lock-in.
- Document Justifications Rigorously: If your organization decides to select a proprietary, closed-source solution, you must be prepared to document the objective criteria that justified this choice. Was the open-source alternative demonstrably less secure? Did it have a significantly higher total cost of ownership? Ensure your decision-making process is transparent, defensible, and recorded.
- Adopt an "Open Source First" Mindset for Development: If your organization develops custom software for its cloud or AI stack, consider releasing it as open source. This not only aligns with the spirit of CADA but also allows other public bodies to reuse your work, maximizing the return on public expenditure.
- Utilize the EU OSS Catalogue: Familiarize yourself with the upcoming EU Open Source Solutions Catalogue. It will serve as a primary resource for finding vetted, reusable open-source software developed by other Union entities and public sector bodies, reducing the need to build from scratch.
- Engage with OSPOs: If your organization does not yet have an Open Source Programme Office (OSPO), consider establishing one or connecting with the emerging OSPO Network mandated by Article 44. This network will be a key channel for sharing best practices, licensing advice, and security guidelines across the Union.
Common misconceptions
Misconception 1: CADA bans proprietary software.
- Reality: CADA does not ban proprietary software. Article 41 requires taking measures to encourage open source, but explicitly allows for deviations based on "security, total cost, and other relevant, duly justified objective criteria." Proprietary solutions remain an option if objectively justified.
Misconception 2: Only the European Commission is responsible for promoting open source.
- Reality: The responsibility is shared. Article 41 explicitly states that "The Union and Member States shall take the necessary measures." National governments and their public sector bodies have a direct obligation to implement these measures within their jurisdictions.
Misconception 3: Open source is only about cost savings.
- Reality: While cost is a factor, CADA emphasizes open source for transparency, security, interoperability, and technological autonomy. Open source allows for the auditability of code, reduces dependency on single vendors, and fosters a collaborative ecosystem that strengthens the Union's strategic position in cloud and AI.
Misconception 4: This only applies to new software development.
- Reality: Article 41 applies to "building their cloud and AI ecosystem or stack." This includes the procurement of third-party services, internal development, and the integration of existing components. It is a holistic approach to the entire technology stack.
Related
- Is open source mandatory under CADA? Article 41 explained
- Why does CADA promote open source for digital sovereignty?
- CADA Open Source Chapter: Articles 41β44 Explained
- 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?
This is general information about a draft EU regulation, not legal advice.