Summary Under the proposed Cloud and AI Development Act (CADA), public sector bodies must encourage the use of open-source solutions by applying an "open source first" approach. As proposed in Article 41, this requires weighing "functionalities, including security, total cost, and other relevant, duly justified objective criteria" when building cloud and AI ecosystems. There is no rigid mathematical formula; rather, the regulation mandates a holistic assessment where open source is favored unless proprietary alternatives demonstrably better meet these specific, justified criteria.

Detail

Article 41 of the proposed CADA, titled "Promoting open source solutions and open source first," establishes a binding obligation for the Union and Member States. It states that they "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 core of this obligation lies in the specific criteria that must guide this choice. The text explicitly lists the factors that public sector bodies must consider: "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria." This phrasing creates a structured decision-making framework rather than a blanket mandate to use open source in every instance regardless of quality.

The Total Cost Test

The "total cost" criterion is central to applying the open source first principle. In the context of CADA, total cost does not refer solely to the initial purchase price or licensing fees. Because open-source software is often available at no direct licensing cost, a narrow focus on upfront expenditure would automatically favor open source, rendering the test meaningless.

Instead, "total cost" implies a Total Cost of Ownership (TCO) analysis. Public sector bodies must evaluate the full financial lifecycle of the software, including:

  • Implementation and Integration: Costs associated with deploying the software into existing infrastructure, including data migration and API integration.
  • Maintenance and Support: Expenses for ongoing updates, patches, and technical support, whether provided internally by public staff or through third-party commercial support contracts.
  • Training and Upskilling: Resources required to train staff to manage and operate open-source solutions effectively, which may differ from training for proprietary systems.
  • Operational Efficiency: Long-term costs related to performance, scalability, and the avoidance of vendor lock-in, which can reduce future switching costs.

A proprietary solution may have a higher initial license fee but a lower total cost if it requires significantly less maintenance, offers superior out-of-the-box integration, or reduces the need for specialized internal expertise. Conversely, an open-source solution may have zero licensing fees but a higher total cost if it requires extensive custom development, lacks a mature support ecosystem, or demands significant internal resources to maintain. The "open source first" rule requires that open source be preferred unless the total cost analysis (alongside other criteria) demonstrates that a proprietary solution is objectively superior.

Weighing Functionality and Security

Alongside cost, Article 41 explicitly requires consideration of "functionalities, including security." This creates a triad of primary evaluation metrics that must be balanced:

  1. Functionality: The software must meet the technical and operational requirements of the specific use case. An open-source solution that lacks critical features required for a public service cannot be favored simply because it is open source. The functionality must be sufficient to deliver the intended public value and meet the specific needs of the cloud or AI ecosystem.
  2. Security: Security is highlighted as a subset of functionality, reflecting the high-stakes nature of public sector cloud and AI ecosystems. This includes assessing the software's vulnerability history, the responsiveness of the community or vendor to security patches, and compliance with relevant cybersecurity standards. While CADA does not prescribe a specific security certification for open source in Article 41, it aligns with the broader CADA framework (such as the sovereignty framework in Title IV) which emphasizes high cybersecurity standards. Security assessments must be evidence-based, looking at audit trails, community responsiveness, and available commercial support options.
  3. Other Duly Justified Objective Criteria: The regulation allows for flexibility by including "other relevant, duly justified objective criteria." This catch-all provision permits public sector bodies to consider additional factors such as interoperability with existing systems, accessibility compliance, sustainability, the maturity of the open-source project, and the availability of local talent. However, these criteria must be "duly justified," meaning they must be relevant to the procurement or development objective and applied consistently and non-discriminatorily. Arbitrary criteria cannot be used to bypass the open source first principle.

The "Open Source First" Mechanism

The term "open source first" indicates a presumption in favor of open-source solutions. Public sector bodies should start their evaluation with open-source options. To justify choosing a proprietary alternative, the procuring authority must demonstrate that the proprietary solution better satisfies the combination of functionality, security, total cost, and other objective criteria.

