Featured

Public Procurement Exposes Techno-Feudalism, Systemic Problems, and Geopolitical Vulnerability

Digital Vassals: How the Rejection of Open Source in Public Infrastructure Exposes Techno-Feudalism, Corruption, and Geopolitical Vulnerability


"Whoever controls the code controls reality. Whoever controls reality doesn’t need tanks."

Editorial Transparency: Research and structuring assisted by AI tools (Claude, Anthropic). Editorial responsibility and analytical judgment belong to the author.


A Competition the Vassals Don’t Know They’re Losing

There is a tacit convention in public discourse about the digitalisation of the state—a convention that politicians, corporate consultants, and tech journalists reproduce with almost liturgical fidelity: that adopting a new IT system, a new software package, or a new cloud contract represents, in itself, progress. That "modernisation" is a neutral, de-ideologised category, the technical equivalent of moving forward. That a ministry migrating to the infrastructure of an American or European tech giant has taken an evolutionary step, not an act of surrender.

This convention is a well-maintained lie. And it is precisely the meticulous care with which it is reproduced—in press releases, in ignored audit reports, in the inaugural speeches of systems that don’t work at launch—that should alert us to its political utility.

The world we live in is no longer organised around classical military blocs, though these still exist. Instead, it is organised around architectures of digital power. The competition between the United States, China, and—more timidly—the European Union is not played out solely on battlefields or through economic sanctions. It is played out in technical standards, in communication protocols, in the file formats public officials open in the morning, in the algorithms processing pension applications, in the databases storing an entire nation’s medical history.

And in this competition, a state that refuses to adopt Open Source solutions, that systematically prefers proprietary vendor contracts, is not making a neutral technical choice. It is making a geopolitical choice. It is choosing to be a vassal.

What follows is not a manifesto for free software in the evangelical sense in which the GNU movement formulated it in the 1980s, with the typical enthusiasm of Californian counterculture. It is a cold analysis of the mechanisms by which dependence on proprietary software in public infrastructure reproduces, in the digital register, the oldest forms of political and economic domination, while simultaneously expanding a state’s attack surface against external adversaries. In other words, it is an anatomy of voluntary vassalage.


The Anatomy of Techno-Feudalism: The Rent That Doesn’t Appear in Any National Balance Sheet

Yanis Varoufakis did not invent the term "techno-feudalism", but he had the merit of inserting it into the current analytical vocabulary with a precision that goes beyond mere polemical metaphor. His central argument, reformulated in the terms that concern us, is this: classic capitalism, which functioned on the basis of profit extracted from production and exchange, has been partially replaced by a form of digital rent-seeking, in which the owners of platforms and software infrastructure do not produce value in the classical Marxist sense, but extract a tax on the digital existence of everyone else.

Apply this scheme to the relationship between a state and its proprietary software providers, and you get a picture that should produce indignation, but instead produces annually renewed maintenance contracts.

A ministry that operates on a licensed ERP system, a proprietary productivity suite, and a cloud solution provided by a corporation headquartered outside national borders does not own the infrastructure on which its administrative processes run. It owns the contract that allows it to use that infrastructure. This is not a minor legal distinction. It is the difference between an owner and a serf paying tribute.

Digital feudal rent operates through several overlapping and mutually reinforcing mechanisms.

1. Perpetual Licences

A euphemism for a dependency relationship without an expiration date. A public institution that has migrated all its processes to a proprietary platform no longer has, after a few years, the technical capacity to migrate to anything else—because staff no longer know how to work differently, documents are stored in proprietary formats incompatible with alternatives, and procedural knowledge has settled into the interface of an external provider. The cost of exiting this relationship is never calculated at the time of signing the initial contract, because it is not in the interest of any party at the table to do so.

2. Forced Updates

The proprietary vendor controls the product’s lifecycle. It decides when a version becomes "end of life"—unsupported, a security vulnerability. At that moment, the public institution has no choice: pay for the upgrade or remain exposed. This asymmetry of power, where the client cannot negotiate the timing and conditions of the transition, is the very definition of feudalism in any age: the serf does not decide when the harvest changes.

3. Code Opacity (The Most Insidious Mechanism)

Proprietary software is a black box. Not because it’s too complex to understand, but because the vendor has deliberately built a legal and technical wall around its internal mechanisms. This is, in Shoshana Zuboff’s terms, a pure form of "surveillance capitalism" in reverse: while Zuboff describes how corporations collect data about users, the opacity of proprietary state software describes how the collective user—the state and its citizens—cannot know what the system does with their data.

And the state, instead of rebelling against this opacity, pays for it. It finances it with public money. It legitimises it through contracts signed by officials who either do not understand what they are buying or understand all too well why it is advantageous not to understand.


Total Technological Competition: Ignoring Open Source as an Act of Strategic Suicide

To understand why the rejection of Open Source in state infrastructure has moved from a budgetary efficiency problem to a critical national security vulnerability, we must look at how strategic adversaries of Western democracies—and Western democracies themselves—think about software as an instrument of power.

China did not adopt Linux in public administration and the military for ideological reasons or because it read Richard Stallman’s manifestos. It adopted it because it realised something essential: dependence on Windows or any other American proprietary system represented a geopolitical kill switch, a hidden dead man’s hand in the national infrastructure. If diplomatic relations deteriorate, if economic sanctions escalate, if a direct conflict arises, the vendor could deactivate licences, stop security updates, or—through obscure clauses in licensing contracts—cooperate with its own government to provide access to the adversary’s critical systems.

This is not paranoia. It is basic geopolitics, which all great powers practise and which small states, caught in the logic of public procurement, consistently choose to ignore.

