Summary The legal basis for the open source provisions in the proposed Cloud and AI Development Act (CADA) is the cumulative application of Article 114 and Article 173(3) of the Treaty on the Functioning of the European Union (TFEU). As proposed in COM(2026) 502 final, Article 114 addresses internal market fragmentation by harmonising rules for software reuse and preventing siloed repositories, while Article 173(3) empowers measures to boost industrial competitiveness and technological sovereignty. These provisions, located in Chapter V of Title IV (Autonomy), would require Union entities and public sector bodies to encourage open standards, mandate the connection of reusable software to the EU Open Source Solutions Catalogue, and establish a network of Open Source Programme Offices (OSPOs) to coordinate implementation.

Detail

To understand the legal architecture of CADA's open source chapter, one must examine the dual treaty foundations cited in the proposal's preamble and explanatory memorandum. Unlike purely research-focused initiatives, CADA is structured as a Regulation designed to simultaneously correct market failures and drive strategic industrial policy.

The TFEU Foundations: Internal Market and Competitiveness

The proposal explicitly relies on a cumulative legal basis under Article 114 and Article 173(3) TFEU. This dual foundation is critical for understanding the scope and intent of the open source rules.

Article 114 TFEU empowers the EU to adopt measures for improving the functioning of the internal market through the harmonisation of national provisions. The explanatory memorandum identifies a specific market failure: the fragmentation of software assets across Member States. Without a unified framework, software developed by public bodies remains trapped in disparate, non-interoperable repositories. This "silo effect" hampers discoverability, prevents reuse, and creates regulatory disparities that undermine the digital single market. By mandating that public sector software be made available via a centralised hub, CADA would remove these barriers, ensuring uniform conditions for the internal market and facilitating the free flow of digital solutions.

Article 173(3) TFEU provides the legal basis for measures aimed at enhancing the EU's industrial competitiveness and innovation capacity. The proposal frames the shortage of computing capacity and overreliance on third-country providers as a constraint on European industry. The open source chapter is therefore not merely an administrative convenience but a strategic industrial policy tool. By fostering open standards and open-source components, the EU aims to reduce dependency on single vendors, limit vendor lock-in, and strengthen the competitiveness of the European cloud and AI ecosystem. The explanatory memorandum states that promoting open source is essential to "support innovation, ensure better value for public expenditure, and strengthen the Union's digital autonomy."

Placement within Title IV: Autonomy

A distinctive feature of CADA is the placement of its open source provisions. They are not located in Title II (Research, Development and Deployment) or Title III (Data Centre Capacities), but are situated in Title IV: Autonomy. Specifically, they form Chapter V of this title.

This placement is deliberate and legally significant. Title IV is dedicated to reducing dependencies on critical technologies and ensuring the availability of a sovereign cloud and AI offer to safeguard the Union's public order. By embedding open source rules here, the legislation signals that open source is not just a technical preference for developers, but a strategic imperative for resilience and independence.

The explanatory memorandum highlights that open source plays a critical role in ensuring transparency, security, and efficiency. Access to source code enables auditability, fosters collaboration, and reduces the risk of vendor lock-in. In the context of the "Autonomy" title, these benefits directly contribute to the Union's ability to act independently of third-country control. The open source chapter thus serves as a demand-side measure to drive the adoption of sovereign, auditable, and resilient technologies.

The Specific Provisions: Articles 41–44

