Summary As proposed, the Cloud and AI Development Act (CADA) establishes a mandatory framework for Union entities and public sector bodies to share software developed with public funds, ensuring it is made available for reuse under an open source licence via the EU Open Source Solutions Catalogue. Article 42 codifies this "share and reuse" obligation, requiring connection to a central repository to prevent siloed development. Crucially, Article 44 creates a network of Open Source Programme Offices (OSPOs) to operationalize this strategy, explicitly tasked with "collaborating on and exchanging open-source projects of common interest" under Article 44(3)(d). For developers and SMEs, this signals a structural shift where public-sector improvements must be "upstreamed" into shared repositories, creating a standardized, interoperable ecosystem that reduces duplication and fosters innovation across the Union.

Detail

The Cloud and AI Development Act (CADA), proposed by the European Commission on 3 June 2026 (COM(2026) 502 final), identifies open source as a critical lever for achieving technological sovereignty and reducing vendor lock-in. The proposal moves beyond mere encouragement to establish a binding regulatory architecture for the sharing of public-sector software. This architecture is built on three interconnected pillars: the obligation to share (Article 42), the centralization of discovery (Article 43), and the operational governance of collaboration (Article 44).

The "Share and Reuse" Obligation (Article 42)

Article 42 of the proposal fundamentally alters the lifecycle of software developed by or for the public sector. It 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 serves two distinct but complementary functions. First, it formalizes the principle that software created with public resources should not remain proprietary or siloed within a single administration. While the decision to release software under an open source licence remains within the discretion of the entity (subject to security and IP constraints), the mechanism for release is strictly regulated. Second, it mandates discoverability. By requiring that any released software be connected to the EU Open Source Solutions Catalogue, hosted on the Interoperable Europe portal, the proposal ensures that these assets adhere to FAIR principles (Findable, Accessible, Interoperable, and Reusable).

For the technical community, this means that bespoke solutions developed for specific government use casesβ€”ranging from tax processing to healthcare data managementβ€”will increasingly be available as standardized, open-source components. This reduces the "reinventing the wheel" phenomenon where multiple Member States or agencies develop identical solutions in isolation.

The OSPO Network and Collaborative Upstreaming (Article 44)

To ensure that the "share and reuse" mandate translates into a vibrant, collaborative ecosystem, Article 44 establishes a network of Open Source Programme Offices (OSPOs). This network brings together relevant structures within Union entities and Member States to coordinate open-source strategies, share best practices, and manage the complexities of licensing and security.

The most significant provision for contributors and developers is found in Article 44(3)(d), which explicitly tasks the OSPO network with: "collaborating on and exchanging open-source projects of common interest to Union entities and public sector bodies."

This clause is the engine of upstreaming. In traditional public procurement, a vendor might deliver a closed-source solution to a single client. Under CADA, the OSPO network facilitates the identification of "projects of common interest"β€”software components that serve multiple public bodies. By institutionalizing collaboration, the regulation encourages entities to contribute fixes, features, and security patches back to a central, shared codebase rather than maintaining parallel, incompatible forks. This ensures that improvements made for one public body (e.g., a new accessibility feature in a citizen portal) are immediately available to all other bodies in the network, maximizing the return on public investment.

The "Open Source First" Principle (Article 41)

Complementing these specific articles, Article 41 sets the strategic tone by requiring Union entities and public sector bodies to "encourage and facilitate their use of open source solutions over proprietary ones." This "open source first" approach mandates that when building their cloud and AI ecosystem, public bodies must consider functionalities, security, total cost of ownership, and other objective criteria, with a strong preference for open standards and components.

This creates a powerful demand-side pull. As public procurement shifts toward open-source solutions, the market for high-quality, maintainable open-source code expands. This, in turn, incentivizes the private sector to contribute to and maintain these projects, knowing that the public sector is a committed and structured consumer.

Practical Mechanisms for Contribution

The proposal envisions a structured environment where contribution is not an ad-hoc activity but a governed process. The EU OSS Catalogue (Article 43) acts as the central hub for discovery, while the OSPO network (Article 44) provides the governance and support.