Russia—regardless of the moral evaluation we make of Putin’s regime—has initiated systematic programmes to transition to Russian and Open Source software for critical infrastructures precisely for this reason. Not because they are better at free software, but because they understand that allowing a strategic adversary to control the code running ministries, hospitals, and power plants is equivalent to allowing enemy troops to set up garrisons in your own institutions.

India, through government initiatives centred on the FOSS (Free and Open Source Software) platform, has built a national tech industry partially anchored in open ecosystems. South Korea, Germany, France—all have initiatives, some timid, others more consistent, to transition to Open Source solutions in the public sector, explicitly motivated by digital sovereignty arguments.

And the states that do nothing, that continue to sign multi-year contracts with the same vendors, renewing dependence with each budget cycle, are participating in the global technological competition with their hands tied behind their backs and blindfolds over their eyes.

The speed of innovation in Open Source ecosystems is a technical argument, but with direct strategic consequences. When a critical vulnerability is discovered in a widely used Open Source system, the global developer community produces, tests, and distributes patches in hours or days. Patches for proprietary systems follow corporate approval cycles that can take weeks or months, during which vulnerable systems remain exposed. And if the vendor has decided that your software version is no longer a priority, you might not receive any patch at all.

But the deeper argument is not one of speed, but of knowledge and power. The concept of "security through obscurity"—the belief that a system is more secure because no one can see its code—is one of the most persistent myths in the bureaucratic culture of cybersecurity. In reality, obscurity does not protect—it masks. The intelligence agencies of major powers—NSA, GCHQ, FSB, MSS—invest massive resources precisely in discovering Zero-Day vulnerabilities in proprietary systems used by their adversaries. These vulnerabilities are discovered in secret, not disclosed to vendors, and exploited in silence, sometimes for years, before anyone realises they have been compromised.

Snowden confirmed what security analysts had long known: backdoors in commercial proprietary systems are not a conspiracy scenario—they are documented practice. And a state that installs proprietary systems in its critical institutions does not know for certain whether it has installed an administrative efficiency solution or a well-disguised backdoor in its licensing contracts.

Publicly auditable source code—which can be verified, dissected, and reproduced by anyone with technical competence—does not eliminate vulnerabilities (no system is perfect), but it democratises their discovery. It offers the possibility for independent researchers, academic institutions, and even the state’s own intelligence services to verify exactly what every line of code in the critical infrastructure does. This is not a techno-libertarian utopia. It is a basic requirement of strategic hygiene for any state that claims to exercise sovereignty.


The Toxic Alliance: How Systemic Problems Make Vassalage Possible and Perpetuate It

No state deliberately chooses to be a digital vassal. But there are states where decision-making mechanisms have been captured by interests that benefit from vassalage.

This distinction is crucial because it shifts the analytical register: we are not talking about institutional incompetence—though that exists—but about a form of systemic corruption that has its own logic, its own internal rationality, and its own identifiable beneficiaries.

The Corporate Lobby in Public Procurement

The lobby of major software vendors in public procurement is not an anomaly of the system—it is a feature of it. Global tech corporations are not more or less moral than other corporations; they are simply entities that maximise profit within the available rules. And if the available rules allow the capture of the public decision-making process through various forms of "advocacy", "public-private partnerships", and the hiring of former officials as consultants, then that is exactly what happens.

The Classic Mechanism: "Dedicated" Terms of Reference

Drafting the technical requirements for a public IT tender is a political act, not a technical one. When the technical specifications of a tender for a ministry’s IT system include requirements for compatibility with specific proprietary formats, or request integration with platforms that only work through proprietary APIs, or define "relevant experience" in terms that exclude, by definition, any bidder who has not previously won similar contracts with the same vendor, then the tender is not an open competition—it is a ritual of legitimising a decision already made.

This is, in Colin Crouch’s vocabulary, "post-democracy" applied to IT procurement: the form remains, but the substance disappears. We have tenders, we have commissions, we have audits, we have implementation reports, we have all the procedures through which a democratic decision should be taken and verified. But the result is predetermined by the actors who have access to the requirement-drafting process, not to its voting.

Corruption in Public IT Procurement: A Specific Kind of Capture

Corruption in public IT procurement has a specificity that makes it harder to identify than classic bribery. It doesn’t necessarily circulate in envelopes. It circulates in job offers for former ministers or state secretaries, in "consulting" contracts for firms associated with decision-makers, in partnerships with universities or research centres in close proximity to political power. Or, more elegantly, it circulates in election campaign funding, in media access, in support for the political careers of those who make favourable decisions.

The net result is a systematic transfer of public resources, through the contractual chain of software licences, to transnational corporations—and, in parallel, an informal tax extracted by local intermediaries who facilitate corporate access to these resources. It is a two-tier extraction scheme: digital rent paid to the Senior Techno-Feudal Lord and the feudal commission collected by the internal vassal.

But the consequence that goes beyond mere economic redistribution is this: a public official or politician who has obtained personal benefits from a contract with a proprietary vendor has a structural, active interest in maintaining this dependency relationship. They have an interest in sabotaging any discussion about Open Source alternatives. They have an interest in keeping the corruption ecosystem functional, because its disintegration would mean the disappearance of their off-budget income source.

In other words, corruption in IT procurement is not just a moral failure of individuals. It is a mechanism that aligns the interests of corrupt officials with those of monopolistic vendors—and opposes both, as a bloc, to any reform towards transparency and digital sovereignty. And in this alignment of interests lies the explanation for the systematic resistance to Open Source in states with high levels of institutional corruption: it is not a matter of technical ignorance, but of self-defence of an extraction system that works perfectly.


Digital Serfs: Citizenship as an Extractive Resource

There is a dimension of digital techno-feudalism that targets not the relationship between the state and the software vendor, but the relationship between the state and its citizens. It is the dimension that Zuboff analyses under the concept of "surveillance capitalism", but which, in the context of state infrastructure, takes on a more perverse specific form: data extraction not as a side effect of using a private service, but as an intrinsic function of exercising civil rights.

