Public Procurement of Open Source Software

Yes. EU public procurement rules do not prohibit or discourage open source software – in fact, they require a “level playing field” for all solutions. Under EU Directive 2014/24/EU and in line with the principles of equal treatment, transparency, and proportionality, contracting authorities must treat vendors equally and avoid unjustified discrimination. This means open source and proprietary software must be evaluated on the same basis, focusing on meeting the technical and business requirements. 

The European Commission’s own Open Source Strategy emphasises equal treatment: open source solutions should be assessed fairly, based on total cost of ownership. Many Member States even encourage open source in the public sector – for example, Italy’s Digital Administration Code requires considering open source before proprietary options. In summary, it is fully legal and supported by EU policy to procure open source software, as long as procurement procedures remain neutral and focused on best value. 

To include open source solutions lawfully, contracting authorities should frame requirements in functional and performance terms rather than by brand or licence type. Naming a specific open source solution, such as Drupal for municipal websites or Moodle for e-learning, is permissible where justified by legitimate and objective needs, where all suppliers have equal access to the software, and where this justification is transparently documented in the tender. 

Tenders can also require open standards, interoperability, and rights to access, modify, and reuse source code, criteria that promote transparency and long-term sustainability while avoiding vendor lock-in. Authorities are encouraged to embed open source principles in procurement strategies and build internal guidelines or templates to ensure consistency. 

Open source software licences grant broad rights to use, modify, and share software, but they also impose obligations that procurement officers should understand. Key points include:

• Licence compliance: each open source licence (e.g., MIT, GPL, EUPL) has specific conditions. Some “copyleft” licenses require that modified versions be released under the same terms. This does not restrict public sector use but requires planning for compliance. Tools such as the Interoperable Europe Portal's Licensing Assistant can help verify licence terms and compatibility.
• Intellectual property and contract rights: contracts should ensure that the administration obtains the source code and the right to use, modify, and reuse it within the public sector freely. Clauses should prevent suppliers from adding restrictions beyond those in the open source licence.
• Contributions and maintenance: where appropriate, contracts can require suppliers to contribute improvements back to the original open source project, helping sustain the software and reduce maintenance burdens.
• Warranty and support: open source software is usually provided “as is,” so support and service levels should be clearly defined in the contract. Support can be procured competitively since multiple vendors can work with the same code.

By addressing these points early, public administrations can confidently adopt open source solutions while staying compliant and maintaining long-term control.

Public administrations can procure open source software in several ways:

1. Reuse an existing open source solution: acquire services to implement or adapt an existing open source project.
2. Commission new development open source software: fund custom software under an open licence, ensuring openness from the outset.
3. Download and use existing open source software directly, procuring support services separately.

Each model is valid under EU procurement rules; the key is to match the model to the administration’s capacity, needs, and long-term maintenance plan.

Procuring the software is only the first step: public administrations also need confidence that open source solutions will remain secure and sustainable over time. This can be achieved through several good practices:

• Assess community health: before adoption, evaluate the vitality of the open source project, e.g., update frequency, active maintainers, contributor base, and include this as a quality evaluation criterion in tenders. Choosing well-established or growing open source communities helps ensure continued security and support.
• Build internal capacity: investing in staff training or establishing an Open Source Programme Office (OSPO) helps coordinate open source use, manage compliance, and strengthen in-house expertise.
• Collaborate with peers: joining national or EU-level initiatives (e.g. Denmark’s OS2 network or France’s BlueHats) enables administrations to share costs, pool expertise, and collectively maintain solutions.