Summary Under the proposed Cloud and AI Development Act (CADA), Union entities and public sector bodies that hold intellectual property rights to software and choose to make it available for reuse must do so under an open source licence. Crucially, as proposed in Article 42, this software must be published via a catalogue or repository that is connected to, and made accessible through, the EU Open Source Solutions Catalogue (EU OSS Catalogue). This ensures that public-sector software is findable, accessible, and reusable across the Union, preventing siloed local repositories. The definition of "open source licence" is fixed by Article 2(25), which references the Interoperable Europe Act.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, seeks to strengthen the EU's cloud and AI ecosystem by reducing dependencies on non-European providers and fostering a competitive internal market. A central pillar of this strategy is the promotion of open source software (OSS) within the public sector. CADA posits that open source enhances transparency, security, and efficiency while limiting vendor lock-in.

For CTOs, architects, and legal teams evaluating the practical impact of CADA, the specific licensing and publishing obligations for public-sector software are defined in Title IV, Chapter V of the proposal. While Article 41 sets the general policy direction to "encourage" the use of open standards and components, Article 42 establishes a binding operational requirement for those entities that decide to share software.

The Binding Obligation: Article 42 and Article 2(25)

The core compliance mechanism is found in Article 42, which 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 creates a mandatory technical and procedural link between any public-sector software repository and the central EU OSS Catalogue. It does not force every public body to host its software directly on the EU OSS Catalogue itself, but it strictly requires that any local or national catalogue used for distribution must be interoperable and connected to the central hub.

To understand the scope of this obligation, one must look at the definition of "open source licence" provided in Article 2(25) of the proposal. This article defines the term by reference to Article 2, point (12), of Regulation (EU) 2024/903 (the Interoperable Europe Act). This cross-reference ensures that the definition aligns with established open source standards, guaranteeing that the licence allows users to run, study, change, and distribute the software. Consequently, a public body cannot simply label software as "open" if it does not meet the specific legal criteria of the Interoperable Europe Act.

The EU Open Source Solutions Catalogue (EU OSS Catalogue)

The infrastructure supporting this obligation is the EU Open Source Solutions Catalogue (EU OSS Catalogue), established under Article 43. The Commission is tasked with providing and maintaining this centralised catalogue to access software made available for reuse by Union entities and public sector bodies.

Key features of the EU OSS Catalogue as proposed include:

  • Centralisation: It serves as the single entry point for searching and accessing reusable software across the Union.
  • Hosting: The catalogue shall be hosted on the Interoperable Europe portal, referred to in Article 8 of Regulation (EU) 2024/903.
  • Accessibility: It must be accessible electronically free of charge.
  • Connectivity: The Commission will decide, based on objective and relevant criteria, whether to connect external catalogues or repositories maintained by Union entities or public sector bodies to the EU OSS Catalogue.

This structure supports a federated approach. Public bodies can maintain their own national or regional repositories, but to comply with Article 42, these repositories must be technically integrated with the EU OSS Catalogue. This ensures that software developed in one Member State or by one EU agency is discoverable by entities in other Member States, maximizing the return on public investment and avoiding duplication of effort.

Choosing the Right Open Source Licence

While CADA mandates the use of an open source licence for any software made available for reuse, it does not prescribe a specific licence text (e.g., MIT, Apache 2.0, GPL). However, the choice of licence has significant implications for reuse and compliance.

  1. Compatibility with Article 2(25): The licence chosen must meet the definition in Article 2(25), which references the Interoperable Europe Act. This typically requires the licence to allow for free use, modification, and distribution. Licences with restrictive clauses that undermine these freedoms may not qualify.
  2. Intellectual Property Authority: Article 42 applies specifically to software "to which they hold intellectual property rights." Therefore, public bodies must ensure they have the legal authority to license the software as open source. This includes verifying that any third-party components included in the software are compatible with the chosen open source licence and do not impose conflicting obligations.
  3. Strategic Selection: While not mandated by CADA, permissive licences (like MIT or Apache 2.0) are often preferred for public sector software to maximize adoption and integration into proprietary or mixed ecosystems, which is common when working with SMEs and private sector partners.

The Role of Open Source Programme Offices (OSPOs)

To support the implementation of these obligations, CADA establishes a network of Open Source Programme Offices (OSPOs) under Article 44. The OSPO Network will facilitate cooperation on the implementation of Chapter V, including the sharing and reuse of open-source software.

For public sector bodies, engaging with the OSPO Network can provide guidance on:

  • Selecting appropriate open source licences that align with the definition in Article 2(25).
  • Technical requirements for connecting local repositories to the EU OSS Catalogue.
  • Best practices for maintaining and supporting open source software.

The OSPO Network will exchange information, experience, and best practices between Member States and the Commission, helping to standardize the approach to open source licensing and reuse across the EU.

What this means for you

For Public Sector CTOs and Architects:

  • Audit Your Software Inventory: Identify software developed by or for your entity where you hold intellectual property rights. Determine which of these projects are candidates for open source release.
  • Review Repository Infrastructure: Ensure your current code repositories (e.g., GitHub, GitLab, or internal servers) can be technically connected to the EU OSS Catalogue. This may involve API integration, metadata standardization, or federated search capabilities to meet the "connected to" requirement of Article 42.
  • Standardize Licensing: Adopt a standard set of open source licences for your organization to simplify compliance. Ensure these licences are consistent with the definition in Article 2(25) and the Interoperable Europe Act.
  • Engage with OSPOs: Participate in the OSPO Network (Article 44) to stay updated on technical requirements and best practices for connecting to the EU OSS Catalogue.

For SMEs and Private Sector Partners:

  • Opportunity for Reuse: The EU OSS Catalogue will provide a centralized source of high-quality, publicly funded software that SMEs can reuse, modify, and build upon. This can reduce development costs and accelerate time-to-market.
  • Compliance Checks: When integrating software from public sector sources, verify the open source licence terms. Ensure that your use of the software complies with the licence conditions, especially regarding attribution and distribution of modifications.
  • Participation in Ecosystem: SMEs can contribute to the open source ecosystem by submitting patches, improvements, or new modules to public sector software projects, enhancing their visibility and reputation in the EU market.

Common misconceptions

Misconception 1: CADA forces all public sector software to be open source.

  • Reality: CADA encourages the use of open source and requires that if software is made available for reuse, it must be under an open source licence and connected to the EU OSS Catalogue. It does not mandate that all software must be open sourced. Public bodies can still use proprietary software, but they lose the benefits of the reuse framework.

Misconception 2: The EU OSS Catalogue replaces national or local repositories.

  • Reality: The EU OSS Catalogue is a central hub, but it does not replace local repositories. Public bodies can maintain their own catalogues, provided they are connected to the EU OSS Catalogue as required by Article 42. This federated model allows for local governance while ensuring Union-wide discoverability.

Misconception 3: Any licence can be used as long as it is called "open source."

  • Reality: The licence must meet the definition of an open source licence as per Article 2(25) of CADA, which references the Interoperable Europe Act. This typically means the licence must allow for free use, modification, and distribution. Licences with restrictive clauses that undermine these freedoms may not qualify.

Misconception 4: Only the Commission manages the EU OSS Catalogue.

  • Reality: While the Commission maintains the central catalogue, the OSPO Network (Article 44) facilitates cooperation and best practices among Member States and Union entities. Public bodies play an active role in populating and maintaining the software available through the connected repositories.

Related

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