What is a public sector body for CADA open source purposes?

Under the proposed Cloud and AI Development Act (CADA), the term "public sector body" is not defined anew but incorporates the definition from Directive (E

Summary Under the proposed Cloud and AI Development Act (CADA), the term "public sector body" is not defined anew but incorporates the definition from Directive (EU) 2019/1024 via Article 2(6) of the proposal. This definition encompasses national, regional, and local public administrations, as well as bodies governed by public law. These entities are subject to specific obligations under Articles 41–44: if they voluntarily decide to make software they own available for reuse under an open-source licence, they must do so via a repository connected to the EU Open Source Solutions Catalogue (Article 42). While the Act encourages an "open source first" approach (Article 41), it does not mandate that all software be open-sourced, only that the sharing mechanism be centralised when sharing occurs.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, establishes a framework to strengthen Europe's cloud and AI ecosystem. A key pillar of this framework is the promotion of open-source solutions to enhance transparency, security, and technological autonomy. To determine which entities must comply with these rules, one must examine the interplay between the definitions in Title I and the specific obligations in Chapter V of Title IV.

The Definition: Article 2(6) and Directive 2019/1024

CADA does not create a bespoke definition for "public sector body." Instead, Article 2(6) explicitly cross-references existing EU law. It states:

"'public sector body' means public sector body as defined in Article 2, point (1), of Directive (EU) 2019/1024."

Directive (EU) 2019/1024 (the Open Data Directive) defines a public sector body broadly to ensure comprehensive coverage of the public administration. This includes:

The State: Central government ministries and departments.
Regional or local authorities: This explicitly covers regional governments, municipalities, cities, and local councils.
Bodies governed by public law: Entities established for the purpose of meeting needs in the general interest, having legal personality, and financed or supervised by the State or regional/local authorities.
Associations: Formed by one or more of the above authorities or bodies.

Consequently, the scope of CADA's open-source obligations extends far beyond central government. It captures the entire spectrum of public administration, from a national ministry developing a frontier AI model to a local municipality creating a waste-management application, provided the entity holds the intellectual property rights to the software.

The Obligations: Articles 41–44

The obligations for these bodies are set out in Chapter V (Open source) of Title IV (Autonomy).

Article 41: Promoting open source solutions This article sets the strategic tone. 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 ecosystems. Crucially, the choice of software must take into account functionalities, security, total cost, and other relevant, duly justified objective criteria. This establishes a "consideration" duty rather than an absolute mandate to use open source in every instance.

Article 42: Share and reuse of software This is the core operational obligation for public sector bodies regarding software assets. It applies when a Union entity or public sector body holds intellectual property rights to software and voluntarily decides to make it available for reuse under an open-source licence. The article imposes a strict condition on how this sharing must occur:

"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 means that if a public body chooses to open-source its software, it cannot simply host it on a private GitLab instance or a disconnected GitHub repository. It must ensure its repository is technically connected to the central EU Open Source Solutions Catalogue.

Article 43: EU Open Source Solutions Catalogue The Commission is required to provide and maintain this centralised catalogue. It will be hosted on the Interoperable Europe portal (established by Regulation (EU) 2024/903) and must be accessible electronically free of charge. The Commission will decide on requests from public bodies to connect their existing catalogues or repositories to this central hub.

Article 44: Network of Open Source Programme Offices To support compliance, CADA establishes a network of Open Source Programme Offices (OSPOs). Public sector bodies at local, regional, or national levels may request to join this network. The OSPO network's tasks include facilitating the exchange of information on licensing, security, and maintenance, and promoting the sharing of open-source software.

Scope of Application

The obligations apply to software developed by or for the public sector body.

Developed by: Software created internally by public administration staff.
Developed for: Software commissioned from private vendors where the contract grants the public body the intellectual property rights.

If a public body commissions software but the vendor retains the IP, Article 42 does not apply to that specific asset unless the vendor voluntarily agrees to open-source it (in which case the vendor, not the public body, would be the actor, though the public body might still benefit from Article 41's encouragement). However, if the public body owns the IP and decides to release it, Article 42 is triggered.

What this means for you

For in-house counsel, IT directors, and compliance officers within national, regional, and local public administrations, the proposed CADA introduces a new governance layer for software assets.

Map Your IP Portfolio: Conduct an audit to identify all software for which your entity holds intellectual property rights. This includes custom-built applications, AI models, and data processing tools.
Prepare for Repository Integration: If your entity plans to release software under an open-source licence, you must ensure your technical infrastructure can connect to the EU Open Source Solutions Catalogue. This may require upgrading existing internal repositories or adopting new metadata standards to ensure interoperability with the Interoperable Europe portal.
Document "Open Source First" Assessments: Under Article 41, when procuring or developing new cloud and AI solutions, you must be able to demonstrate that you have considered open-source alternatives. Your decision-making records should explicitly weigh functionalities, security, and total cost of ownership, as required by the proposal.
Join the OSPO Network: Consider establishing an internal Open Source Programme Office or joining the network established under Article 44. This will provide access to best practices on licensing, security vulnerability management, and the specific technical requirements for connecting to the EU catalogue.
Monitor Implementing Acts: The Commission is empowered to adopt implementing acts to specify the technical and operational measures for the OSPO network and the catalogue connection. Stay alert for these updates, as they will define the precise technical protocols for compliance.

Common misconceptions

"All public sector software must be open source." This is incorrect. Article 42 applies only when a public sector body voluntarily decides to make software available for reuse under an open-source licence. The Act does not mandate that all software be open-sourced. However, Article 41 does create a strong obligation to consider and encourage the use of open-source solutions when building stacks.

"Only central government ministries are affected." No. The definition in Article 2(6) explicitly includes regional and local authorities. A municipality developing a custom AI tool for traffic management or a regional health agency creating a patient-data platform is subject to the same open-source reuse rules as a national ministry if they own the IP and choose to share it.

"Open source means free of cost." While open-source software often reduces licensing fees, Article 41 explicitly requires that the choice of software consider "total cost." This includes support, maintenance, integration, and training costs. Compliance is about making an informed, objective choice based on value and security, not simply choosing the option with the lowest upfront price.

"I can host my open-source code on any private server." If you decide to open-source software, Article 42 requires that the repository be connected to the EU Open Source Solutions Catalogue. Hosting code on a disconnected private server without this connection would not satisfy the proposal's requirements for public sector bodies.

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