When a citizen submits a pension application through a state portal running on proprietary infrastructure, when they access their electronic medical file through a system provided by a private corporation, when they pay taxes through an application whose internal processes are opaque even to the tax authority itself, they are not a user of a public service. They are a subject of data extraction in a system they cannot audit, cannot challenge, and cannot, in most cases, avoid.

The medical, tax, biometric, and behavioural data collected through the state’s digital infrastructure does not belong to the state in any practical sense. It belongs to the contract between the state and the software vendor, a contract whose clauses regarding data ownership, secondary processing, and third-party access are, for the most part, drafted by the vendor and accepted by state officials who sign without reading the technical annexes.

This is what authors such as Aral Balkan or Nick Couldry call "data extractivism" in state form: a model in which the state, which should be the guarantor of citizens’ rights—including in the digital space—becomes instead an intermediary that captures data about citizens and delivers it, through the contractual architecture, to external private entities.

Illusory Digital Sovereignty

States adopt laws on data protection, issue regulations, establish supervisory authorities, and build an impressive normative apparatus of digital citizen rights. And simultaneously, they sign contracts under which the infrastructure processing this data is owned, controlled, and updated by private corporations whose interests do not align with those of the citizens in question.

GDPR, the glorious European data protection reform, is a sublime example of this structural hypocrisy. A regulation that imposes gigantic obligations on private data processors but leaves relatively unexplored the conditions under which the state’s own institutions process personal data through external proprietary platforms. The guarantee of "confidentiality" of a citizen’s tax or medical data becomes a legal fiction when the architecture of the system processing it is inaccessible to public audit and controlled by an entity subject to another jurisdiction.

There is also a class dimension to this equation, which rarely appears in techno-optimist discourse. Those who can avoid or minimise exposure to the state’s digital infrastructure—through access to alternative private services, through the ability to hire legal advisors to navigate bureaucracy without using official portals, or simply through the cultural capital that allows them to understand what they are ceding when they accept the terms of use—are, without exception, the segments of the population with greater resources. Digital serfdom has its own stratification: those most exposed to data extractivism through public infrastructure are those who depend the most on public services.


Sovereignty as Practice, Not as Rhetoric

"Public Money, Public Code"

The "Public Money, Public Code" campaign, launched by the Free Software Foundation Europe and supported by a coalition of civil society organisations, has a simple argument that, precisely because of its simplicity, exposes the absurdity of current arrangements: if software is developed or purchased with public money, its source code should be public.

This is not a technical or budgetary efficiency argument, though both applications are valid. It is a constitutional argument. If popular sovereignty means anything in the digital age, it means that citizens have the right to know how the tools that govern them work. An algorithm that decides eligibility for social assistance, a system that processes criminal records, a platform that manages public procurement—these are instruments of public power. Their opacity is incompatible with fundamental democratic principles, not with the technical preferences of a community of programmers.

The Techno-Feudal Argument Against Transparency

The argument against code transparency is always the same: "If we make the code public, we will expose it to attackers." This is an argument that works almost exclusively through technical intimidation of an uninformed public, because its premise is false.

Security vulnerabilities do not disappear through obscurity—they disappear through audits, testing, and exposure to a wide community of researchers who can identify and report them.

Concrete examples exist and are hard to dismiss:

  • Estonia’s internet voting system, though debated from multiple security perspectives, has partially public source code.
  • The Linux systems running NATO’s infrastructure—rarely mentioned in "security through obscurity" discussions.
  • Germany’s digital taxation system, partially based on Open Source components.
  • The French army, which uses customised Linux distributions for its classified communication systems.

These examples exist not because their leaders abandoned security in favour of Open Source ideology, but because they calculated the exact opposite of vassal bureaucracy: auditable transparency provides more real security than contractual opacity.

Transitioning to Open Source in Public Infrastructure

Transitioning to Open Source in public infrastructure does not mean that the state suddenly becomes more competent or that institutional problems disappear. It means redistributing power: from external vendors who own the code to local communities of programmers who can modify, adapt, and maintain it. It means that licence budgets can become salaries for local engineers, that technical expertise accumulates within the institution instead of being permanently imported. It means that, in the event of a diplomatic crisis or conflict, the state can continue to function because it does not depend on a vendor’s activation key from another jurisdiction.

This is the real democratisation of digital technology in the public sector: not putting an iPad on the official’s desk, but transitioning from a feudal dependency relationship to one of sovereign competence.


Infrastructure as a Battlefield: Lessons the Vassal States Refuse to Hear

The Russian invasion of Ukraine—alongside its evident tragedies—provided an accelerated course in digital geopolitics that should be studied carefully by every state claiming to be concerned about its own security.

The cyberattacks that preceded and accompanied the physical invasion did not target exclusively military systems. They targeted civilian digital infrastructure: energy systems, communication networks, government databases, financial systems. And one detail that largely went unnoticed in media coverage: the differentiated vulnerability of state systems depending on their architecture.

Ukraine benefited, in the early phases of the conflict, from rapid mobilisation of the international cybersecurity community, made possible in part because some of its critical digital infrastructure used systems that could be quickly audited, patched, and supported by external experts without requiring permission from proprietary vendors. Where systems were fully proprietary, external help was slower and more limited.

The lesson is clear, even if it was not formulated as such in any official statement: in times of crisis, the ability to quickly repair and adapt digital infrastructure depends on access to the source code. A state whose digital infrastructure is exclusively distributed through proprietary licences cannot, legally or practically, receive rapid external technical assistance without the consent of the original vendors. It is a different kind of kill switch: not one activated by the adversary, but one built into its own contracts.

Technological Imperialism

