A legislative proposal winding through European policy circles aims to mandate that publicly funded software be made publicly available as open source. The idea sounds simple. Almost obvious. But the details — and the fierce disagreements they’ve generated — reveal just how fraught the intersection of government procurement, intellectual property, and open-source ideology has become.
The concept is often distilled into a slogan: “Public Money, Public Code.” If taxpayers fund the development of software, the argument goes, the resulting code should belong to the public. It shouldn’t be locked behind proprietary licenses held by contractors who then charge governments again and again for access, updates, and modifications. The Free Software Foundation Europe has championed this principle for years, and it has gained traction in multiple EU member states. Now, as The Register reported, a formal bill is taking shape — and the debate around it has intensified considerably.
The legislation, broadly modeled on proposals that have surfaced in Germany, France, and at the EU level, would require government agencies to release software developed with public funds under open-source licenses, with narrow exceptions for national security and critical infrastructure. Proponents see it as a long-overdue correction to decades of vendor lock-in that has cost European governments billions. Critics see it as a well-meaning but dangerously naive policy that could undermine software quality, discourage private-sector participation in government contracts, and create security vulnerabilities at scale.
Both sides have a point. And neither is fully reckoning with the other’s strongest arguments.
Start with the case for the bill. European governments spend enormous sums on custom software. Much of it is built by large systems integrators — companies like Capgemini, Atos, and Accenture — under contracts that typically leave the intellectual property with the vendor. The government gets a license to use the software, but not to modify it, share it, or switch providers without starting over. This dynamic creates what procurement specialists call “sticky contracts”: arrangements where the switching costs are so high that agencies renew with incumbents almost by default, regardless of performance.
The result is a kind of quiet extraction. Governments pay to build software, then pay again to maintain it, then pay again when they need changes. The vendor controls the code. The public, which funded the work, owns nothing. Open-source mandates would break this cycle by ensuring that code produced under government contracts is freely available. Any qualified firm could pick up maintenance. Agencies could share solutions across jurisdictions. A tool built for Hamburg’s transit authority could be adapted by Lyon’s.
That’s the theory.
In practice, as The Register’s analysis noted, the bill’s critics raise several uncomfortable questions. First: who maintains open-source government software once it’s released? Open-source projects thrive when they attract active communities of developers who contribute improvements, fix bugs, and patch security holes. But government software is often highly specialized — tax processing systems, benefits administration platforms, regulatory compliance tools. These aren’t the kind of projects that attract passionate volunteers on GitHub. They’re complex, domain-specific, and frankly boring to most developers.
Without a healthy contributor community, open-sourcing government code could mean publishing software that nobody outside the original contractor actually understands or maintains. The code becomes technically public but practically orphaned. And orphaned code is a security liability, not an asset.
Second: the bill could reshape the economics of government contracting in ways that hurt smaller firms. Large integrators can absorb the margin compression that comes from losing proprietary control over code they develop. They’ll make it up on volume, on consulting, on the next contract. Smaller software firms and startups, which often bid on government work partly because they can retain and reuse IP they develop, may find the economics no longer work. If everything you build for the government must be given away, the incentive to invest your best engineers and your most innovative approaches in public-sector work diminishes.
This isn’t hypothetical. In the United States, the federal government’s experiments with open-source mandates — particularly under the Obama-era Federal Source Code Policy — produced mixed results. Some agencies released high-quality open-source tools that gained traction. The U.S. Digital Service and 18F, the technology consultancies embedded within government, produced genuinely useful open-source projects. But many agencies simply complied on paper, publishing code repositories that were incomplete, undocumented, and never updated. The mandate existed. The culture to support it didn’t.
European advocates argue their approach is different. More comprehensive. Better funded. The bill under discussion includes provisions for dedicated maintenance budgets, standardized documentation requirements, and centralized repositories managed at the EU level. These are meaningful additions. But they also add bureaucratic overhead to an already bureaucratic process, and they assume a level of technical competence within government agencies that, frankly, many do not yet possess.
There’s a deeper tension here that neither side fully acknowledges. Open-source software works best when it emerges organically — when developers build something useful, share it, and others improve it because they need it too. Linux, PostgreSQL, Kubernetes: these projects succeeded because they solved real problems for large numbers of technically sophisticated users who had both the ability and the motivation to contribute. Government mandates can’t manufacture that dynamic. They can publish code. They can’t conjure communities.
And yet. The status quo is genuinely bad. European governments are spending tens of billions of euros annually on software they don’t own, can’t modify, and often can’t even inspect for security vulnerabilities. The vendor lock-in problem is real, expensive, and getting worse as governments digitize more services. Doing nothing isn’t a viable option either.
The most honest assessment of the bill might be that it’s a necessary but insufficient step. Mandating open-source release addresses the ownership problem but not the capacity problem. Governments need not just open code but the institutional ability to manage, evaluate, and contribute to open-source projects. That means hiring developers. It means building internal technical leadership. It means treating software not as a procurement category but as a core governmental competency.
Some European governments are already moving in this direction. France’s DINUM — the interministerial digital directorate — has built internal teams capable of developing and maintaining open-source tools. Estonia’s digital infrastructure, widely regarded as the most advanced in Europe, relies heavily on open-source components maintained by government developers. Germany’s ZenDiS initiative is attempting to build sovereign digital workplaces using open-source alternatives to Microsoft products. These efforts are real, but they’re also expensive and politically fragile, dependent on sustained funding and leadership commitment that can evaporate with a change in government.
The bill’s treatment of security has also drawn scrutiny. Publishing source code makes it available not just to friendly developers but to adversaries looking for vulnerabilities. The open-source community’s standard response — that transparency improves security because more eyes find more bugs — is true in aggregate but misleading in specific cases. A widely used open-source library like OpenSSL benefits from intense scrutiny. A niche government application for processing agricultural subsidies does not. Publishing its source code doesn’t meaningfully increase the number of people reviewing it for security flaws, but it does give attackers a roadmap.
The bill includes security exemptions, but their scope is contested. National security applications are excluded. Critical infrastructure gets special treatment. But what counts as critical infrastructure? Election systems, obviously. Tax administration? Probably. The portal where citizens renew their driver’s licenses? It depends on who you ask. Drawing these lines will be an enormous political and technical challenge, and getting them wrong in either direction carries real costs.
There’s also the question of existing contracts. Governments have decades’ worth of agreements with proprietary software vendors. Many of these contracts contain IP provisions that would conflict with an open-source mandate. Unwinding them — or waiting for them to expire — could take years. In the meantime, agencies would face a patchwork of open and proprietary systems with different licensing terms, different maintenance models, and different security postures. Managing that complexity is itself a significant technical and administrative burden.
Industry reaction has been predictably split along interest lines. The large proprietary vendors — Microsoft, Oracle, SAP — have expressed cautious concern, emphasizing the importance of “choice” and “flexibility” in procurement. Translation: they don’t want to lose their lock-in advantages. Open-source advocates and smaller competitors have generally supported the bill, seeing it as a way to level a playing field that has long favored incumbents with deep lobbying operations and established relationships.
But some voices within the open-source community itself have raised concerns. Bruce Perens, one of the original authors of the Open Source Definition, has argued in recent commentary that government mandates can distort open-source development by flooding repositories with low-quality, compliance-driven code dumps. The risk is that “open source” becomes a checkbox exercise rather than a genuine development methodology. Code gets published. Nobody reads it. Nobody improves it. It sits in a repository, technically open but functionally dead.
So where does this leave the bill? Probably moving forward, in some form. The political momentum behind digital sovereignty in Europe is strong, driven by concerns about dependence on American and Chinese technology platforms. Open-source mandates fit neatly into that broader agenda. They signal independence. They promise cost savings. They align with European values around transparency and public goods. Whether they deliver on those promises depends entirely on implementation — on whether governments are willing to invest not just in publishing code but in building the institutions and hiring the people needed to make that code useful.
The legislation is expected to face further revision as it moves through committee stages. Amendments addressing maintenance funding, security review processes, and transition timelines for existing contracts are all under discussion. The final version may look quite different from the current draft. But the core principle — that software built with public money should be publicly available — seems likely to survive in some form. It’s too politically appealing, and too substantively reasonable, to abandon entirely.
The harder question, the one that the bill alone cannot answer, is whether European governments are prepared to become genuine participants in open-source development rather than merely mandating it from above. The difference between those two things is the difference between policy and practice. Between legislation and competence. Between publishing code and actually making it work.
That gap is where the real work lies. And no bill, however well-drafted, can close it on its own.
WebProNews is an iEntry Publication