This approach aligns with CADA's broader goals of reducing dependencies on third-country providers, limiting vendor lock-in, and fostering a competitive European digital ecosystem. By mandating this structured comparison, Article 41 aims to ensure that open source is not ignored due to inertia or legacy preferences, but is instead evaluated on its merits against clear, objective benchmarks. The provision works in tandem with Article 42 (Share and reuse of software) and Article 43 (EU Open Source Solutions Catalogue), which provide the infrastructure for public bodies to find and reuse these solutions.

What this means for you

For public-sector procurement officers, IT decision-makers, and legal counsel, Article 41 changes how you structure tender documents and internal software selection processes. You can no longer default to proprietary vendors without a rigorous, documented justification. The burden of proof shifts: you must actively demonstrate why a proprietary solution is necessary when an open-source alternative exists.

Actionable steps for implementation:

  1. Update Evaluation Criteria: Revise your procurement templates and internal selection guidelines to explicitly include "functionality, security, total cost, and other duly justified objective criteria" as key evaluation metrics. Ensure these criteria are weighted appropriately to reflect the "open source first" presumption.
  2. Conduct TCO Analysis: Move beyond license fee comparisons. Develop a standardized Total Cost of Ownership model that accounts for implementation, maintenance, support, training, and potential switching costs for both open-source and proprietary options. This analysis must be documented and available for audit.
  3. Document Justifications: If you choose a proprietary solution over an available open-source alternative, you must document why. Your justification should clearly explain how the proprietary solution better meets the specific functionality, security, or total cost requirements, or how other duly justified objective criteria necessitated the choice. This documentation is crucial for compliance with the "open source first" mandate.
  4. Assess Security Rigorously: Given the explicit mention of security, ensure your security assessments for open-source solutions are as robust as those for proprietary ones. Consider factors like community activity, patch frequency, available commercial support, and alignment with the European Cybersecurity Certification Scheme for Cloud Services (EUCS) where applicable.
  5. Engage with Open-Source Ecosystems: Proactively identify relevant open-source solutions for your cloud and AI needs. This may involve consulting the EU Open Source Solutions Catalogue (referenced in Article 43) or engaging with Open Source Programme Offices (OSPOs) within your organization or the network established under Article 44.

By adopting these practices, you not only comply with the proposed CADA but also contribute to a more resilient, secure, and competitive European digital infrastructure.

Common misconceptions

Misconception 1: "Open source first" means we must always choose the cheapest option. Reality: Article 41 requires considering "total cost," not just the lowest upfront price. A more expensive solution may be justified if it offers superior security, better functionality, or lower long-term maintenance costs. The test is holistic, not purely financial.

Misconception 2: We can ignore open-source solutions if we prefer proprietary vendors. Reality: The "open source first" principle creates a presumption. You must actively consider and evaluate open-source options. Choosing proprietary software requires a documented, objective justification based on the criteria in Article 41. Ignoring open-source alternatives without assessment would likely be non-compliant.

Misconception 3: "Other duly justified objective criteria" allows us to pick any factor we want. Reality: These criteria must be "relevant" and "duly justified." They must be linked to the specific needs of the procurement or project and applied objectively. Arbitrary or discriminatory criteria would not meet the regulatory standard.

Misconception 4: Open source is always less secure than proprietary software. Reality: Article 41 explicitly includes "security" as a key criterion, implying that open-source solutions can meet high security standards. Security should be assessed based on evidence (e.g., audit trails, community responsiveness, certifications) rather than assumptions about licensing models.

Misconception 5: The rule only applies to new software purchases. Reality: The obligation applies to "building their cloud and AI ecosystem or stack," which includes the development, procurement, and reuse of software components. It also encourages the reuse of existing open-source software, as reinforced by Article 42.

Official sources

Related

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