The concept of "infrastructure as a battlefield" is no longer an alarmist metaphor. It is a reality documented by every modern conflict with a significant cyber component. And a state that does not understand that the software architecture of its institutions is a strategic variable, not an administrative one, is participating in a modern conflict with a structural vulnerability that the adversary knows about and its own citizens do not.

Technological imperialism is not a rhetorical concept reserved for anti-globalisation discourse. It is a functional description of how digital hegemonies—whether corporate or state-based—extract value, control information flows, and maintain dependencies that ensure their influence. The difference from classic imperialism is that it does not send armies—it sends licensing contracts. And the effects of colonisation are harder to observe because they are masked in user-friendly interfaces and promises of efficiency.

A state that signs a cloud contract with an American vendor is not just making an IT purchase. It is submitting to the jurisdiction of the CLOUD Act, which allows the US government to request access to data stored by American companies on servers anywhere in the world, regardless of local data protection legislation. This is not a national security hypothesis. It is positive American law, applied.

And yet, vassal states continue to migrate sensitive data to these platforms. Because there are consulting commissions that make this decision attractive. Because there are officials who do not know and do not want to know. And because there is a deeply conformist institutional culture that treats any procurement decision validated by precedent as a sacred tradition.


Resistance as Practice: Examples of Real Sovereignty vs. Sovereignty Theatre

If the above arguments are correct, then we should expect to find an inverse correlation between a state’s real level of digital sovereignty and its level of institutional corruption. And this correlation exists, though it is not perfect and is complicated by major geopolitical factors.

Germany: Partial Success, Corporate Backlash

Germany, through various Länder (states) and federal institutions, has adopted systems based on Open Source components for public administration. The most cited example is Munich’s LiMux project, which migrated 14,000 workstations to Linux before a partial regression—not for technical reasons, but due to documented corporate lobbying by researchers independent of Microsoft’s influence. This example illustrates the central tension: digital sovereignty is not a technical project—it is a political project that faces opposition from corporate interests.

France: Explicit Open Source Preference

France, through DINSIC and later DINUM, has built an explicit policy of preference for Open Source in public procurement, with notable results in certain areas of administration. The French army, as mentioned, operates on customised Linux distributions for classified communications—not out of sentimentality towards Stallman, but due to direct operational security calculations.

India: Large-Scale Digital Sovereignty

India, through initiatives like eSanjeevani or Digital India policies that include Open Source components, has built a massive digital medical and administrative infrastructure, partially using open ecosystems. Not because it is ideologically pure, but because total dependence on proprietary vendors at this scale would be financially and strategically unsustainable for an emerging economy aspiring to strategic autonomy.

Russia and China: The Uncomfortable Truth

And then there are a few states—uncomfortable to mention in a positive context—which have perhaps best understood the strategic argument: Russia and China. Regardless of the political evaluation of their regimes, Rosatom runs on internal Linux systems, the Chinese army has systematically migrated to Kylin OS (a Linux derivative), and the Chinese public administration has accelerated the transition to UOS (also a Linux derivative) precisely in response to commercial tensions with the US and the risk of withdrawal of access to American proprietary systems.

The tragic irony for vassal states in Central and Eastern Europe is this: the very states that proclaim themselves defenders of democracy and Western values have taken digital sovereignty lessons more seriously than the "free" states that continue to sign contracts with the same vendors.

Sovereignty Theatre: The Opposite of Real Sovereignty

Sovereignty theatre, in contrast, is the exact opposite: grand political declarations about "digital transformation", launches of government applications that reproduce the same dependence on commercial clouds, national digitalisation strategies that mention the word "sovereignty" but contract with the same vendors every time. It is an administrative pantomime: the form of sovereign discourse without any of its technical or political substance.


Conclusion: Opacity Is Betrayal, Dependence Is Surrender

At the end of this analysis, we must say directly what diplomatic rhetoric in audit reports and national strategies refuses to say: a state that, in 2025, continues to build its critical digital infrastructure exclusively on proprietary systems, to sign multi-year contracts with vendors whose loyalty is not to the citizens they serve, to block the adoption of Open Source through dedicated tenders and bureaucracies captured by corporate interests, is not making a technical or administrative mistake. It is making a political choice with grave strategic consequences.

This choice serves multiple beneficiaries simultaneously:

  • Corporations that collect perpetual digital rent.
  • Officials and politicians who extract commissions from the dependency relationship.
  • And, in the most sinister scenario, strategic adversaries who already have access to the backdoors in the code we cannot audit.

Digital techno-feudalism is not an expressive metaphor. It is an exact description of the relations of production and power that characterise the digital infrastructure of vassal states. Rent replaces investment. Dependence replaces competence. Opacity replaces accountability.

The rejection of Open Source is not, as its defenders claim, a technical preference based on performance or security criteria. It is the reflex of a power system that reproduces itself through opacity and feeds on dependence. A state that flees from auditable code flees from responsibility. A state that prefers dependence over digital sovereignty has chosen—consciously or not—to be a colony.

In an era of hybrid conflicts, total technological competition, and digital infrastructure as a battlefield, this choice is not just fiscally costly and morally corrupt. It is, in the most literal sense, an exploitable strategic vulnerability. It is an act of voluntary blindness in the face of an adversary who sees perfectly.

And the citizens who pay taxes for systems they cannot see, who use public services they cannot audit, and who are governed by algorithms they cannot challenge are, in the precise vocabulary of power analysis, serfs. Well-connected digital serfs, perhaps, but serfs nonetheless.

Code transparency is no longer an idealistic option of the Open Source community or an abstract principle of digital democracy. It is the demarcation line between:

  • A state that exercises real sovereignty and a digital colony with its own flag.
  • A citizen and a data subject.
  • A functional democracy and a democracy spectacle running on servers we do not own and code we do not read.

The choice, though it may seem technical, is political in the purest sense of the word.


