Summary Under the proposed Cloud and AI Development Act (CADA), the OSPO Network's tasks are set out in Article 44(3): facilitating the exchange of information, experience and best practices; promoting the sharing and reuse of open-source software by public sector bodies; contributing, on a voluntary and non-binding basis, to guidance, templates or recommendations; and collaborating on and exchanging open-source projects of common interest. The Commission supports and coordinates the network and chairs meetings at least twice a year. The network has no enforcement power, and its guidance is expressly non-binding. CADA is still a proposal, so this is not yet in force.

Detail

CADA (COM(2026) 502 final) treats open source as a strategic lever for technological autonomy, security and efficiency. The open source chapter (Chapter V of Title IV) sets up a framework for open source in the public sector, including the OSPO Network established under Article 44. The network brings together the relevant structures within Union entities and Member States to support consistent implementation of the chapter. It is a collaborative platform, not a regulatory or enforcement body.

Legal basis and establishment

Article 44(1) requires the Commission to establish the OSPO Network "to facilitate cooperation on the implementation of the obligations under this Chapter." That chapter includes the "open source first" duty in Article 41 (a duty on the Union and Member States to encourage open source use and reuse) and the share-and-reuse publishing rule in Article 42.

Participation is by request. Article 44(2) provides that OSPOs established by public sector bodies at local, regional or national level, and those established by Union entities, "may request from the Commission to join the OSPO Network." This eligibility runs from EU institutions down to municipal-level offices.

The four tasks of the OSPO Network

The mandate is detailed in Article 44(3), which lists four tasks.

1. Exchanging information and best practices

Article 44(3)(a) tasks the network with "facilitating the exchange of information, experience and best practices between Member States and the Commission, in particular by discussing common technical, legal and organisational challenges, including those related to licensing, security, maintenance and procurement of open-source software." Typical topics would include:

  • Licensing — navigating common open-source licences (for example GPL, Apache, MIT) and compliance;
  • Security — managing vulnerabilities and integrating components into secure supply chains;
  • Maintenance — sustaining software, particularly where upstream community support is thin; and
  • Procurement — framing tenders and evaluating open-source offerings fairly within procurement rules.

2. Promoting sharing and reuse

Article 44(3)(b) requires the network to focus on "promoting the sharing and reuse of open-source software by public sector bodies." This supports Article 42, under which a body that chooses to make software it owns available for reuse under an open source licence must publish it via a catalogue connected to the EU Open Source Solutions Catalogue. The network can highlight successful cross-border reuse, identify barriers (such as missing documentation or incompatible licences), and encourage treating public-sector software as a shared asset.

3. Voluntary, non-binding guidance and templates

Article 44(3)(c) tasks the network with "contributing, on a voluntary and non-binding basis, to the development of guidance, templates or recommendations on the sharing and reuse of open-source software." The non-binding character matters: the proposal gives the network no legislative power. Its outputs might include licence-compliance checklists, contribution-agreement templates, or recommendations on sharing and reuse — which authorities may adopt at their discretion.

4. Collaborating on projects of common interest

Article 44(3)(d) covers "collaborating on and exchanging open-source projects of common interest to Union entities and public sector bodies." This goes beyond discussion towards joint effort — for example on shared infrastructure components or interoperability building blocks — letting bodies pool resources on work that would be hard to fund alone.

Governance and coordination

While Article 44(3) sets the tasks, Article 44(4) makes the Commission responsible for supporting and coordinating the network, and Article 44(5) requires the Commission to convene and chair a meeting of members "at least twice a year," with meetings that "may be organised online." The Commission's role is facilitative — coordinating activity and keeping it aligned with the open source chapter's aims — rather than dictating an agenda.

What this means for you

For public-sector IT leaders, procurement officers and policy makers, the OSPO Network — if adopted — would be a practical resource.

If you are a public-sector IT leader: establishing or strengthening an OSPO would make you eligible to request membership (Article 44(2)) and give access to EU-wide best practices and peer support. You could draw on voluntary templates and guidance, and propose projects of common interest.

If you are a procurement officer: the network's exchange of best practices could help you frame tenders and evaluate open-source offerings, and identify reusable solutions to reduce custom development.

If you are a policy maker: the network offers a channel to monitor and support open-source implementation across the EU and to inform national or regional policy. Its outputs are non-binding, so engagement is a matter of choice rather than obligation.

These are proposed measures; CADA must be adopted and apply before they take effect.

Common misconceptions

Misconception 1: The OSPO Network can enforce open-source compliance. No. Article 44(3)(c) makes its guidance "voluntary and non-binding," and the proposal gives it no enforcement role. Enforcement of CADA's obligations lies with national competent authorities and the Commission, not the network.

Misconception 2: Joining the network — or having an OSPO — is mandatory. No. Article 44(2) provides that eligible OSPOs may request to join. The proposal does not require any public body to have an OSPO or to join.

Misconception 3: The network only deals with technical issues. Article 44(3)(a) expressly covers "technical, legal and organisational challenges," including licensing, procurement and security governance — it is multidisciplinary.

Misconception 4: The network replaces national open-source strategies. It complements them. Article 44 sets up a European coordination layer; national strategies continue to address local legal and technical contexts.

Related

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