The OSPOs are tasked with facilitating the exchange of information, experience, and best practices, including discussions on licensing, security, maintenance, and procurement. This structured support lowers the barrier for public sector developers to contribute to external projects. They will have institutional guidance on compliance, security standards, and the technical requirements for connecting to the central catalogue. Furthermore, the network is designed to promote the sharing and reuse of open-source software by public sector bodies, ensuring that the ecosystem remains dynamic and responsive to emerging needs.

What this means for you

For CTOs, software architects, SMEs, and open-source maintainers, the provisions in Article 42 and Article 44 of CADA present significant strategic opportunities and operational shifts.

Opportunities for SMEs and Developers

SMEs specializing in open-source development, cloud infrastructure, or digital public services will find a more predictable and standardized market. As public sector bodies are required to share their software via the EU OSS Catalogue, the volume of high-quality, government-vetted open-source code will increase. SMEs can:

  1. Contribute to Mainline Projects: Engage with the OSPO network to identify "projects of common interest" (per Article 44(3)(d)) and offer expertise in upstreaming improvements. This allows SMEs to shape the direction of critical public-sector software.
  2. Provide Maintenance and Support: Public sector entities may lack the internal resources to maintain complex open-source stacks. SMEs can offer professional services for maintenance, security patching, and integration, leveraging the standardized components made available through the share-and-reuse mandate.
  3. Influence Standards: By participating in the OSPO network or contributing to the catalogued projects, SMEs can help shape the technical standards and security requirements that will govern public-sector AI and cloud deployments, ensuring they align with market realities.

Strategic Considerations for Architects

Architects designing systems for public sector clients or those aiming to sell to the EU market should:

  1. Design for Reuse: Build solutions with modularity and open standards in mind, anticipating that components may need to be shared via the EU OSS Catalogue. Avoid proprietary lock-in mechanisms that would prevent compliance with Article 42.
  2. Adopt Open-Source Licensing Best Practices: Ensure that any software developed for public entities is released under appropriate open-source licences that comply with CADA's requirements and facilitate broad reuse.
  3. Engage with OSPOs: Monitor the establishment of the OSPO network and seek opportunities to collaborate on projects of common interest. This can provide early visibility into upcoming public sector needs and technological priorities.

Operational Impact

The mandate to contribute back and share software requires robust internal processes for code quality, security auditing, and licence compliance. Organizations should invest in tools and processes that automate these checks, ensuring that contributions to the EU OSS Catalogue are seamless and compliant. The "open source first" principle also implies a shift in procurement and development strategies, favoring solutions that are transparent, auditable, and free from vendor lock-in.

Common misconceptions

Misconception 1: CADA forces all public software to be open-sourced. Clarification: Article 42 applies to software to which Union entities or public sector bodies hold intellectual property rights and which they decide to make available for reuse. It does not mandate that all software must be open-sourced (e.g., software with classified security requirements may be exempt). However, it sets a clear path and infrastructure for those that are released, ensuring they are discoverable and reusable.

Misconception 2: The OSPO network is a new bureaucratic layer. Clarification: Article 44 establishes the OSPO network to facilitate cooperation and exchange, not to create bureaucracy. Its tasks, including collaborating on projects of common interest (Article 44(3)(d)), are designed to streamline efforts, reduce duplication, and provide best practices. It acts as a support structure for entities to effectively manage their open-source contributions and collaborations.

Misconception 3: Contributing back is optional and unstructured. Clarification: While the decision to release software may be discretionary, the mechanism for doing so is strictly defined. Article 42 requires connection to the EU OSS Catalogue, and Article 44 mandates a coordinated network for collaboration. This creates a structured, EU-wide ecosystem for open-source contribution, ensuring that contributions are discoverable, interoperable, and aligned with common interests.

Misconception 4: This only affects large government bodies. Clarification: The proposal applies to Union entities and public sector bodies, which include a wide range of organizations from local municipalities to EU agencies. Furthermore, the ripple effects on the private sector, particularly SMEs providing services to these entities, are significant. The standardization and availability of open-source components will impact the broader market, creating opportunities for smaller players to engage with high-value public sector projects.

Related

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