Summary As proposed in COM(2026) 502 final, the Cloud and AI Development Act (CADA) would require the EU and Member States to "encourage" Union entities and public sector bodies to prioritize open source solutions when building cloud and AI ecosystems, weighing factors like security, total cost, and functionality (Article 41). Crucially, if a public body develops software and chooses to make it available for reuse under an open source license, it must publish it in a repository connected to the EU Open Source Solutions Catalogue (Article 42). To enable this, procurement contracts must secure sufficient intellectual property (IP) rights from vendors. Furthermore, Article 44 establishes a network of Open Source Programme Offices (OSPOs) to address common legal and procurement challenges, meaning procurement teams should align their clauses with emerging best practices from this network.

Detail

The proposed Cloud and AI Development Act (CADA) represents a strategic pivot in how the European public sector acquires and manages software. By embedding open source principles into the legislative framework, CADA aims to reduce vendor lock-in, enhance transparency, and foster a competitive European digital ecosystem. For legal counsel and procurement officers, the interplay between Article 41 (promotion of open source), Article 42 (reuse obligations), and Article 44 (OSPO network) dictates a new standard for drafting tender documents and managing intellectual property.

The "Open Source First" Principle and Evaluation Criteria (Article 41)

Article 41 establishes the foundational policy for open source adoption. 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 is not an absolute ban on proprietary software. Instead, it creates a conditional preference. The article explicitly states that this encouragement must take into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria."

In practical terms for public procurement, this means:

  1. Evaluation Factors: Tender documents must include "open source first" as a distinct evaluation criterion. Procurement authorities cannot default to proprietary solutions without justification.
  2. Objective Scoring: The scoring methodology must explicitly weigh:
    • Functionalities: Does the open source solution meet the technical requirements?
    • Security: Is the software auditable and free from backdoors?
    • Total Cost: Does the solution offer a lower total cost of ownership (TCO) compared to proprietary alternatives, considering licensing, maintenance, and lock-in risks?
    • Other Criteria: This may include community vitality, interoperability, and the ability to avoid vendor lock-in.
  3. Justification of Deviation: If a contracting authority selects a proprietary solution, the procurement file must document why it was superior based on the Article 41 criteria. For instance, if a proprietary solution is chosen, the authority must demonstrate that it offers significantly better security or a lower total cost that outweighs the benefits of an open source alternative.

Intellectual Property Clauses to Enable Article 42 Reuse

The most critical legal challenge in CADA-compliant procurement lies in Article 42. This article states: "When making software to which they hold intellectual property rights available for reuse under an open source licence, a Union entity or public sector body shall do so using a catalogue or repository that is connected to, and made accessible through, the EU OSS Catalogue referred to in Article 43."

This creates a downstream obligation that fundamentally alters upstream procurement contracts. For a public body to "make software available for reuse" under an open source license, it must first hold the intellectual property rights to that software. Standard commercial contracts often grant the vendor ownership of the code or restrict redistribution. To comply with the potential future enforcement of Article 42, procurement clauses for custom software development must be drafted to ensure the public buyer retains the necessary rights.

Key IP clauses required in CADA-compliant contracts include:

  • Assignment or Broad License: Contracts must include clauses that either assign copyright of the custom-developed software to the public buyer or grant a perpetual, irrevocable, worldwide, royalty-free license to use, modify, and redistribute the code. This license must explicitly permit the public body to release the software under an open source license (e.g., EUPL, Apache 2.0, MIT) if they choose to do so.
  • Third-Party Component Clearance: Vendors must be obligated to identify all third-party open source components used in the deliverable. The contract must ensure that the licensing terms of these components (e.g., copyleft licenses like GPL) do not prevent the public body from releasing the combined work under the desired open source license or, conversely, that they do not inadvertently contaminate proprietary modules if the buyer intends to keep parts of the system closed.
  • Documentation and Source Code Access: The contract must grant the public body the right to access, modify, and redistribute not only the source code but also the technical documentation, which is essential for the effective reuse of open source software by other public entities.
  • Warranty of Non-Infringement: Vendors must warrant that the software does not infringe on third-party IP rights, protecting the public body from liability when they subsequently release the code under an open source license.

Without these specific IP ownership clauses, a public body may develop software but lack the legal authority to place it in the EU OSS Catalogue, rendering Article 42 compliance impossible.

Addressing Procurement Challenges via the OSPO Network (Article 44)

Article 44 establishes a network of Open Source Programme Offices (OSPOs) to facilitate the implementation of CADA's open source obligations. This network is not merely advisory; it is a central mechanism for resolving the legal and technical complexities of open source procurement.

