Summary Under the proposed Cloud and AI Development Act (CADA), Union entities and public sector bodies must actively "encourage" the use of open standards and components released under open source licences when building their cloud and AI ecosystems (Article 41). This "open source first" principle does not override existing EU public procurement rules but requires contracting authorities to treat open source as a justified, non-discriminatory evaluation factor. Compliance involves integrating these preferences into procurement documents under Article 32 (Union added value) while ensuring criteria remain "ancillary and not decisive." Crucially, open source solutions must still meet the relevant Union assurance levels (Articles 29–30) regarding sovereignty, data localisation, and third-country control.

Detail

The proposed Cloud and AI Development Act (CADA) introduces a specific, binding mandate for the European Union and its Member States to promote open source software within the public sector. This is not merely a suggestion; it is a legislative requirement to shift procurement behaviour towards transparency and autonomy.

The Legal Basis: Article 41 and the "Open Source First" Mandate

Article 41 of the CADA proposal establishes the core principle of promoting open source solutions. The text explicitly 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 provision fundamentally alters the default position of public buyers. Historically, proprietary software often prevailed due to perceived lower integration risks or established vendor support. Article 41 requires public buyers to actively consider open source alternatives as the primary option, provided they satisfy the same functional and security requirements. The evaluation must be based on four explicit pillars:

  1. Functionalities: The technical capability of the open source solution must match the requirements.
  2. Security: The solution must meet the cybersecurity standards required by the specific cloud or AI stack (potentially intersecting with the sovereignty levels in Annex II).
  3. Total Cost: This encompasses not just licensing fees (often zero for open source) but also implementation, maintenance, support, and customization costs.
  4. Other Relevant, Duly Justified Objective Criteria: This allows for considerations such as interoperability, vendor lock-in risks, and long-term sustainability.

Interaction with EU Procurement Rules (Directive 2014/24/EU)

CADA does not create a parallel procurement regime; it operates strictly within the framework of existing EU public procurement law, specifically Directive 2014/24/EU. Contracting authorities, as defined in Article 2(22) of that Directive, must ensure that their preference for open source adheres to the principles of equal treatment, non-discrimination, transparency, and proportionality.

Open Source as a Justified Evaluation Factor To comply with Article 41 without breaching procurement law, contracting authorities must structure tender documents with precision. Open source compliance can be integrated in two primary ways:

  1. Selection Criteria: Authorities may require bidders to demonstrate the capability to deliver open source solutions, particularly for contracts involving new software development or migration to open standards.
  2. Award Criteria: More commonly, open source preferences are embedded in the quality evaluation. Article 32 of CADA reinforces this by allowing contracting authorities to include non-price award criteria that evaluate a tenderer's contribution to the European cloud and AI ecosystem. This can include the use of software designed or manufactured in the Union, which often aligns with open source initiatives aimed at reducing dependency on third-country proprietary technologies.

However, these criteria must be ancillary and not decisive. As stipulated in Article 32(2)(d) of CADA, non-price award criteria must be "ancillary and not decisive in the award of the contract." Furthermore, Article 32(2)(b) and (c) require that such criteria "not confer unrestricted freedom of choice on the contracting authority" and be "expressly set out in the procurement documents or in the contract notice." The preference for open source cannot be used to arbitrarily exclude proprietary solutions if those solutions offer superior value for money or meet technical specifications more effectively.

Integration with CADA's Procurement Title (Articles 30–33)

Article 41 must be read in conjunction with Title IV of CADA, which outlines demand-side measures for cloud and AI procurement.

  • Risk Assessments and Sovereignty Levels (Articles 29–30): Before procuring any cloud service, public sector bodies must conduct risk assessments to determine the appropriate Union assurance level (1–4). Open source solutions must be evaluated against these sovereignty criteria. For instance, an open source cloud stack must still meet the data localisation and third-country control requirements of the relevant assurance level (e.g., Level 2 or 3) to be eligible for procurement in sensitive sectors. The fact that code is open source does not automatically grant sovereignty; the provider must still demonstrate compliance with Annex II criteria regarding control, personnel, and infrastructure.
  • Union Added Value (Article 32): Article 32 explicitly allows contracting authorities to award points for tenders that strengthen the digital technology supply chain in the Union. Using open source components, particularly those developed within the EU or those that reduce dependency on non-EU proprietary stacks, can be a valid metric for "Union added value."
  • Monitoring and SME Participation (Article 33): Member States must monitor their procurement of innovation in cloud and AI. Article 33(4) sets an objective for Member States to pursue awarding at least 25% of their procurement for cloud computing services and AI systems to innovative SMEs. Open source ecosystems often provide a lower barrier to entry for SMEs, allowing them to compete with larger proprietary vendors. By prioritising open source, authorities can indirectly support this SME participation goal, as smaller firms are more likely to offer customised open source solutions than large hyperscalers offering closed black-box services.

