EU Open Source Strategy Backs Public Code With Procurement and Maintenance Measures

The EU Open Source Strategy places open source at the centre of the European Commission’s technology sovereignty agenda. Published on 3 June 2026 alongside the Commission’s Communication on European Tech Sovereignty, the strategy proposes public-procurement reform, support for maintainers and foundations, security and dependency measures, skills programmes, and long-term funding mechanisms intended to help open technologies become durable parts of European public infrastructure.

For Drupal and other community-maintained software, the policy shift is broader than a preference for open licences. The Commission wants public administrations to become stronger users and contributors, remove procurement barriers that favour proprietary suppliers, and support the governance and maintenance needed to keep shared software usable over time. The strategy is not binding law, and its practical effect will depend on later legislation, budgets, procurement rules, funding programmes, and the institutions created to implement it.

Public procurement is the strategy’s clearest route to market change. The Commission says proprietary-oriented specifications, bundled single-vendor stacks, and eligibility thresholds have disadvantaged open-source suppliers, particularly small and medium-sized enterprises. Its proposed open-source-first approach would direct public administrations towards open standards, interoperability, lifecycle costs, maintenance arrangements, and the ability to move between suppliers.

The Commission’s communication cites estimated annual European Union IT spending of €264 billion and says much of it goes to non-European proprietary products and services. It presents that spending pattern as a source of dependency, reduced negotiating leverage, and limited control over critical digital infrastructure. Its four objectives cover open source for technological sovereignty, a stronger European open-source ecosystem, open source in public administration, and standards and international outreach.

The Commission estimates that the public and private sectors would need to mobilise about €2 billion over seven years for measures under the strategy. That figure is an investment estimate rather than a dedicated fund already available to maintainers, foundations, or suppliers. Proposed actions include support for start-ups, procurement guidance, skills programmes, dependency mapping, stewardship tools, and an Open Source Maintenance Instrument.

Legal analysis from Bird & Bird considers how parts of this non-binding strategy could later influence procurement and regulatory expectations. In an analysis published on 22 July 2026, Pawel Lipski, a partner in the firm’s commercial team, connected the strategy to the proposed Cloud and AI Development Act, the existing Cyber Resilience Act, and future procurement guidance. That interpretation provides legal context, while the Commission’s communication and legislative texts remain the primary evidence for the policy measures.

The proposed Cloud and AI Development Act, known as CADA, could give part of the package’s procurement direction legal force in cloud services. The proposal creates a Union-wide sovereignty framework with four assurance levels and a public-sector adoption mechanism, while also promoting open-source solutions as a resilience measure. CADA remains a legislative proposal and may be amended by the European Parliament and the Council of the European Union.

The Open Source Initiative welcomed the procurement direction in its response to the package, but identified reform of EU public-procurement law as the next critical step. The Free Software Foundation Europe similarly called for binding requirements, secure long-term funding, and civil-society participation. Both responses support the strategy’s direction while warning that a Commission communication cannot deliver implementation by itself.

The strategy’s stewardship and security proposals also build on distinctions already established in the Cyber Resilience Act, known as the CRA. The Act applies to free and open-source software when it is made available on the market in the course of a commercial activity. It also created the legal category of an open-source software steward for a legal person that provides sustained support for software intended for commercial activities and plays a main role in ensuring its viability.

Open-source software stewards must maintain a cybersecurity policy, support secure development and vulnerability handling, cooperate with market-surveillance authorities, and report certain actively exploited vulnerabilities and severe incidents. The CRA does not apply to developers who contribute source code to software outside their responsibility, and stewards are not subject to administrative fines for infringements. These distinctions prevent the CRA from operating as a uniform compliance regime for all open-source participation.

You May Like

Article

Sovereignty Takes Different Forms Across Drupal Hosting

Article

Sovereignty Takes Different Forms Across Drupal Hosting

The strategy builds on that framework by proposing a stewardship toolkit, support for EU-based steward organisations, and a feasibility study for a cross-border framework for foundations. It also envisages a European Digital Public Infrastructure Steward Organisation and long-term arrangements for selected EU reference implementations. These proposals recognise that sustainable public software depends on governance, release management, security response, contributor coordination, and continuity as well as code availability.

The proposed Open Source Maintenance Instrument would support the maintenance and security of essential components alongside dependency analysis, mirroring capabilities, and voluntary assessment or attestation programmes. The communication does not yet establish detailed eligibility rules, award procedures, or guaranteed allocations for individual projects. Its eventual funding design will determine whether the instrument supports routine maintenance and ecosystem development as well as emergency security work.

The Commission’s cookie policy identifies its corporate content-management platform as based on Drupal open-source software. That detail does not establish how every Commission website is procured or maintained, but it makes Drupal a relevant example of software used within European public infrastructure. It brings questions about supplier choice, component transparency, shared maintenance, and lifecycle support into a familiar Drupal context.

A direct public-sector example is LocalGov Drupal. Its project model brings councils and suppliers together to share code, research, and implementation knowledge. The Open Digital Cooperative provides governance and works to sustain the software and community through subscriptions and shared decision-making.

A Tipperary County Council case study says the Irish implementation created two modules for use by other councils. Returning publicly useful work to a maintained shared project reflects the strategy’s goals of reuse, supplier participation, and reduced duplication. It also shows why documentation, review, funding, and governance matter when another public body or supplier needs to adopt the work.

The end of Drupal 7 community support provides a different kind of example. Drupal 7 reached end of life on 5 January 2025, 14 years after its release, and Drupal.org stopped providing community releases, fixes, and security advisories for the version. Its source code remained available, preserving the legal and technical possibility of continued use or independent support, but safe operation still required engineering capacity, maintenance arrangements, and funding.

An open licence can reduce legal barriers to inspecting software, commissioning changes, sharing improvements, and moving work between suppliers. Those freedoms are strongest when public buyers also require documentation, testing, transition plans, security ownership, and contracts that make maintenance responsibilities clear. Undocumented custom modules, proprietary hosting arrangements, closed integrations, or knowledge concentrated in one delivery team can otherwise limit the practical choices that open source makes possible.

Procurement reform alone will not create sustainable public code. Public administrations need staff who can evaluate architecture, licensing, security practices, supplier-transition plans, and the condition of upstream dependencies. Legal, finance, and contract teams also need to treat maintenance as continuing infrastructure work rather than an optional contribution after launch.

The policy direction suggests that suppliers may increasingly need to document component inventories, vulnerability response, data portability, support periods, and handover arrangements. Those expectations can improve accountability, but they should remain proportionate so that smaller open-source suppliers are not excluded by assurance costs designed around large proprietary vendors. Open-source transparency should support informed procurement rather than become a reason to penalise suppliers for disclosing dependencies that closed products also contain.

The strategy’s practical value will be measured by whether public bodies can change suppliers, publicly funded improvements return to maintained projects, stewards receive dependable support, smaller open-source suppliers can compete, and essential systems remain secure throughout their operating life. For the Drupal community, access to source code provides the foundation for those outcomes, while procurement, governance, maintenance, and institutional capacity help keep that freedom usable over time.