Open Source in Public Procurement

What the Expert Opinion Changes

A report by the German Bundestag’s Science Service clears the final hurdle under public procurement law for open source in tenders. What this means for contracting authorities and IAM projects, and what a legally compliant requirement looks like in practice.

Inhaltsverzeichnis

Finally, government agencies can require open source instead of just hoping for it

Until recently, contracting agencies found themselves in an awkward position. Anyone drafting a request for proposals had to keep it technology-neutral and, in principle, accept any bid that met the required performance criteria. A mandatory open-source requirement was considered legally risky, so, to be on the safe side, the language was kept neutral. The result of this caution was paradoxical. A government agency that, for good reasons, wanted to pursue an open-source approach ended up evaluating bids that included proprietary products—and often found itself exactly where it didn’t want to be. The desire for digital sovereignty and the rules of procurement pulled in different directions.

The Scientific Service of the Bundestag has now resolved this dilemma.

On July 16, 2026, an expert opinion was released that clarifies the key question: Are public contracting authorities permitted to mandate open-source software in a request for proposals? The response from the Scientific Services is clear: They are permitted to do so, and in many cases, there are even more arguments in favor of it than against it.

Changes in Exemption Law

The gist of it is simple. An open-source requirement in the request for proposals is permissible as long as it is objectively justified, proportionate, and transparently substantiated. This is not a blank check. A government agency that requires open source must be able to explain why this requirement serves the purpose at hand. Where suitable open-source offerings are lacking, the expert opinion further recommends adding the phrase “or equivalent” to ensure that competition remains open.

The key difference from the old practice lies elsewhere. In the past, the contracting authority had to keep the door open to every technological proposal and hope that the right one would ultimately win. In the future, it will be allowed to make the desired characteristic a requirement from the outset, rather than leaving it to the vagaries of the proposals submitted. The expert opinion even goes a step further and considers such a requirement to be necessary under certain circumstances—not merely permissible.

Four Reasons Why an Open-Source Requirement Is Justified in RFP’s

The paper cites several justifications for an open-source requirement, and they align remarkably well with what we know from IAM projects.

The first is IT security. Open-source code can be reviewed, audited, and further developed independently, whereas a closed black box prevents exactly that. Especially in identity management, where a single piece of software controls the access rights for thousands of accounts, traceability is not just an academic luxury.

Then there’s interoperability. Open standards and documented interfaces make it easier to integrate with existing systems, which—in complex government environments with a dozen source systems—often determines whether a project succeeds or becomes a never-ending task.

The third point— dependence on a specific manufacturer—is the most serious. Recent case law from the European Court of Justice requires public contracting authorities to think strategically as early as the initial award stage about whether a procurement decision will create future dependencies that restrict competition. A vendor lock-in that the contracting authority has brought upon itself is generally not sufficient justification for a direct award without competitive bidding. The actual obligation, therefore, is to avoid such dependencies from the outset. This is precisely what open source achieves, because it prevents a dependency on a single vendor from arising in the first place.

That leaves long-term cost efficiency, of which the license fee is only the visible part. What’s usually more expensive is the item that doesn’t appear on any invoice: the loss of bargaining power vis-à-vis a provider who knows full well that you can’t switch.

The real risk of a proprietary IAM solution isn’t today’s license price. It’s the bill that comes when the contract needs to be renewed and there are no longer any alternatives.

“Open source is a licensing model, not a technology.”

Peter Ganten, CEO of the Open Source Business Alliance, sums up the practical impact of the report when he says it frees government employees from a sense of uncertainty that has long paralyzed them. His second point carries more weight than it might initially seem. Open source is a licensing model, not a specific technology, and it is this that gives rise to transparency and resilience.

This distinction clears up a common misconception. Open-source software is not automatically more modern or more securely programmed than commercial software. The difference lies in the rights an organization retains over its own software. It can view the code, modify it, have it maintained by another service provider, and retains control even if the original provider raises prices or exits the market. For a government agency that operates systems for ten or fifteen years, this is a compelling argument.

Why this is particularly relevant to us in the IAM context

Identity & Access Management is a prime example of the interdependencies addressed in the report. An IAM system occupies one of the most sensitive positions in the entire infrastructure. It knows who has which permissions, provisions accounts in line with business processes, reconciles access rights, and revokes access as soon as someone leaves the organization. Anyone who ties this central hub to a proprietary product creates a dependency precisely where a future switch would be particularly costly.

We regularly see with higher education and government clients that the real hurdle is rarely the license. It’s the connectors and the data logic behind them. If the rules governing how identities are correlated and permissions are granted are locked into a proprietary format, you only have limited control over your own process landscape. With an open-source platform like midPoint, this logic remains transparent and transferable—which makes all the difference when it’s time to switch service providers or migrate a system.

Being honest is part of it. Open source doesn’t solve every problem, and the most common reason for this has little to do with the software itself. It’s called a shortage of personnel. Many organizations have to focus on the expertise they actually have in-house, and independently operating an open-source IAM platform is rarely part of that. That’s exactly why we’ve deliberately focused on managed services and SaaS. This way, a university or government agency gets the benefits of an open, vendor-neutral solution without having to build its own operations team. The report doesn’t force anyone to use open source. It simply removes the pressure of knowingly ending up with a solution you didn’t even want in the first place.

From a Neutral Request for Proposals to Clear Requirements

For contracting authorities, this report significantly shifts the landscape. Until now, those who demanded open source were under pressure to justify their position. In the future, those who deliberately tie a key component to a single vendor—even though open-source alternatives are available—will be the ones who have to explain themselves. A clearly formulated requirement specifies the verifiable characteristics that are needed—such as disclosed source code, documented interfaces, and the right to further development by third parties—rather than a specific product. This ensures the desired outcome without closing the door to genuine competition among open-source providers.

Digital sovereignty was long just a buzzword for political rhetoric. Now there is a legal basis for translating it into concrete tender documents. The framework for this was essentially already in place; the expert opinion makes it robust.

Don’t want to wait any longer and end up with yet another stopgap solution for your next RFP? Then get in touch with us now using the contact form. We’ll show you exactly what a legally compliant open-source requirement looks like in your IAM project—from the scope of work to operations.