Procurement Is Policy.

Most of the transparency a public body can offer about its software is settled before anyone writes a line of code. It gets settled in the tender, in a few paragraphs about licensing, formats and ownership that are often copied from the last contract. By the time a freedom-of-information request arrives, the answer was already given by whoever signed.

The European Union's own interoperability law shows how this works. Under the Interoperable Europe Act, a public sector body has to share an interoperability solution behind a trans-European digital public service with any other public body that asks, including its documented source code. The same article exempts solutions "for which third parties hold intellectual property rights that restrict the possibility of sharing the solution for reuse." Read that as a procurement officer would. If the vendor kept the rights, the sharing duty never applies. The law sets the obligation, and the contract decides whether it bites.

So here is what we think belongs in the next tender for software built with public money. None of it is new. Every item already has guidance or a model clause behind it, often written by a government.

First, an open licence for what you pay to have built. The UK's Service Standard asks teams to make all new source code open and reusable, to keep ownership of the intellectual property of new code created for the service, and to make it available under an open licence. It allows exceptions, but asks for "a convincing explanation" for each specific subset of code that stays closed. The European Commission applies a similar rule to itself: its 2021 decision on open source licensing makes the EUPL the default licence for Commission software it shares, and it covers software produced "by the Commission or on its behalf." In practice, the tender should state who owns the code on delivery, which licence it will be published under, and where.

Germany has now written this into its standard contracts. The EVB-IT templates are the model terms German public bodies use to buy IT. In March 2026 the digital ministry and the industry association Bitkom announced revised templates in which development and delivery as open source becomes the standard for new software development projects, with an option to require handover of a software bill of materials. A contracting officer there no longer has to draft the open source clause from scratch. It ships in the template.

Second, source code access as a deliverable, not a favour. The Netherlands has framed the default as "open tenzij", open unless. The state secretary's April 2020 letter to parliament on releasing the source code of government software came with an annex titled "Overwegingen bij Open tenzij en Aanpak open source", setting out how agencies should weigh it. A policy like that only works if the agency actually holds the code. The tender should list the repository, the build instructions and the documentation as deliverables, accepted the same way as the working system.

Third, open standards and formats. EU procurement law already pushes in this direction. Directive 2014/24/EU says technical specifications shall not refer to a specific make, trade mark or source unless the subject of the contract justifies it, and where a reference is unavoidable it must be followed by "or equivalent." The UK's open standards principles go further and tell departments to specify open standards in IT requirements "unless there is a clear reason why this is not possible," partly to avoid lock-in to a specific technology or supplier. The Technology Code of Practice puts "Make use of open standards" next to "Be open and use open source" as separate points a project is assessed against. Write the formats into the specification: what the data is stored in, what the API returns, which published standard each interface follows.

Fourth, data export and an exit plan. Ask for the exit on day one, while you still have leverage. For cloud services in the EU, some of this is now law. The Data Act has applied since 12 September 2025, and its switching rules require contracts with providers of data processing services to include a notice period for switching of no more than two months, a default transitional period of 30 calendar days, and "an exhaustive specification of all categories of data and digital assets that can be ported." From 12 January 2027 providers may no longer charge switching fees. That is a floor, not a full exit plan. A tender for a bespoke system should add export in an open, documented format, a test export before acceptance, and the vendor's duty to help migrate at the end.

Fifth, reuse rights for other public bodies. If another municipality wants to run your system, the contract should let you hand it over without a second licence negotiation. This is where the Interoperable Europe Act exemption matters most. The Act also requires an interoperability assessment before new or modified digital systems are put in place, with those rules applying from 12 January 2025, and it tells public bodies to prioritise solutions that "do not carry restrictive licensing terms, such as open source solutions" when they are otherwise equivalent. A reuse clause turns that priority into a right you can exercise.

Sixth, security disclosure. Publishing code makes some officials nervous, and the fix is to require the vendor to handle vulnerabilities in the open. The Secure by Demand guide from the US cybersecurity agency CISA gives buyers questions to put to suppliers: whether they publish a vulnerability disclosure policy "that authorizes testing by members of the public," whether they file timely and correct CVE records, and whether they will supply a software bill of materials in a standard, machine-readable format listing third-party and open source dependencies. It suggests building product security requirements into contract language. A tender can require all three.

One more thing belongs in the file, even though it is about the procurement rather than the software: publish the tender, the award and the signed contract. The Open Contracting Data Standard describes what to release at each stage, from tender notices and specifications through the signed contract, amendments, payments and completion. If the clauses above are worth writing, they are worth letting the public check.

None of this asks a procurement officer to become a software licensing expert. It asks them to stop treating these paragraphs as boilerplate. The template is the policy, and most of the drafting has already been done by governments that had to work it out.