This article is part of the "Geocriminality and Digital Power" series published on petrucojocaru.ro. The author declares the use of AI assistance tools in the documentation and writing process, in accordance with the editorial transparency policy of the publication network.

© Petru Cojocaru / ABSOLUT WEB EXPERT SRL — All rights reserved.


Select Online Bibliography

The references below are verifiable, publicly accessible sources used as an analytical foundation or as a point of critical counterargument in the construction of this essay. They do not represent an exhaustive list, but a reading guide for those who wish to verify, contest, or deepen the arguments.


Techno-Feudalism & Digital Political Economy

  • Varoufakis, Yanis — Technofeudalism: What Killed Capitalism (2023) Summary and extended interview: The Guardian

  • Zuboff, Shoshana — The Age of Surveillance Capitalism (2019) Introductory chapter: shoshanazuboff.com

  • Morozov, Evgeny — The Net Delusion: The Dark Side of Internet Freedom (2011); Current articles: evgenymorozov.substack.com

  • Crouch, Colin — Post-Democracy (2004) Analytical review and contemporary applications: Open Democracy


Open Source, Digital Sovereignty & Public Policies

  • Free Software Foundation Europe — "Public Money, Public Code" Campaign: publiccode.eu

  • European Commission — Open Source Software Strategy 2020–2023: ec.europa.eu

  • DINUM (France) — Open Source Preference Policy: code.gouv.fr

  • German Federal Ministry of the Interior — Open Source in Public Administration: cio.bund.de


European Technological Sovereignty Package (2026) — Official Documents & Critical Analyses

  • European Commission — EU Open Source Strategy & Communication on European Technological Sovereignty (3 June 2026): digital-strategy.ec.europa.eu

  • European Commission — Central Page: Tech Sovereignty Package (includes Chips Act 2.0, Cloud and AI Development Act, EU Open Source Strategy): digital-strategy.ec.europa.eu

  • TechPolicy.Press — How the EU's Tech Sovereignty Package Finally Puts Open Source to the Test (3 June 2026) — Critical analysis of the gap between ambition and contractual reality; identifies 3,609 contracts of EU member states with Microsoft, Amazon, and Google worth €10.8 billion: techpolicy.press

  • TechPolicy.Press — Does Europe Really Have a Plan for Tech Sovereignty? (29 June 2026) — Direct critique of the contradiction between declarations and practice: "EU member states keep procuring frontier technologies from US giants": techpolicy.press

  • Osborne Clarke — The new EU Open Source Strategy – Europe's path to digital sovereignty (12 June 2026) — Legal analysis of the implications of CADA and Cloud and AI Development Act: osborneclarke.com

  • Atlantic Council — Digital Sovereignty: Europe's Declaration of Independence? (12 February 2026) — Analytical report; includes European Parliament data: EU depends on non-member countries for over 80% of digital products, services, and infrastructure: atlanticcouncil.org

  • GLOBSEC — EU Open Source Digital Sovereignty Strategy Explained (25 June 2026): globsec.org

  • CNBC — 'A matter of national survival': European governments on digital sovereignty (18 February 2026) — Includes statement by Estonian Minister Liisa Pakosta: "This has made digital sovereignty a matter of national survival, not just IT policy": cnbc.com

  • Digital Independence — Digital Sovereignty in Europe (16 February 2026) — Includes European Parliament vote (471 vs. 68) for "Open Source first" and details about the Franco-German summit in November 2025; critical note: "the participating governments continue to award major IT contracts to US providers in parallel": digital-independence.org

  • Wire Blog — The State of Digital Sovereignty in Europe 2025 — Survey of 270+ European tech leaders; key data: 84% consider digital sovereignty a critical factor in vendor selection, but only a minority are convinced their current stack complies: wire.com

  • Digital Samba Blog — Europe's Dependency on Microsoft: A Threat to Its Digital Sovereignty? (May 2026) — Documents how tender design (bundling, proprietary compatibility, repeat procurement) systematically excludes European alternatives: digitalsamba.com

  • Kramer & Co — Digital Sovereignty: Why European Governments Are Breaking Up With Microsoft (November 2025) — Includes sworn testimony in the French Senate (June 2025) that Microsoft cannot guarantee that European data stored on its European servers is free from US government access; the case of Schleswig-Holstein and its transition to Linux/LibreOffice: kramerand.co

  • EuroStack Directory Project — Open Source and Digital Sovereignty: The Year 2024 in Europe (2025) — Annual review of FOSS implementations in European public administration, including OZG 2.0 (Germany) and the Open Source Monitor France study: euro-stack.com

  • ECDPM — Sovereignty in European International Digital Policy (April 2026) — Analysis of the tension between sovereignty proclamations and the continuation of procurement from non-European vendors: ecdpm.org


Cybersecurity, Geopolitics & Critical Infrastructure

  • Snowden, Edward — NSA/PRISM Documents, archived and analysed: The Guardian

  • CLOUD Act (2018) — Full text and legal analyses:

  • ENISA (European Union Agency for Cybersecurity) — Report on Software Dependencies in Critical Infrastructure: enisa.europa.eu

  • Atlantic Council — Cyber Operations and the Law of Armed Conflict: atlanticcouncil.org


Corruption & Capture of Public Decision-Making

  • Transparency International — Government Defence Integrity Index (includes IT procurement capture): transparency.org

  • Balkan Insight / BIRN — Investigations into public IT procurement in Central and Eastern Europe: balkaninsight.com

  • Corporate Europe Observatory — Corporate Tech Lobbying in the EU: corporateeurope.org


Case Studies & Documented Examples

  • Kylin OS (China) — Military and administrative Linux distribution: Wikipedia

  • Munich LiMux — Migration and regression case, with documentation of corporate lobbying: FSFE

  • Estonia e-Governance — Open sources and architecture of the national digital system: e-estonia.com


