Summary As proposed in COM(2026) 502 final, the Cloud and AI Development Act (CADA) mandates that Union entities and public sector bodies prioritize open source solutions to strengthen technological sovereignty. Under Article 41, public bodies must "use and facilitate the reuse of open standards and components released under an open source licence" when building cloud and AI ecosystems, subject to security and cost criteria. To operationalize this, organizations must establish or join an Open Source Programme Office (OSPO) connected to the EU-wide network (Article 44) and ensure any software released for reuse is listed via a repository connected to the EU Open Source Solutions Catalogue (Articles 42 and 43).

Detail

The proposed CADA introduces a specific "open source first" framework within Chapter V of Title IV. This is not merely a recommendation but a structured obligation designed to reduce vendor lock-in, enhance transparency, and foster a shared European digital ecosystem. The provisions apply to Union entities and public sector bodies as defined in the Regulation.

1. The "Open Source First" Evaluation Obligation (Article 41)

Article 41 requires the Union and Member States to take necessary measures to encourage public 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."

  • Evaluation Criteria: The choice is not blind. Public bodies must evaluate options based on "functionalities, including security, total cost, and other relevant, duly justified objective criteria."
  • Strategic Rationale: As noted in Recital 81, access to source code enables auditability, fosters collaboration, and reduces dependency on single vendors. The goal is to limit the risk of vendor lock-in and ensure better value for public expenditure.
  • Scope: This applies to the construction of the "cloud and AI ecosystem or stack," covering the underlying infrastructure, software tools, and AI models used by the public sector.

2. Mandatory Listing in the EU OSS Catalogue (Articles 42 & 43)

If a public body develops software or holds intellectual property rights to software and decides to make it available for reuse under an open source licence, it cannot simply publish it on a generic platform.

  • The Connection Requirement: Article 42 stipulates that such software must be made available using a catalogue or repository that is "connected to, and made accessible through, the EU Open Source Solutions Catalogue (EU OSS Catalogue)."
  • Centralized Hub: Article 43 establishes that the Commission shall provide and maintain this centralised catalogue. It will be hosted on the Interoperable Europe portal and be accessible electronically free of charge.
  • Purpose: This centralization ensures that solutions developed by one public body are easily searchable and discoverable by others, preventing duplication of effort and maximizing the value of public investment.

3. The OSPO Network (Article 44)

To support the implementation of these obligations, CADA establishes a formal governance structure: the Network of Open Source Programme Offices (OSPO Network).

  • Establishment: The Commission is obligated to establish this network to facilitate cooperation on the implementation of open source obligations (Article 44(1)).
  • Membership: Open Source Programme Offices established by public sector bodies at local, regional, or national levels, as well as those by Union entities, "may request from the Commission to join the OSPO Network" (Article 44(2)).
  • Core Tasks: The network is tasked with:
    • Facilitating the exchange of information, experience, and best practices on licensing, security, maintenance, and procurement (Article 44(3)(a)).
    • Promoting the sharing and reuse of open-source software (Article 44(3)(b)).
    • Contributing to the development of guidance, templates, or recommendations (Article 44(3)(c)).
    • Collaborating on open-source projects of common interest (Article 44(3)(d)).

What this means for you

For public-sector procurement officers, IT directors, and legal counsel, CADA's open source provisions translate into a mandatory operational workflow. The following checklist outlines the practical steps to achieve compliance with the proposal.

Step 1: Institutionalize the "Open Source First" Evaluation

Before initiating any procurement for cloud, AI, or software, your organization must integrate open source assessment into the decision-making process.

  • Update Procurement Checklists: Modify your standard procurement templates to include a mandatory "Open Source Availability" filter. Before considering proprietary solutions, verify if a suitable open source alternative exists.
  • Apply Objective Criteria: When evaluating options, document the assessment against the criteria in Article 41: functionalities, security, and total cost of ownership (TCO).
  • Justify Deviations: If you choose a proprietary solution, you must be prepared to provide a "duly justified" rationale based on objective criteria (e.g., specific security requirements that open source cannot currently meet). This documentation is critical for demonstrating compliance.

Step 2: Establish or Join an OSPO

You cannot effectively manage open source strategy without dedicated governance. Article 44 envisions a networked approach to this governance.

  • Internal Setup: If your organization lacks an Open Source Programme Office (OSPO), establish one immediately. This office should be responsible for legal review of licences, security audits of components, and strategy alignment.
  • Join the Network: Once established, your OSPO must actively request to join the OSPO Network under Article 44(2). This is not just a formality; it is the primary channel for accessing EU-wide guidance, templates, and legal support.
  • Engage in Collaboration: Proactively participate in the network's tasks. Use the platform to share your own best practices, access shared guidance on licensing, and collaborate on joint projects with other public bodies to reduce costs and improve quality.

Step 3: Connect Your Repository to the EU OSS Catalogue

If your body develops custom software, tools, or AI models, you must prepare for reuse in a specific manner.

  • Technical Integration: Ensure your internal software repositories or catalogues are technically capable of connecting to the EU OSS Catalogue. You cannot simply host code on a private server or a generic public site like GitHub without this connection.
  • The Listing Process: When you decide to release software under an open source licence, do not just publish it. You must ensure it is listed via a repository that feeds into the central EU OSS Catalogue as mandated by Article 42.
  • Metadata and Discoverability: Prepare your software metadata (descriptions, licence types, usage instructions) to meet the standards of the EU OSS Catalogue. This ensures your solution is discoverable by other public administrations, fulfilling the "facilitate reuse" obligation.

Step 4: Leverage the OSPO Network for Procurement

Use the network to modernize your procurement strategies.

  • Joint Procurement: Collaborate with other public bodies via the OSPO Network to identify common technical challenges and launch joint open source procurement initiatives.
  • Template Adoption: Adopt the guidance and templates developed by the network for open source clauses in contracts, ensuring consistency and legal robustness across the Union.

Common misconceptions

"CADA forces us to use open source for everything." Incorrect. Article 41 states that public bodies should use and facilitate the reuse of open standards and components, but explicitly requires taking into account "functionalities, including security, total cost, and other relevant, duly justified objective criteria." It is a priority-based obligation, not an absolute ban. If a proprietary solution is objectively superior for security or cost reasons, it can still be chosen, provided the decision is duly justified and documented.

"We can just post our open source code on GitHub or GitLab." Incorrect. While you may host the code on a platform like GitHub, Article 42 specifies that when making software available for reuse, it must be done via a catalogue or repository that is "connected to, and made accessible through, the EU Open Source Solutions Catalogue." The central EU catalogue is the mandatory discovery layer. Without this connection, the software does not meet the "facilitate reuse" requirement of the proposal.

"The OSPO Network is optional, so we can ignore it." While individual offices "may request" to join (Article 44(2)), the establishment of the network itself is a mandatory obligation of the Commission (Article 44(1)). For public bodies, joining is the primary mechanism for receiving the guidance, templates, and legal support necessary to comply with the rest of the open source chapter. Ignoring the network risks leaving an organization without access to essential resources and best practices required to navigate the new regulatory landscape.

"Open source means no security." On the contrary, Recital 81 explicitly states that access to source code "enables auditability, fosters collaboration and reuse and reduces dependency on a single vendor." The proposal views open source as a tool to enhance security through transparency and community scrutiny, provided that security is evaluated as an objective criterion under Article 41.

Related

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