Summary No, the proposed Cloud and AI Development Act (CADA) does not impose an absolute, rigid mandate requiring public authorities to exclusively use open-source software. Instead, Article 41 establishes an "open source first" principle, obliging the Union and Member States to encourage and facilitate the use of open standards and components. This preference must be balanced against functionalities, security, total cost, and other "duly justified objective criteria." While the use of open source is strongly promoted to reduce vendor lock-in and strengthen sovereignty, the proposal explicitly allows for proprietary solutions where justified. However, if public bodies do release software they own as open source, Article 42 mandates that it be made available through a repository connected to the EU Open Source Solutions Catalogue (Article 43), supported by a coordinated Network of Open Source Programme Offices (Article 44).

Detail

The proposed Cloud and AI Development Act (CADA), as set out in COM(2026) 502 final, identifies open source as a critical lever for achieving technological sovereignty, enhancing security, and fostering innovation. The legislative text, particularly Title IV, Chapter V, creates a comprehensive ecosystem to promote open-source adoption across the EU public sector. However, the legal framework is designed to be flexible rather than prohibitive, recognizing that different use cases may require different technological solutions.

The "Open Source First" Principle (Article 41)

The cornerstone of the proposal's approach to software licensing is Article 41, titled "Promoting open source solutions and open source first." This article does not create a blanket prohibition on proprietary software. Instead, it imposes a duty on the Union and Member States to 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.

The text of Article 41 is precise in its limitations:

"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 phrasing creates a "soft mandate." Public authorities must actively consider open-source alternatives as a primary option. However, the decision-maker retains the discretion to select proprietary software if specific, objective criteria justify the choice. The proposal explicitly lists the factors that must be weighed:

  • Functionalities: Does the open-source solution meet the specific technical and operational requirements of the public service?
  • Security: Is the open-source solution sufficiently secure for the intended purpose, or does a proprietary solution offer superior protection for sensitive data?
  • Total Cost: The assessment must go beyond licensing fees (which are often zero for open source) to include the "total cost," encompassing maintenance, support, training, integration, and long-term operational expenses.
  • Other relevant, duly justified objective criteria: This catch-all provision allows for flexibility in unique circumstances, such as specific regulatory compliance needs or the availability of specialized proprietary tools.

The Explanatory Memorandum (Recital 81) clarifies the strategic intent behind this approach. It states that "Access to the source code enables auditability, fosters collaboration and reuse and reduces dependency on a single vendor, thereby limiting the risk of vendor lock-in." The goal is to strengthen the Union's digital autonomy and ensure better value for public expenditure, not to eliminate the commercial software market.

Mandatory Reuse via the EU OSS Catalogue (Article 42)

While the choice to use open source is encouraged but not absolute, the dissemination of public-sector software is more strictly regulated. Article 42, "Share and reuse of software," addresses the scenario where a public body decides to make its own software available for reuse.

The 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 provision ensures that publicly funded software, once released as open source, does not remain siloed in isolated national or local repositories. It mandates a centralized discovery mechanism. If a public authority chooses to open-source its code, it must ensure that the repository hosting that code is technically connected to the central EU catalogue. This prevents fragmentation and maximizes the potential for cross-border reuse, reducing duplication of effort across the Union.

The EU Open Source Solutions Catalogue (Article 43)

To operationalize the reuse mandate, Article 43 requires the Commission to provide and maintain the EU Open Source Solutions Catalogue (EU OSS Catalogue). This serves as the central hub for the public sector's open-source ecosystem.

Key features of the Catalogue as defined in Article 43 include:

  • Centralized Access: It acts as a single point of access for software made available for reuse by Union entities and public sector bodies.
  • Hosting: The Catalogue is hosted on the Interoperable Europe portal, as referenced in Regulation (EU) 2024/903, ensuring alignment with broader EU digital interoperability goals.
  • Cost: It is accessible electronically free of charge.
  • Connectivity: The Commission is empowered to decide on requests from any Union entity or public sector body to connect their own catalogues or repositories to the EU OSS Catalogue, based on objective and relevant criteria.