The legal obligations are detailed in four key articles within Chapter V:

  • Article 41 (Promoting open source solutions and open source first): This article establishes the overarching principle. It obliges 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. Crucially, the article specifies that this encouragement must take into account functionalities, security, total cost, and other relevant, duly justified objective criteria. It creates a strong directive for public sector behaviour without imposing an absolute, unconditional mandate to open-source every line of code.

  • Article 42 (Share and reuse of software): This article operationalises the reuse principle. When a Union entity or public sector body holds intellectual property rights to software and decides to make it available for reuse under an open source licence, it must do so using a catalogue or repository that is connected to the EU Open Source Solutions Catalogue. This creates a binding technical and legal linkage between national/public repositories and the central EU hub, ensuring findability and interoperability across the Union.

  • Article 43 (EU Open Source Solutions Catalogue): The Commission is tasked with providing and maintaining this centralised catalogue. It will be hosted on the Interoperable Europe portal, ensuring accessibility and alignment with broader digital public service interoperability goals. The Commission will decide on requests from entities to connect their existing repositories to this catalogue based on objective and relevant criteria, acting as the gatekeeper for the central hub.

  • Article 44 (Network of Open Source Programme Offices): To ensure consistent implementation, the Commission will establish a network of OSPOs. This network will facilitate cooperation, exchange best practices, and contribute to the development of guidance on sharing and reusing open-source software. While the tasks of the OSPO network are largely supportive and coordinative, their establishment is a binding obligation for the Commission, reinforcing the structural support for the open source strategy.

Delegated and Implementing Acts

The proposal grants the Commission powers to adopt delegated acts (under Article 45) and implementing acts (under Article 46) to ensure the framework remains adaptable. While the open source chapter does not list specific delegated powers in the same granular detail as the sovereignty framework (Title IV, Chapter I), the general power to amend annexes and supplement the regulation allows for future technical adjustments to the catalogue's operation or the criteria for OSPO network participation. This ensures the framework can evolve alongside technological developments without requiring a full legislative amendment.

What this means for you

For in-house counsel, compliance officers, and IT strategists at Union entities or public sector bodies, the open source chapter introduces a structured compliance pathway for software asset management.

  1. Audit Your IP Portfolio: Identify all software for which your entity holds intellectual property rights. Assess which of these could be released under an open source licence to generate public value and reduce duplication costs.
  2. Repository Integration: If you decide to release software, you cannot simply host it on an internal or disconnected public repository. You must ensure your repository is connected to the EU OSS Catalogue, or release the software directly through a connected channel. Monitor the Commission's criteria for connecting repositories, as defined in Article 43.
  3. Procurement and Development Strategy: Align your cloud and AI ecosystem development with the "open source first" principle outlined in Article 41. When building new systems, document how you have considered open standards and open-source components, weighing factors like security, total cost, and functionality. This documentation may be relevant for demonstrating compliance with the broader objectives of national cloud and AI strategies.
  4. OSPO Engagement: Prepare to engage with the Network of Open Source Programme Offices (Article 44). If your entity has an existing OSPO, it should request to join the network. This will be a primary channel for receiving guidance, templates, and best practices on licensing, security, and maintenance.

Common misconceptions

"CADA mandates all public software must be open source." No. Article 41 encourages and facilitates reuse but does not impose an absolute obligation to open-source every piece of software developed. It requires entities to take measures to encourage use and facilitate reuse, taking into account objective criteria such as security and cost. The decision to release software under an open source licence remains voluntary for the entity, but if chosen, the reuse conditions in Article 42 apply.

"Open source compliance is separate from cybersecurity obligations." Incorrect. The proposal explicitly links open source to security and sovereignty. Article 41 notes that access to source code enables auditability and reduces vendor lock-in risks. Compliance with open source provisions is intertwined with the broader cybersecurity and sovereignty frameworks in Title IV. Ignoring open source governance may expose entities to risks identified in the sovereignty risk assessments.

"The EU OSS Catalogue is just a search engine." The catalogue is a centralised technical and legal hub. Connecting to it (Article 42 and Article 43) is a binding requirement for reusable software. It is not merely a discovery tool but a compliance mechanism to ensure that public sector software assets are findable, accessible, interoperable, and reusable (FAIR principles) across the Union.

"Private companies are directly bound by Articles 41–44." These articles primarily address Union entities and public sector bodies. However, private companies supplying software or services to the public sector may be indirectly affected. Public procurement criteria (Article 32) and the general push for open standards may influence contract requirements. Furthermore, the reduced vendor lock-in and increased auditability may change the competitive landscape for proprietary software vendors.

Related

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