Key Questions to Retain—and Eloquent Answers

These questions are not rhetorical. They are analytical tools and should be asked aloud at any public meeting on digitalisation, any IT procurement conference, and to any politician speaking about "digital transformation."


1. Why does the state pay millions annually for software it does not own?

Because there is no sufficiently powerful political pressure mechanism to force another choice. The annual payment of licences is invisible in public discourse, buried in technical budget lines, and does not produce electoral scandal. The commission it generates for intermediaries, however, is highly visible to those who receive it. This asymmetry of visibility is deliberately maintained.


2. What happens if our main state software vendor decides to stop services in the event of a geopolitical conflict?

Exactly what has happened with various economic sanctions in recent years: institutional capabilities stop, because there is no functional alternative prepared. This is not a hypothetical scenario. It is a vulnerability already exploited in other contexts. The correct response to this question should be a contingency plan based on software that does not require external activation. Most likely, no such plan exists.


3. How can a citizen know if their medical data processed by a state proprietary system has been accessed by third parties?

They cannot. And this is exactly the problem. The citizen’s right to information about the processing of their personal data, formally guaranteed by GDPR, becomes inapplicable in practice when the architecture of the system processing it is opaque by design. Formal legal transparency coexists with real technical opacity, and this combination is the equivalent of a safe with a visible lock but no bottom.


4. Why did Munich return to Windows after migrating to Linux? Was it a technical failure?

No. It was a documented political failure. Independent reports and journalistic investigations have indicated that the decision to revert coincided with Microsoft moving its European headquarters to Munich, with a package of investments and hires that created an uncomfortable proximity between corporate interests and administrative decision-making. The technical failure was constructed retroactively to justify a political decision already made. This is the classic model.


5. Are there states that have successfully transitioned to Open Source in public administration? Why aren’t they more widely cited?

There are, and they are multiple: France (partially), Germany (in some Länder), India (at large scale), Estonia (with a partially open digital architecture), and—uncomfortably—states that Western geopolitical discourse makes it awkward to cite positively. They are not more widely cited because their success contradicts the narrative that Open Source in public administration is impractical or risky—a narrative that serves the interests of proprietary vendors, who have lobbying budgets far larger than any Open Source organisation.


6. What does "backdoor" concretely mean, and why is it relevant for state software?

A backdoor is a hidden mechanism in code that allows access to a system without the knowledge or consent of the legitimate user. There is documented evidence—Snowden being the most famous—that intelligence agencies have collaborated with proprietary software manufacturers to include or deliberately fail to remediate vulnerabilities that allow unauthorised access. Proprietary code cannot be publicly audited, so the presence or absence of backdoors cannot be verified. It is literally impossible to know for certain that proprietary state software does not contain such mechanisms.


7. Why do public procurement formulas de facto exclude Open Source solutions?

Because they are drafted by people who either have a direct interest in their exclusion or have received technical advice from entities with interests in the same direction. Technical requirements that demand native compatibility with proprietary formats, support from a vendor with a certain level of capitalisation, or experience exclusively with specific commercial solutions are artificial constructions of an unequal competitive landscape. Remedying this would require political will and independent technical knowledge in the tender-drafting committees. Both are systematically absent.


8. Isn’t Open Source more vulnerable because the code is visible to everyone, including attackers?

This is the most durable error in pro-proprietary security discourse. "Security through obscurity" is a principle rejected by every serious cybersecurity manual for at least three decades. Sophisticated attackers—whether criminal or state-based—have the resources to reverse-engineer any system. What they cannot do is compete with a global community of thousands of researchers actively auditing Open Source code. Vulnerabilities are discovered and resolved faster in open ecosystems precisely because more eyes are better than obscurity.


9. How is it possible that politicians do not understand these risks? Is it ignorance or complicity?

It is a combination, and the distinction between the two is sometimes smaller than it appears. Technical ignorance is real and widespread in the political class of almost any democracy. But ignorance also functions as a shield: a politician who chooses not to understand the implications of an IT contract cannot be accused of deliberate complicity, even if the consequences are identical. The incentive system creates selective ignorance: it is in the interest of many decision-makers not to understand exactly what they are signing.


10. What should an informed citizen concretely demand from their political representatives?

At least five specific and verifiable things:

  1. Publication of the source code of any software purchased with public money.
  2. Independent security audits of critical digital infrastructure, with public reports.
  3. Anti-vendor-lock-in clauses in all public IT contracts.
  4. Explicit bans on storing citizens’ data on cloud platforms subject to extraterritorial jurisdictions.
  5. Training and hiring programmes for software engineers in public institutions, to reduce dependence on external contractors.

None of these are technically or unrealistically demanding. All are political.


Author’s Note


Evolution of the Idea, Limits, Tensions, and Possible Errors

A note of intellectual honesty, because an essay without self-criticism is a sermon, not an analysis.


How the Idea for This Article Evolved

The starting point was a much narrower article about public IT procurement in Romania, focused on the budgetary mechanisms of software licence dependence. As documentation progressed, it became clear that the national problem cannot be understood without the geopolitical framework: the US-China-EU competition for dominance in digital standards, the escalation of hybrid conflicts with a significant cyber component, and the progressive documentation of institutional backdoors transformed a budgetary critique article into a digital geopolitics essay.

The second pivot came from a closer reading of the Munich case: an example initially used as proof of the possibility of transition turned, with additional documentation, into an example of corporate capture mechanisms of political decision-making. The ambiguity of the case enriched the analysis.


Assumed Limits

This essay is deliberately one-sided in its polemical register. The Morozovian tone chosen assumes a rhetorical intention: not the balanced presentation of a complex landscape, but the frontal attack on comfortable premises. This is a stylistic choice, not a methodological error, but the reader must be aware of it.