This infrastructure transforms the open-source landscape from a collection of disparate national initiatives into a unified, searchable resource for the entire EU public sector.

The Network of Open Source Programme Offices (Article 44)

Recognizing that policy alone is insufficient without implementation capacity, Article 44 establishes a Network of Open Source Programme Offices (OSPO Network). This network is designed to facilitate cooperation and ensure consistent implementation of the open-source obligations across the Union.

The tasks of the OSPO Network, as outlined in Article 44, include:

  • Exchange of Best Practices: Facilitating the sharing of information, experience, and best practices between Member States and the Commission.
  • Addressing Challenges: Discussing common technical, legal, and organizational challenges, specifically regarding licensing, security, maintenance, and procurement of open-source software.
  • Promoting Reuse: Actively promoting the sharing and reuse of open-source software by public sector bodies.
  • Guidance Development: Contributing, on a voluntary and non-binding basis, to the development of guidance, templates, or recommendations on sharing and reusing open-source software.

The Commission is tasked with supporting and coordinating this network, convening meetings of its members at least twice a year. This ensures that local, regional, and national OSPOs remain aligned with EU-wide strategic objectives and can provide consistent support to public administrations.

What this means for you

For public-sector procurement officers, IT directors, and policy makers, the proposed CADA represents a significant shift in how software strategies are formulated. While you are not forced to abandon proprietary software, the burden of proof shifts toward justifying why an open-source alternative was not chosen.

  1. Revise Procurement Policies: Your internal procurement guidelines must be updated to reflect the "open source first" principle. You should establish a formal process for evaluating open-source alternatives against proprietary ones. This evaluation must explicitly consider total cost of ownership (TCO), security posture, and the risk of vendor lock-in.
  2. Document "Duly Justified" Exceptions: If your decision is to proceed with proprietary software, you must document the "duly justified objective criteria" that led to this choice. Mere preference is insufficient; you must demonstrate that functionalities, security, or total cost considerations objectively favored the proprietary solution.
  3. Plan for Reuse: If your administration develops custom software, plan for its potential release as open source. Ensure that your IT infrastructure includes a repository capable of connecting to the EU OSS Catalogue (Article 42) to comply with the reuse mandate if you choose to open-source the code.
  4. Engage with OSPOs: Identify and connect with your national or regional Open Source Programme Office (OSPO). Participate in the OSPO Network (Article 44) to access the guidance, templates, and peer support necessary to navigate these new requirements effectively.
  5. Prioritize Interoperability: Even when using proprietary software, prioritize the use of open standards and open-source components within your cloud and AI stack. This aligns with the broader goals of CADA to ensure resilience and reduce dependencies on single vendors.

Common misconceptions

"CADA bans proprietary software."

  • Reality: CADA does not ban proprietary software. Article 41 explicitly allows for exceptions based on functionalities, security, total cost, and other objective criteria. The law requires an encouragement of open source, not an absolute prohibition of alternatives.

"All public-sector software must be open-sourced."

  • Reality: Article 42 applies only to software that public bodies choose to make available for reuse under an open-source license. It does not force every piece of internal software to be public. However, if you do release it, you must use the EU OSS Catalogue.

"Open source is always cheaper."

  • Reality: While licensing fees are often zero, Article 41 requires considering "total cost." This includes maintenance, support, training, and integration. A proprietary solution might be more cost-effective in the long run if it requires less internal expertise to manage or offers superior support.

"The EU OSS Catalogue is a marketplace for buying software."

  • Reality: The catalogue (Article 43) is a repository for software made available for reuse by public bodies. It is not a commercial procurement marketplace for buying third-party commercial software, though it may influence procurement by highlighting available open-source alternatives.

Related

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