European public administrations are waking up to a stark, uncomfortable fact: much of the EU’s day-to-day work — messaging, documents, calendars, collaboration and even parts of the software supply chain — runs on infrastructure and platforms controlled by a handful of U.S. companies. At a recent Open Source Policy Summit in Brussels, the message landed bluntly: reliance on a handful of U.S.-headquartered platforms creates economic leakage, operational risk and a legal exposure that can be exploited or triggered by geopolitical tensions. One participant put it plainly: when most government offices, ministries and intergovernmental workflows depend on products and services headquartered under U.S. jurisdiction, the theoretical ability of a foreign power (or of U.S. law enforcement and regulatory action) to restrict or cut access is not merely rhetorical — it is a material risk that must be managed.
Background: why the alarm bells are ringing
The modern public-sector workplace is built around a small set of productivity and cloud platforms: email and calendaring, document editing, file storage and team collaboration. Over the past decade, these capabilities have migrated from locally-managed servers and desktop apps to centrally-hosted, subscription-based services and globally distributed code hosting and package ecosystems. That shift produced huge efficiency and innovation gains — but it also concentrated control.
Two facts make this concentration consequential. First, a large share of public-sector productivity tooling is provided by U.S.-based firms whose corporate headquarters, legal obligations, and executive decisions are governed by U.S. law. Second, open-source software and development workflows — which many national governments depend on indirectly through shared code, libraries and package managers — are themselves concentrated on services owned by these same firms. The result is a stack where critical operational dependencies and software supply chains sit squarely under foreign jurisdiction.
Those are not hypothetical vulnerabilities. Cloud outages, service suspensions and the legal frameworks that compel data disclosure are real levers that can interrupt public administration or complicate the EU’s digital sovereignty. The debate in Brussels is no longer rhetorical: it moves from “would it be nice to reduce dependence?” to “how do we do it, without breaking government operations?”
The practical pivot: Schleswig‑Holstein as a test case
A large-scale migration, with teeth
The German state of Schleswig‑Holstein has become the most visible, concrete example of transition from Microsoft-controlled tooling to an open‑source-first stack. Over the course of a multi-month program, the state’s administration migrated tens of thousands of mailboxes away from Microsoft Exchange and Outlook to Open‑Xchange as the back end and Mozilla Thunderbird as the client, while rolling out LibreOffice, Nextcloud for collaboration and Matrix-based Element for chat in other parts of the environment.
This is not symbolic: it involved migrating more than 40,000 mailboxes and moving over 100 million messages and calendar items. The project illustrates four essential points for any government thinking of following suit:
- Scale and complexity are real but manageable: moving tens of thousands of users requires a phased, well-resourced program with robust data migration tools and a clearly staged rollout.
- Costs shift rather than vanish: license savings are real, but the state paid heavily for migration, integration, training and early friction. Those investments flowed to European firms and integrators — a deliberate policy effect rather than an incidental one.
- Functionality and user experience matter: the state retained Windows for the time being while replacing office productivity suites and email clients — a pragmatic compromise that reduced risk.
- Political signalling matters: the move was framed as a sovereignty and economic-retention policy — keeping public money and capability within the European sphere.
Schleswig‑Holstein’s approach is instructive because it is pragmatic: it replaces vendor lock‑in where feasible, keeps the most difficult transitions incremental, and channels procurement spend to local suppliers during the change. That is the kind of “concrete step” digital ministers have been recommending: start with clear, manageable wins and scale them.
What the migration doesn’t solve — and why that’s important
Replacing Office with LibreOffice and Exchange with Open‑Xchange removes a layer of dependence, but it does not magically eliminate all exposure. Many modern services are pluggable in complex ways: authentication can still be federated through external identity providers; file storage may remain on third‑party clouds; and software development pipelines still often pull dependencies and CI artifacts from global repositories and registries. Migrating clients and servers addresses immediate operational control, but the larger structural issue — where critical data flows and software supply chains cross jurisdictions — still needs holistic attention.
The economic scale: public money, licences and the case for retention
Public procurement is public policy. When governments spend tens or hundreds of millions on software licences, those purchases become strategic levers: they shape markets, lock in vendor roadmaps, and transfer taxpayer money across borders.
Speakers at recent policy fora have cited striking headline numbers — estimates that EU institutions and public bodies collectively spend hundreds of millions of euros annually on productivity and collaboration subscriptions. Independent commentators and analysts have modelled similar orders of magnitude and argued that the payoff for redirecting even a fraction of that procurement toward European suppliers or open-source ecosystems would be economic stimulus for local software companies and reduced strategic exposure.
Two practical economic points follow:
- Even where licences are a small percentage of GDP, they represent concentrated recurring spending. Replacing or reshaping that recurring spend amplifies its fiscal impact across the domestic industry.
- Spending on open-source alternatives is not “free.” It is an investment: implementation, support, integration, training and long-term maintenance cost money — but that money can be captured by European vendors and service providers instead of flowing overseas.
Policy-makers and procurement professionals must therefore treat software procurement as industrial strategy, not merely as IT transactions.
Legal and security exposure: the tug of extra‑jurisdictional law
A key driver of the new urgency is legal exposure: U.S. statutes and law‑enforcement powers extend to many technology companies and their subsidiaries irrespective of where data is physically stored. The Clarifying Lawful Overseas Use of Data Act (the CLOUD Act) and related legal mechanisms permit U.S. authorities to compel data disclosure from providers subject to U.S. jurisdiction — even if the servers are in Europe. That reality creates a systemic conflict between EU data protection norms (GDPR) and extraterritorial legal access mechanisms.
Operationally, the risk manifests in three ways:
- Legal compulsion: courts and law‑enforcement orders can require U.S.-based providers to produce data or restrict accounts; the provider then faces a legal choice between compliance and contestation.
- Sanctions and export controls: geopolitical decisions and sanctions regimes can force or incentivize vendors to block access or services for targeted entities or regions.
- Operational outages and administrative control: a global provider can impose configuration changes, throttle service, or suffer an outage that affects many customers at once — a single point of failure at scale.
Those are not just theoretical possibilities. Over the past years, large cloud providers and SaaS platforms have experienced wide outages that disrupted government services; companies have also modified access in response to legal or policy pressures. At the same time, code hosting and distribution ecosystems (where packages, containers and libraries are hosted) are single points of failure for a huge swathe of software development — making the control of those platforms strategically significant.
The open-source paradox: freedom, cost and vendor dynamics
The push to “de‑Microsoft” public administration is often framed under the banner of open source and digital sovereignty. But open source does not mean “no cost” — nor does it mean a single, simple answer to sovereignty.
Key realities:
- Open source shifts costs from licensing to integration, support, and sustained maintenance. Those recurring costs still exist; they are just captured differently.
- Open-source success depends on a healthy ecosystem: maintainers, contributors, commercial support providers and standards. Governments can accelerate that ecosystem by procuring services, funding upstream maintainers, and sponsoring long-term maintenance.
- Owning upstream code or hosting it domestically reduces one axis of risk, but it does not automatically reduce others (for example, developer tooling, CI/CD pipelines, or external package dependency usage).
The political and economic opportunity lies in using public procurement and grant funding to build a resilient European open-source ecosystem that captures value and reduces the need for foreign tooling.
The software supply chain: GitHub, npm, Maven and the choke points
The software we run depends on a global network of repositories and package registries. Many projects mirror or directly use hosting on services owned by U.S. companies — most notably GitHub. Microsoft’s acquisition of GitHub in 2018 consolidated code hosting under a company headquartered in the United States. That consolidation matters because modern software almost always depends on upstream components distributed via package managers and hosted repositories.
Operational dependencies arising from this reality include:
- A service outage at a major host can stop builds and deployments across dozens or hundreds of organizations.
- Policy or legal actions could disrupt access to particular accounts, repositories or packages.
- Centralized visibility can create systemic risk if supply chains are not diversified or mirrored.
Mitigations include cached mirrors, multiple registries, strict provenance and reproducible builds — and, importantly, political choices about supporting alternative, European-hosted developer platforms and registries.
What the EU and member states can and should do — a pragmatic roadmap
Winning strategic independence is not about a single radical “rip‑out” of foreign software. It’s about layered, risk‑aware steps that preserve continuity while shifting control. The following roadmap is deliberately practical and tactical.
Short-term (0–12 months): visibility, containment, and pilots
- Inventory and dependency map: every public body must maintain a live, authoritative inventory of software dependencies, hosted services, data flows and critical accounts. This map is the single most important baseline for risk management.
- Resilience engineering for critical services: mandate local caching, mirrors and failover paths for package registries, CI artifacts and key code repositories used in government builds.
- Legal risk review: review contracts and data locations against extraterritorial legal exposure (Cloud Act, MLATs, export controls) and identify where legal safeguards, notice provisions or geofencing are needed.
- Targeted pilot projects: start with pilot migrations for high‑value, low‑risk domains (for example, internal document workflows or non-critical email) to validate integration patterns, training needs and operational bounds.
- Fund maintainers: use procurement and procurement-adjacent grants to fund critical open-source maintainers whose code is used in public services.
Medium-term (1–3 years): scale, procurement reform, and capability building
- Procurement as industrial policy: rewrite procurement frameworks to favor open standards, clause-based code reuse requirements, and local maintenance obligations — not “lowest license price” alone.
- Build EU OSPOs and shared services: invest in European‑hosted Open Source Program Offices and federated platform services for code hosting, CI/CD runners, and registries with strong SLAs and legal frameworks.
- Training and change management: large‑scale migrations require comprehensive user‑level training, admin upskilling and ongoing support contracts; budget for it upfront.
- Interoperability and standards: demand adherence to open standards (document formats, APIs) in all procurement, and require exportable, documented data formats.
Long-term (3–7 years): platform sovereignty and ecosystem maturity
- Regional cloud and platform alternatives: encourage European hyperscalers, neutral cloud providers and federated platforms that offer robust data governance and legal clarity.
- Strategic public procurement to seed market: use long-term public contracts to create viable commercial ecosystems around open-source stacks — sustainable, domestic alternatives to vendor lock‑in.
- Research and developer ecosystem investment: fund research into reproducible builds, secure supply chain tooling and resilient package distribution models.
- Legal harmonization: push for international agreements and multi-lateral instruments that limit overreach and clarify cross-border data access while preserving law‑enforcement cooperation.
The trade-offs and real risks — be honest about what moves require
Moving away from dominant vendors yields strategic benefits, but the transition is not without real costs and risks. Responsible policy-making must weigh them:
- Migration costs can be front‑loaded and politically sensitive. The budget to migrate large workforces is real, and the benefits are often mid‑to-long-term.
- Security risks during migration are non-trivial: misconfigurations, incomplete rollouts, and shadow IT can increase short-term exposure.
- Some niche or advanced capabilities may remain better served by incumbent proprietary tools for the foreseeable future. A one-size-fits-all purge is neither realistic nor wise.
- Fragmentation risk: if every member state pursues a different stack without interoperability rules, the EU could fragment its digital infrastructure and lose economies of scale.
A strategic approach acknowledges these trade-offs and designs programs that spread cost, minimize disruption, and preserve interoperability.
Business and market implications: a growth story for European tech
A coordinated public shift towards open-source and regional platforms is not only defensive; it can be an industrial policy win. Public procurement, applied as seed funding, can create sustainable commercial markets for:
- European-hosted code and artifact registries with enterprise-grade SLAs.
- Managed services for open-source stacks (email platforms, identity and access management, collaboration platforms).
- Trusted maintainers and vendors who provide long-term support for components used in critical public services.
If the EU treats procurement as an investment rather than purely an expense line-item, that money becomes a lever to build local capability, retain value on the continent, and create a more resilient supplier base.
What’s already changing: policy signals and international momentum
Momentum is accumulating in multiple forums: cities and regions adopting open-source principles, UN agencies endorsing Open Source Principles, and national governments funding digital sovereignty initiatives. These are not merely ideological moves — they create practical incentives for building local capacity.
At the same time, multilateral frameworks (including UN guidelines and EC-level interoperability rules) are converging on the idea that open-source and shared public goods should be default choices when public funds are used to build software. That political momentum matters: a legal and procurement environment that rewards openness will change vendor behaviour and market structure.
Claims and numbers to treat with caution
The debate is full of striking statistics and dramatic formulations; some are well-documented, others are estimates or event-stage soundbites. Two important points of caution:
- Estimates of total EU spending on specific licences (for example, global productivity suites) vary widely depending on scope and which institutions are included. Publicly reported procurement and licensing numbers exist, but aggregate estimates should be treated as indicative rather than precise until validated against procurement datasets.
- Quotations about how quickly a U.S. provider could “turn off” services are rhetorical to underline a systemic exposure; operationally, the reality is more nuanced. Providers are constrained by commercial contracts, reputational risk, legal procedures and technical architecture. However, narrow administrative actions (account freezes, service restrictions or legal orders) can have immediate operational impacts on specific customers.
Responsible policy and procurement rest on validated inventories and legally informed threat models — not slogans.
Clear, actionable checklist for public‑sector CIOs and ministers
- Map dependencies: inventory all hosted services, code hosting, package registries and data locations.
- Classify criticality: define what services must be available under all circumstances, and plan resilient alternatives.
- Require provenance: mandate reproducible builds, signed artifacts and provenance metadata in procurement.
- Contractual protections: negotiate transparency clauses, escrow arrangements and jurisdictional guarantees where possible.
- Fund upstream: budget to support maintainers of code used in public services.
- Pilot and learn: validate user migration patterns with real world pilots before broad rollouts.
- Coordinate regionally: collaborate with neighboring public bodies to build shared platform services and capture scale economies.
Conclusion: sovereignty through prudence, not panic
The conversation in Brussels and across European capitals is no longer abstract. The choices are practical, political and economic. Dependence on a handful of global vendors delivers undeniable benefits — but it creates asymmetries that are now seen as strategic liabilities.
The right response is not ideological repudiation nor naive optimism. It is a sober program of inventory, piloting, legal clarity and targeted procurement that channels public money into building resilient, interoperable, and European-controlled alternatives where it matters most. The Schleswig‑Holstein example shows that significant change is achievable, but it also demonstrates the real costs and complexity involved.
For governments, the guiding principle should be layered resilience: reduce single points of failure, diversify suppliers and hosting jurisdictions, invest in European maintenance ecosystems, and treat software procurement as long‑term infrastructure policy rather than a short-term license negotiation. That path won’t be cheap or instant — but it will be the surest way to ensure that public administrations remain operationally autonomous, legally resilient, and economically beneficial to the societies they serve.
Source: theregister.com
'The EU runs on Microsoft' – and Uncle Sam could turn it off