The analysis does not deeply cover the real costs of transitioning to Open Source, which exist and are significant: staff training costs, data migration costs, internal technical support costs, incompatibility management costs. These costs do not invalidate the central argument, but they necessarily nuance it.

There is also no systematic, statistical, and comparative analysis of the correlation between corruption levels and preference for proprietary software. There is a persuasive argumentative logic and concrete examples, but not a rigorous quantitative demonstration. The sceptical reader is right to demand more on this point.


Internal Tensions of the Argument

There is a fundamental tension that is not resolved in the text and which I explicitly acknowledge: I argue simultaneously that: (a) States with higher corruption levels more often choose proprietary software for rent-seeking reasons, and (b) Some authoritarian regimes (Russia, China) have adopted Open Source for strategic sovereignty reasons.

This juxtaposition creates real discomfort: the adoption of Open Source by non-democratic regimes does not validate Open Source as a democratic instrument. Digital sovereignty and digital democracy are, in fact, distinct concepts that can exist independently. A state can control the code of its own systems and, at the same time, use that control to surveil and oppress its citizens. The Chinese case is precisely this.

The argument that "Public Money, Public Code" is a democratic act assumes that publishing the code is accompanied by institutions truly capable of auditing it and holding it accountable. Without this institutional infrastructure, code transparency becomes a formality.


Possible Errors and Underestimated Perspectives

1. The Perspective of Public Administration Practitioners

There are officials who have tried to introduce Open Source solutions and have encountered not corruption, but institutional inertia, lack of local technical support, real incompatibilities with legacy systems. Their experience is more nuanced than a polemical essay allows.

2. The Perspective of Real Operational Security

Some arguments in favour of proprietary software in national security contexts are more solid than I treat them. An Open Source system used at scale is, theoretically, easier to attack through publicly known vulnerabilities. My counterargument (the community resolves them faster) is statistically valid, but not absolutely true in cases of critical systems with extreme security requirements.

3. The Short-Term Economic Perspective

Politicians with 4-year mandates have no incentive to invest in transitions with a 10–15 year horizon, even if they would bring considerable net benefits. This is not necessarily corruption, but a structural defect of electoral democracies in relation to long-term infrastructure investments.


On Positioning Towards the Official European Discourse: Critical Essay, Not Propaganda

There is a risk of misinterpretation that I want to address explicitly, because I thought about it during the writing and did not find a better way than to name it directly.

Some arguments in this essay partially and superficially coincide with lines of official European discourse. In June 2026, the European Commission adopted a legislative package on technological sovereignty—the EU Technological Sovereignty Package—which, for the first time in the history of European digital policy, includes an autonomous Open Source strategy. The European Parliament had already voted, in January 2026, with a majority of 471 to 68, on a resolution calling for the adoption of the "Open Source first" principle in European public procurement, a €10 billion sovereign technology fund, and the construction of a "Eurostack"—an end-to-end European digital infrastructure.

All of this sounds like the arguments in this essay. And it is precisely this similarity that forces me to make an essential positioning clarification.

This essay is not European propaganda, nor Euro-enthusiast, nor of any other nature. It is a critical, polemiical, anti-status-quo essay that happens to coincide on some points with official European lines. The difference is not in content, but in function: the official European discourse is performative and partially self-contradictory; the analysis in this essay targets precisely this contradiction.

The central problem that official European documents consistently ignore is this: while the Commission proclaims digital sovereignty and the Parliament votes for "Open Source first", member states continue to sign massive contracts with the same proprietary vendors they declare a strategic threat. An investigation cited by TechPolicy.Press identified 3,609 contracts or memoranda of understanding signed by EU member states with Microsoft, Amazon, or Google for cloud and AI services, worth a total of €10.8 billion—two-thirds with Microsoft alone. These contracts did not stop with the sovereignty declarations. They continued to grow in 2024 and 2025, the periods when sovereignist rhetoric was most visible.

Microsoft’s lawyer confirmed under oath in the French Senate, in June 2025, that the company cannot guarantee that French data stored on its European servers is free from tacit US government access. The CLOUD Act remains positive American law. And yet, French ministries continue to use Azure, just as German, Romanian, Polish ministries continue to pay Microsoft licences. Between the summit declaration and the contract signed the following week by the IT department of the same ministry, there is a gap that is not a coordination accident, but the result of the same corporate capture mechanisms described in this essay.

The paradox is therefore this: the EU produces the most ambitious digital sovereignty discourse in its history precisely at the moment when operational dependence on non-European vendors is at its highest. The Technological Sovereignty Package of June 2026 is, in this reading, not a solution to the problem described in this essay, but a belated confirmation of it. The fact that the Commission acknowledged in 2026 that dependence on proprietary software hinders digital sovereignty—a formulation that appears literally in official documents—does not mean the problem has been solved. It means the problem has become scandalous enough to enter press releases, which is not the same thing.

The critique in this essay is addressed not only to peripheral vassal states, but also to the European centre that proclaims sovereignty in documents and undermines it in contracts. If Germany and France, which sponsored the European Digital Sovereignty Summit in November 2025 and have invested €12 billion in alliances for a European sovereign cloud, continue in parallel to award major public IT contracts to American vendors—and they do, documented—then the difference from smaller, more corrupt member states is one of scale and rhetorical sophistication, not of substance.

This essay does not give the EU a certificate of good intentions. It gives it the same scepticism it applies to all actors who produce sovereignist discourse without applying it in their own procurement practices. The coincidence with some arguments from official European documents is exactly what it says: a partial coincidence of diagnosis, not an alignment of perspective or interests.


Explicit Lizards (Esoteric Language and Hidden Intentions)

In accordance with the tradition of analytical texts in this publication network, I explicitly mention where I used esoteric language—i.e., formulations that contain a more direct message than the surface one.