Article 44(3)(a) specifically tasks the OSPO Network with "facilitating the exchange of information, experience and best practices between Member States and the Commission, in particular by discussing common technical, legal and organisational challenges, including those related to licensing, security, maintenance and procurement of open-source software."

For procurement officers, this has several implications:

  • Standardization: The OSPO Network will likely develop standardized licensing templates and procurement clauses. Ignoring these emerging standards could lead to non-compliance with the "best practices" expected under CADA.
  • Risk Mitigation: The network addresses specific challenges such as liability for open source components, security maintenance obligations, and the legal frameworks for sharing code. Procurement teams should align their clauses with the guidance emerging from this network to mitigate legal risk.
  • Collaboration: Article 44(3)(b) promotes the sharing and reuse of open-source software. Procurement clauses should be drafted to facilitate, rather than hinder, this sharing, potentially by including provisions that allow for collaborative development or joint ownership models where appropriate.

Integration with Existing Public Procurement Directives

CADA operates alongside existing Public Procurement Directives (such as Directive 2014/24/EU). It does not replace these directives but adds a layer of strategic preference. Procurement clauses must remain compliant with the principles of non-discrimination, transparency, and equal treatment. However, Article 41's encouragement of open source allows public buyers to structure award criteria that favor solutions with open standards and open source licenses, provided the criteria are linked to the subject matter of the contract and are not restrictive.

For example, a procurement clause might award extra points for solutions that:

  • Provide full source code access.
  • Use widely adopted open standards.
  • Demonstrate a sustainable community support model.

These criteria must be justified under Article 41's requirement to consider functionality, security, and total cost. The "open source first" principle is a tool to achieve better value and resilience, not a rigid mandate that overrides the core principles of EU public procurement law.

What this means for you

For in-house counsel, procurement officers, and compliance teams in the public sector, the proposed CADA provisions require a proactive overhaul of procurement strategies and contract templates.

  1. Audit and Update Procurement Templates: Review current tender documents and contract templates immediately. Ensure that evaluation criteria explicitly include "open source first" principles as mandated by Article 41. Incorporate objective scoring for security, total cost of ownership, and functionality.
  2. Strengthen IP Clauses for Custom Development: In contracts for custom software, ensure that IP clauses grant the public buyer the right to release the software under an open source license. If the vendor retains copyright, the license granted must be broad enough to permit redistribution under open source terms. This is essential for future compliance with Article 42.
  3. Engage with the OSPO Network: Actively utilize the resources of the OSPO Network (Article 44) for guidance on standard clauses, licensing best practices, and risk mitigation. This reduces legal risk and ensures alignment with EU-wide standards.
  4. Prepare for the EU OSS Catalogue: Familiarize your organization with the EU Open Source Solutions Catalogue (Article 43). If your organization develops software, plan for its potential inclusion in this catalogue. Ensure internal processes for code clearance, documentation, and licensing are ready to support this.
  5. Document Decision-Making: If a proprietary solution is chosen over an open source alternative, rigorously document the justification based on Article 41 criteria (functionality, security, total cost). This documentation is critical for demonstrating compliance with the "encouragement" obligation and for defending procurement decisions against challenges.

Common misconceptions

"CADA mandates open source for all public procurement." This is incorrect. Article 41 uses the term "encourage," not "mandate." Public bodies must consider open source solutions, but they can choose proprietary solutions if justified by objective criteria such as superior security, functionality, or lower total cost. The key is the justification and the evaluation process, not the outcome.

"All software developed by public bodies must be open source." Article 42 applies only to software that the public body chooses to make available for reuse under an open source license. It does not force public bodies to open source all their software. However, if they do choose to reuse it, they must do so via the connected catalogue. The obligation is on the method of sharing, not the act of sharing itself.

"Open source clauses are optional in procurement." While CADA does not prescribe specific clause wording, it creates a regulatory environment where failing to consider open source options and failing to secure IP rights for potential reuse could be seen as non-compliant with the broader objectives of the Act. Procurement clauses should proactively address these issues to mitigate risk.

"The OSPO Network is just an advisory body with no impact on contracts." Article 44(3)(a) explicitly tasks the OSPO Network with discussing "common technical, legal and organisational challenges, including those related to... procurement of open-source software." Guidance from the OSPO Network will likely become the de facto standard for what constitutes "best practice" in open source procurement clauses. Ignoring this guidance could lead to contractual inefficiencies or non-compliance with future delegated acts.

Related

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