Implementation Mechanisms and Deadlines

While Article 41 sets the principle, the specific implementation mechanisms are partly delegated. The Commission is empowered to adopt implementing acts to specify the procedures for participation in the EuroCloud Federation (Article 34) and to detail the technical measures for open source integration.

Crucially, the power to adopt delegated acts to update technical criteria and audit rules is conferred in Article 44 (Exercise of the delegation), not Article 45. Article 44(2) specifically lists the articles subject to delegated acts, including Article 6 (Cloud and AI Leadership Initiatives), Article 16 (Union assurance levels), Article 20 (Independent audit), Article 21 (Audit evidence), and Article 31 (Private sector impact assessments).

Member States must ensure their national cloud and AI strategies (required under Article 7) reflect this "open source first" approach within one year of the Regulation's entry into force. Article 7(2)(g) explicitly requires these strategies to include measures to support the development of cloud computing stack technologies built upon open hardware and software.

Furthermore, Article 44 (titled "Network of Open Source Programme Offices") establishes a network of Open Source Programme Offices (OSPOs) to facilitate cooperation on the implementation of these obligations. This network will promote the exchange of information, best practices, and guidance on licensing, security, and procurement of open-source software.

What this means for you

For in-house counsel, procurement officers, and compliance teams in public sector bodies, the following actions are critical:

  1. Audit Current Procurement Templates: Review all standard tender documents for cloud and AI services. Ensure that "open source compatibility" or "use of open standards" is included as a legitimate, weighted award criterion. Remove any language that implicitly favours proprietary formats without objective justification.
  2. Develop Objective Criteria: Document the "duly justified objective criteria" used to evaluate open source vs. proprietary options. This might include a Total Cost of Ownership (TCO) model that accounts for potential licensing fees of proprietary software versus the support costs of open source. This documentation is essential to defend against challenges from unsuccessful bidders.
  3. Align with Sovereignty Risk Assessments: When conducting the risk assessments required by Article 29, evaluate whether open source solutions offer better sovereignty outcomes. For example, open source code can be audited for backdoors, potentially satisfying higher assurance levels (Level 3 or 4) more easily than opaque proprietary software, provided the provider meets the personnel and control criteria in Annex II.
  4. Monitor SME Participation: Track the share of contracts awarded to SMEs in your cloud/AI procurement. If this share is below 25%, consider whether a shift towards open source specifications could unlock competition from smaller, agile European providers.
  5. Engage with the OSPO Network: Article 44 establishes a network of Open Source Programme Offices. Engage with your national OSPO to stay updated on best practices, templates, and guidance for implementing Article 41. This network will facilitate the exchange of information and best practices on licensing, security, and procurement of open-source software.

Common misconceptions

Misconception 1: "Open Source First" means we must only buy open source. This is incorrect. Article 41 uses the word "encourage," not "mandate exclusive use." Proprietary solutions remain eligible if they offer better value, security, or functionality. The key is that the default assumption must shift towards open source, and any deviation must be objectively justified.

Misconception 2: Open source is always cheaper, so it should win on price alone. Total cost includes maintenance, support, and integration. A complex open source solution requiring significant in-house expertise may be more expensive than a turnkey proprietary solution. Article 41 explicitly requires consideration of "total cost," not just licensing fees.

Misconception 3: We can exclude proprietary vendors solely because they are not open source. This would likely violate Directive 2014/24/EU principles of non-discrimination. You can award more points for open source contributions or Union added value (Article 32), but you cannot exclude a bidder solely for using proprietary technology if that technology meets the technical specifications.

Misconception 4: Article 41 replaces the need for cybersecurity certifications. No. Open source components must still meet the cybersecurity requirements of the relevant Union assurance level (Annex II). An open source cloud service must still undergo independent audits (for Levels 2–4) and demonstrate compliance with data localisation and third-country control criteria.

Related

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