Lizard 1 — "Officials who sign without reading the technical annexes"

Direct message: There are officials who know perfectly well what they are signing and choose not to read precisely because they know. Ignorance is sometimes performed, not lived. The phrase deliberately leaves room for ambiguity.


Lizard 2 — "States that are uncomfortable to mention in a positive context"

The reference to Russia and China as examples of real digital sovereignty is intentionally uncomfortable. Esoteric message: If regimes we consider adversarial understand the strategic importance of Open Source better than our democracies, then the problem is not ideological, but one of captured interests. The discomfort is the argument.


Lizard 3 — "Administrative pantomime"

A deliberately theatrical formulation for a real phenomenon: sovereignty declarations accompanied by contracts with the same vendors are a show for the public, not real policy. Theatrical language is chosen to underline the performative nature of official discourse, not reality.


Lizard 4 — "Safe with a visible lock but no bottom"

A metaphor for GDPR applied to proprietary state systems: the formal right exists, the enforcement mechanism is void. The physical image of a useless safe transfers the absurdity of the legal structure into the intuitive register, avoiding a technical argument that would lose the uninformed reader.


Lizard 5 — "The choice to be a colony"

The final formulation is not an ornamental metaphor. It is a direct statement of power, masked in essayistic register: a state that knows it depends on infrastructures it does not control and does not act to change this situation has chosen subjugation. Political responsibility lies not with corporations or vendors, but with decision-makers who perpetuate dependence.


Rhetorical Devices Used

Analytical transparency also involves identifying one’s own persuasion tools.

  • Controlled Reductio ad Absurdam: The argument that "security through obscurity" protects is taken to its logical consequences to the point of collapse, without caricature.

  • Uncomfortable Historical Parallel: Medieval feudalism as a framework for contemporary digital relationships. The risk is anachronism; the benefit is that it makes the power structure immediately recognisable to a reader without a technical background.

  • Accumulation of Heterogeneous Examples: Germany, France, India, Ukraine, Russia, China. The deliberate heterogeneity prevents the accusation of partial selection; examples from opposing ideological camps that confirm the same structural argument.

  • Rhetorical Question Transformed into Analytical Tool: The "10 Questions" section is not rhetorical in the classic sense; the questions are followed by answers that refuse consolation and maintain epistemic discomfort.

  • Citing the Adversary: Including pro-proprietary perspectives (operational security, transition costs) before contesting them gives them apparent weight to make the rejection more credible.

  • Prosecutorial Tone: The scattered legal language (capitulation, betrayal, voluntary act of blindness) transfers moral responsibility from anonymous structures to identifiable agents, without explicitly naming them.


Call to Action: What You Can Do Tomorrow?

Not tomorrow in a figurative sense. Literally, tomorrow morning.


Concrete Actions

1. Check the Software Used by Public Institutions in Your County

Access the public procurement portal (SEAP, e-licitatie.ro in Romania), search for local or county institutions, and sort contracts by "software" or "licences". You don’t need technical expertise—you need time and curiosity. Which company provides the software for your town hall? Who has the contract for the population registry system? How many years does the contract last? Are there exit clauses?

2. Write a Short Email to the Author of a Recent Audit Report

The Court of Auditors publishes annual reports. Choose one that targets a ministry or public institution in the digital field. Write an email to the public contact address of the audited institution, explicitly asking: "What is your policy on Open Source software in IT procurements?" Don’t expect an answer; the number of unanswered emails is also information.

3. Distribute the "Public Money, Public Code" Campaign to a Local Official

publiccode.eu has a model letter in multiple languages. Send it with your own personal message to a local councillor, MP, or senator. It doesn’t matter if they read it. What matters is that the email trail exists.

4. Install and Use at Least One Open Source Tool in Your Professional Life

Not as a symbolic gesture, but as a direct experience. LibreOffice instead of Microsoft Office for a week. VLC, GIMP, Thunderbird, Firefox with privacy extensions. Not because they are superior in every way, but because direct experience changes how you perceive dependence.

5. Attend a Public Local or County Council Meeting When the IT Budget Is Discussed

Or, if none is scheduled, request one. The Transparency of Decision-Making Law (Law No. 52/2003 in Romania) allows you to attend and ask questions. The physical presence of a citizen interested in the IT contracts of the town hall produces a disproportionate effect compared to the effort involved.


What to Avoid

1. Do Not Confuse Open Source with Free

The most dangerous myth in discussions about alternatives to proprietary software is that Open Source solutions cost nothing. They cost implementation time, training, technical support, and adaptation. If you enter this discussion with the zero-cost argument, you will immediately lose against anyone who knows the reality. The correct argument is that of total cost of ownership and sovereignty, not free cost.

2. Do Not Treat This Problem as Exclusively Technical

If you discuss this with politicians or officials, avoid getting into technical details. Arguments about power, sovereignty, national security, and responsibility to citizens are much more effective than explanations about software architectures.

3. Do Not Demand Radical Immediate Change

Credible policy proposals are incremental: an anti-lock-in clause in new contracts, an independent audit of a single system, a code publication requirement for a single project. Incremental pragmatism is more dangerous to the status quo than total manifestos.

4. Do Not Ignore the Real Transition Costs

Any argument that minimises the real costs and difficulties of migrating to Open Source will be rightly rejected by practitioners. Acknowledge the costs, argue the long-term benefits, propose gradual transitions with verifiable milestones.

5. Do Not Stop at a Single Reading

This essay is a polemical entry point, not an exhaustive analysis. Morozov’s critics, defenders of hybrid cloud architectures, practitioners of Open Source transition in real administrations—all have arguments worth hearing and critically evaluating. Independent thinking does not mean replacing one set of clichés with another.


"The first act of digital sovereignty is not technical. It is epistemic: refusing to believe that the choice belongs to someone else." — P.C.