What criteria can a public body use to NOT choose open source under Article 41?

Under the proposed Cloud and AI Development Act (CADA), Article 41 establishes a default obligation for Union entities and public sector bodies to "use and

Summary Under the proposed Cloud and AI Development Act (CADA), Article 41 establishes a default obligation for Union entities and public sector bodies to "use and facilitate the reuse of open standards and components released under an open source licence." However, this is not an absolute mandate. Public bodies may opt for proprietary solutions if they can demonstrate that the open-source alternative fails to meet specific, duly justified objective criteria. The text explicitly lists functionalities, including security, total cost, and other relevant factors as the basis for such decisions. Crucially, the "open source first" principle serves as a starting presumption that must yield when fitness-for-purpose requirements—grounded in objective evidence—dictate otherwise.

Detail

Article 41 of the proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, represents a pivotal shift in EU public sector technology strategy. It mandates that the Union and Member States take 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 provision operationalizes the "open source first" principle, aiming to reduce vendor lock-in, enhance transparency, foster collaboration, and strengthen the Union's technological sovereignty. However, the legislative text carefully balances this preference with the practical realities of public procurement and operational necessity. It does not compel public bodies to select open-source software regardless of its technical merit, economic viability, or suitability for a specific mission.

The Legal Framework of Article 41

The core of Article 41 lies in its qualifying clause. The obligation to use open source is not unconditional; it is subject to the requirement that decisions be made "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

This phrasing is the legal safeguard that prevents the "open source first" principle from becoming a rigid, ideological constraint that could compromise public service delivery. For in-house counsel and compliance officers, this clause defines the boundary between a compliant procurement process and a potential violation of the regulation.

1. Functionalities: The Primary Determinant

The first and most critical criterion is functionality. The primary purpose of any software procurement is to ensure the tool performs the required tasks effectively. Article 41 acknowledges that an open-source alternative may lack specific features essential to a public body's operations.

Feature Gaps: If an open-source solution lacks a critical feature that a proprietary alternative provides, and developing that feature internally is not feasible within the project's constraints, the functionality criterion justifies the proprietary choice.
Interoperability and Integration: The assessment must cover not just core features but also the ability to integrate with existing legacy systems, scalability requirements, and user experience standards. If an open-source option cannot interoperate with the public body's current ecosystem without prohibitive customization, functionality serves as a valid objective reason to select a proprietary solution.
Fitness-for-Purpose: The decision must be rooted in the specific operational needs of the public body. A generic preference for open source cannot override the specific functional requirements of a critical public service.

2. Security: A Nuanced Criterion

While open source is often associated with enhanced security through transparency ("many eyes" review), Article 41 explicitly lists security as a criterion that may, in specific contexts, favor proprietary solutions.

Certified Assurances: A public body may justify a proprietary choice if the vendor offers superior, certified security assurances (e.g., specific European cybersecurity certification levels) that the open-source alternative cannot match.
Incident Response and Support: If a proprietary vendor provides dedicated, 24/7 incident response, guaranteed service level agreements (SLAs) for patching, and specific compliance certifications that are critical for the public body's risk profile, these factors constitute objective security criteria.
Risk Profile: Conversely, if an open-source solution allows for independent security auditing that a proprietary "black box" does not, security becomes a criterion favoring open source. The key is that the security assessment must be based on the specific risk profile of the data and system in question, not on general assumptions about the software model.

3. Total Cost: Beyond the License Fee

The reference to "total cost" in Article 41 is a directive to evaluate the Total Cost of Ownership (TCO), rather than just the initial acquisition cost. This is a crucial distinction for public finance.

Lifecycle Costs: For open-source software, the license fee is often zero, but the TCO includes costs for implementation, customization, maintenance, support, training, and potential future migration.
Hidden Costs: If the hidden costs of maintaining an open-source solution—such as hiring specialized internal staff, paying for third-party support contracts, or managing complex integrations—are significantly higher than the licensing fees of a robust proprietary package, the total cost criterion may objectively justify the proprietary choice.
Economic Efficiency: The regulation requires a holistic view. A decision to choose proprietary software must be supported by a TCO analysis demonstrating that the proprietary option offers better economic efficiency over the lifecycle of the project.

4. Other Relevant, Duly Justified Objective Criteria

The catch-all phrase "other relevant, duly justified objective criteria" provides necessary flexibility for complex procurement scenarios. This may include:

Maturity and Stability: The maturity of the open-source community, the stability of the vendor's roadmap, or the risk of the project being abandoned.
Legal Risks: Specific open-source license obligations (e.g., copyleft provisions) that might conflict with the public body's intellectual property strategy or data protection requirements.
Availability of Support: The availability of local, certified support or the existence of a robust ecosystem of service providers.

Crucially, these criteria must be "duly justified." This means the public body must document the rationale for their selection, demonstrating a clear link between the chosen criterion and the specific needs of the procurement. Subjective preferences, such as familiarity with a specific vendor's interface or historical relationships, are not sufficient.

The "Open Source First" Default and the Burden of Proof

The legislative intent behind Article 41, as reflected in Recital 81 of the explanatory memorandum, is to create a strong presumption in favor of open source. Recital 81 notes that open source plays an important role in ensuring transparency, security, and efficiency, and that access to source code enables auditability and reduces dependency on a single vendor.

Therefore, the burden of proof lies with the public body seeking to deviate from this default. A decision to procure proprietary software must be defensible in the event of an audit or legal challenge. The justification cannot be retrospective; the objective criteria must be defined and applied during the procurement planning and evaluation phases. This aligns with general EU public procurement principles, which require that award criteria be linked to the subject matter of the contract and not confer unrestricted freedom of choice on the contracting authority.

Compliance and Documentation Requirements

For compliance officers, the practical implication of Article 41 is the need for robust documentation. When a public body decides not to use open source, it must be able to demonstrate that it:

Conducted a Market Analysis: Included open-source options in the initial market scan.
Evaluated Against Criteria: Assessed those options against the objective factors listed in Article 41 (functionalities, security, total cost).
Documented the Rationale: Clearly recorded why the open-source options failed to meet the requirements or were less favorable based on the justified criteria.

This documentation is essential not only for internal governance but also to withstand scrutiny from national competent authorities or the European Commission. The CADA aims to foster a competitive single market, and arbitrary exclusion of open-source providers could be seen as distorting competition.

What this means for you

For in-house counsel and compliance officers, Article 41 requires a proactive review of existing procurement policies and technology roadmaps. You must ensure that your organization's approach to software selection is not only compliant with the "open source first" ethos but also rigorously documented when deviations occur.

Actionable Steps:

Update Procurement Templates: Revise request for proposals (RFPs) and tender documents to explicitly include open-source solutions as eligible candidates. Ensure that evaluation criteria reflect the objective factors listed in Article 41, such as TCO and security certifications.
Establish Justification Protocols: Create a standardized template for justifying the selection of proprietary software. This template should require procurement teams to detail how open-source alternatives were assessed and why they were rejected based on functionalities, security, or cost.
Train Procurement Staff: Educate procurement and IT teams on the nuances of Article 41. They must understand that "open source first" is a guiding principle, not a blind mandate, and that objective, documented justifications are the legal shield for choosing proprietary tools.
Monitor TCO Calculations: Ensure that financial assessments for software projects accurately capture the full lifecycle costs of both open-source and proprietary options. Underestimating the support and maintenance costs of open-source software can lead to poor procurement decisions that are difficult to justify under the "total cost" criterion.

Common misconceptions

Misconception 1: Article 41 bans proprietary software. This is incorrect. Article 41 encourages the use of open source but explicitly allows for exceptions based on objective criteria. Proprietary software remains a valid option if it better meets the functionalities, security, or cost requirements of the public body.

Misconception 2: "Open Source First" means open source must always be cheaper. While cost is a factor, it is not the sole determinant. A proprietary solution may be more expensive in terms of licensing but cheaper in terms of implementation time or risk mitigation. The "total cost" criterion allows for a balanced view that may sometimes favor proprietary solutions if they offer greater overall value or lower risk.

Misconception 3: Any reason can justify choosing proprietary software. Justifications must be "objective" and "duly justified." Subjective preferences, such as familiarity with a specific vendor's interface or historical relationships, are not sufficient. The justification must be based on measurable factors related to the project's specific needs, such as technical capabilities or security certifications.

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