DEV Community

Nicolas Martinez
Nicolas Martinez

Posted on

Open source and sovereignty: anatomy of a strategic misunderstanding

#ai #opensource #cloud #sovereignty

Why the United States is pushing open source to better impose its standards — and why adopting Linux does not make you a sovereign state

By Nicolas Martinez, founder of LayerOps. The views expressed here are my own.

Open source enjoys a singular reputation. Freely inspectable code, permissive licenses, governance presented as community-driven: in the collective imagination, it embodies the antithesis of technological dependency. When a state or a company migrates from Microsoft to Linux, from Oracle to PostgreSQL, or from Jira to OpenProject, it feels it is wresting its digital destiny back from the clutches of proprietary giants.

This intuition is largely false. Worse: it is precisely the lever that U.S. public policy has been exploiting since 2016, and openly so since 2025. This article aims to dismantle the mechanism, with concrete examples, and to explain why conflating adopting open source with technological sovereignty is one of the most widespread — and most costly — strategic errors in today's digital landscape.

I. The American strategy is no longer implicit: it is written in plain text

For a long time, U.S. support for open source could pass for a pragmatic alignment of private interests. Tech giants released their code because it was good for productivity, recruitment, and brand image. Administrations followed suit because it was cheaper. The OMB Memorandum M-16-21 of August 2016 — the Federal Source Code Policy — already required federal agencies to release at least 20% of their custom-developed code as open source, explicitly arguing that open standards stimulate innovation and interoperability.

The turning point came in July 2025 with the publication of Winning the Race: America's AI Action Plan, the Trump administration's AI action plan. The text drops all pretense. It states that open models are more likely than closed models to become global standards with geostrategic value. The plan's third pillar, devoted to international diplomacy and security, calls for exporting the complete American AI technology stack — hardware, models, software applications, and standards — to every country willing to join the U.S. "AI alliance."

Chatham House analysts have characterized this as a strategy aimed at locking partners into dependent technological ecosystems, where American AI becomes both the foundation and the walls of the global digital economy's garden. The logic is exactly the same one Microsoft Office applied to office suites for thirty years, or that Google and Meta applied to digital advertising for twenty: turn a technology into unavoidable infrastructure, and infrastructure into normative power.

What changes with open source is the rhetorical frame. The proprietary standard is sold. The open-source standard is offered — and is adopted with a sense of victory by the very party adopting it. It is a soft-power operation of remarkable elegance.

II. The mechanism: why open source is a more effective vector of normative capture than proprietary software

To understand the mechanics, the most pedagogically useful case is Kubernetes, which in less than a decade has become the dominant container orchestration system on the planet.

The story is well known: Google develops an internal system called Borg, reimplements it as Kubernetes, then donates it in 2015 to the Cloud Native Computing Foundation (CNCF), a foundation hosted by the Linux Foundation. To ensure liftoff, Google grants the CNCF a $9 million subsidy in cloud credits to fund the testing and distribution infrastructure. Three years later, more than half of the Fortune 100 use Kubernetes for their containers.

The result is threefold. First, Google has turned its internal architecture into a universal grammar: any system that wants to interact with the modern cloud now speaks Kubernetes. Second, AWS, Microsoft Azure, and Google Cloud have built managed services (EKS, AKS, GKE) on top of this foundation: three American companies now monetize global orchestration. Third — and most subtly — every subsequent cloud-native innovation (service mesh, observability, progressive deployment) must fit Kubernetes' conceptual mold or face non-adoption. The normative capture is complete.

The same pattern recurs with TensorFlow and PyTorch (machine learning), React and Next.js (frontend), Envoy and Istio (networking), OpenTelemetry (observability). Each time, an American actor donates a software component to an American foundation, which ensures its global diffusion, and which becomes a de facto standard that the entire planet must then implement to remain compatible.

III. The "bazaar" fable: who really writes open source today

The open-source imaginary rests on the image of a community of passionate volunteers contributing in their spare time. This imaginary, fixed by Eric Raymond in The Cathedral and the Bazaar in 1999, no longer matches the industrial reality of 2025 at all.

According to the Linux Foundation's annual reports and analyses by Linux Weekly News (LWN), more than 80% of contributions to the Linux kernel today come from developers paid to do this work. In 2025, this figure reaches 84.3% of commits. The main contributors are Intel, Google, Meta, AMD, Red Hat, Linaro, and Huawei. Unpaid individual developers account for only 7.5% of the lines of code modified in recent LTS releases.

This data point is essential for understanding what follows: modern open source is no longer a social movement; it is a modality of industrial coordination. Foundations such as the Linux Foundation, the CNCF, the Apache Software Foundation, or the Eclipse Foundation are corporate-funded consortia whose technical boards are populated mostly by employees of those same corporations. The neutrality on display is a legal convention, not actual independence.

This corporate concentration is the bedrock of the capture strategy. When AWS sits on the technical steering committee of a project, shapes its roadmap, and offers its managed service on top of that very project, the open-source project has become a disguised commercial vehicle. The license remains free. The governance is not.

IV. The coercion is documented, not hypothetical

The most important point — and the one that definitively closes the debate on the "neutrality" of open source — is that U.S. jurisdiction applies to American open-source foundations. This is not a theoretical assumption: it is a legal fact verified at least twice.

First case: GitHub, July 2019. Following the application of U.S. sanctions, GitHub blocks the accounts of developers residing in Iran, Syria, Crimea, Cuba, and North Korea. An Iranian developer, Hamed Saeedi Fard, recounts losing access to his own private repositories without notice or any possibility of backup. The CEO at the time, Nat Friedman, publicly justifies the decision: GitHub is subject to U.S. trade law, like any company operating in the United States. Public repositories remain accessible, but private and paid accounts are frozen. Using a VPN to circumvent the measure is explicitly prohibited by the platform's terms of service.

Second case, and this one is seismic: the Linux Foundation, October 2024. The Linux project removes 11 Russian maintainers from the kernel's MAINTAINERS file, in line with the legal opinion of the Linux Foundation's lawyers, in application of OFAC sanctions tied to the invasion of Ukraine. The maintainers concerned worked on drivers for Baikal processors and on Acer and Cirrus hardware. Linus Torvalds confirms the decision on the kernel mailing list, citing "compliance requirements."

The decisive argument is the one formulated by the Software Freedom Conservancy, an organization otherwise committed to software freedom: the open-source community cannot operate independently of international sanctions programs, because those sanctions are the law of the country where the foundation is domiciled. The Linux Foundation is an American non-profit organization, fiscally registered in the United States. Linus Torvalds and Greg Kroah-Hartman, two key kernel figures, operate from U.S. soil. The code is open, but the institution that coordinates it is not.

Some, like maintainer Felipe Contreras, have contested the legal necessity of this decision, arguing that approving a patch does not constitute a transaction within the meaning of the sanctions. But the legal debate is secondary: the Linux Foundation chose to comply preemptively, without waiting for formal notice. This is exactly the chilling effect mechanism — the deterrent effect of a regulation that pushes actors to self-censor upstream. For anyone dependent on software coordinated from the United States, the conclusion is unambiguous: your software supply is subject to Washington's foreign-policy decisions.

V. Why sovereignty through open source is an illusion: the four levels of dependency

Once this fact is established, we need to introduce the conceptual distinction missing from most political discourse on digital sovereignty. Adopting open-source software does not eliminate dependency; it displaces it, and you need to understand where.

Any open-source software mobilizes four levels of dependency, which must be analyzed separately:

The first level is the license. A free license (GPL, Apache, MIT) guarantees the theoretical right to inspect the code, modify it, and redistribute it. That is the only real guarantee open source provides. It allows, in principle, forking a project if its direction no longer suits you.

The second level is governance. This is the legal entity that owns the trademarks, hosts the coordination infrastructure, arbitrates contributions, and decides the roadmap. For nearly all modern cloud-native projects, this entity is an American foundation — the Linux Foundation, the Apache Software Foundation, the CNCF — subject to U.S. law.

The third level is hosting and distribution. Code lives on GitHub (Microsoft), container images on Docker Hub, JavaScript packages on npm (Microsoft via GitHub), Python packages on PyPI (hosted in the U.S.), Java packages on Maven Central (Sonatype). The slightest geopolitical incident can sever access.

The fourth level is the human and operational ecosystem: the maintainers themselves, their employers, continuous integration pipelines, security fuzzers (OSS-Fuzz, funded by Google), bug bounty programs. This ecosystem is massively concentrated in the American sphere.

An Apache 2.0 license protects you only at the first level. It says nothing about the other three. And it is precisely at levels two, three, and four that coercion is concretely exercised, as the removal of Russian maintainers and the blocking of Iranian developers illustrate.

VI. Supply chain fragility: XZ Utils and IngressNightmare

A final point must be addressed to gauge the naivety of the "open source = secure and sovereign" reasoning: software supply chain security. Two recent affairs — one in 2024, the other in 2025 — illustrate the structural nature of the problem.

On March 29, 2024, a Microsoft engineer named Andres Freund discovers by chance an extremely sophisticated backdoor in XZ Utils, a compression library maintained for years by a burned-out volunteer. An attacker — operating under the pseudonym Jia Tan, and likely backed by a state actor given the patience and sophistication involved — had spent nearly three years gaining the trust of the original maintainer before obtaining commit rights, then introducing a backdoor in versions 5.6.0 and 5.6.1.

Reverse-dependency analysis revealed that the XZ library is used by roughly 30,000 packages in Debian and Ubuntu — the same order of magnitude as glibc, the standard C library. Had the backdoor not been detected in time, it would likely have been the worst supply-chain compromise since SolarWinds, affecting millions of Linux servers worldwide.

One might be tempted to classify XZ as an extreme case: a sophisticated, possibly state-level attack against an obscure library maintained by a single isolated volunteer. The next affair forbids that consolation. In March 2025, the security firm Wiz reveals a series of critical vulnerabilities dubbed IngressNightmare (CVE-2025-1974, CVSS score of 9.8 out of 10) in Ingress-NGINX, the most widely used ingress controller for exposing Kubernetes applications to the outside world. According to Wiz, around 43% of cloud environments were vulnerable, and more than 6,500 clusters — including Fortune 500 companies — were publicly exposing their vulnerable component, allowing an unauthenticated attacker to take complete control of the cluster by reading every secret stored within it.

The chilling detail is not the vulnerability itself, but what it revealed about the state of the project. Ingress-NGINX, used by more than 40% of Kubernetes administrators worldwide, deployed across countless managed platforms and critical infrastructures, was actually maintained by one or two people, on their own time and unpaid. On November 11, 2025, Kubernetes' Special Interest Group Network and the Security Response Committee officially announced the retirement of the project: "best-effort" maintenance will continue until March 2026, after which there will be no new releases, no bug fixes, and no security patches. The justification is plain: the project's attack surface has grown too large for its available human resources, and efforts to recruit additional maintainers have failed. A planned replacement called InGate had been launched; it too was abandoned for lack of hands.

The exact measure of this announcement deserves to sink in. Kubernetes is, as we saw above, the de facto standard of global container orchestration, donated by Google to the CNCF in 2015 and adopted by more than half of the Fortune 100. Ingress-NGINX is one of its most common front doors — the piece that decides which external traffic reaches which internal service. And this central piece of the apparatus turns out to have been held up by two exhausted volunteers, and is now being retired for lack of anyone to take up the torch. With XZ, one could still take refuge in the thesis of an exceptional state-level attack. With Ingress-NGINX, there is not even a sophisticated attack: it is the simple arithmetic of critical volunteer work catching up with global infrastructure at the very heart of the cloud-native ecosystem.

The lesson of XZ and IngressNightmare joins those of Heartbleed (2014) and Log4Shell (2021): critical fragments of the world's digital infrastructure rest on a handful of unpaid volunteers — sometimes exhausted, sometimes infiltrated, sometimes vanished. Open does not mean secure. Auditable does not mean audited. And certainly not sovereign.

VII. The inversion of the equation: why AI turns transparency into risk

The entire ideological edifice of open source has rested for thirty years on a formula attributed to Eric Raymond but inspired by Linus Torvalds: given enough eyeballs, all bugs are shallow. Code transparency, says Linus's law, is in itself a security posture. The more code is read by many developers, the faster flaws are discovered — and patched by defenders before attackers can exploit them. This equation became the mantra of the entire free-software movement.

That equation has just been broken. And the event that demonstrates it took place in April 2026.

On April 7, 2026, the American company Anthropic — one of the three leading frontier AI labs, alongside OpenAI and Google DeepMind — published a technical blog post announcing the capabilities of its new model, named Claude Mythos Preview. What followed is unprecedented in the history of generative AI announcements. The model, Anthropic's red team explained, is capable of autonomously discovering and exploiting zero-day vulnerabilities — that is, never previously identified — in real open-source codebases. Among its findings: CVE-2026-4747, a buffer-overflow flaw in the svc_rpc_gss_validate function of FreeBSD, 17 years old, granting unauthenticated remote root access on any machine exposing NFS. The model also unearthed a 27-year-old bug in OpenBSD. Anthropic claims to have identified thousands of zero-day vulnerabilities across nearly all major operating systems and web browsers, fewer than 1% of which had been patched by their maintainers at the time of the announcement.

The most significant detail is Anthropic's decision not to make Mythos publicly available, which is exceptional for a commercial model. In its place, the company launched Project Glasswing, an initiative endowed with $100 million in usage credits and $4 million in donations to open-source security organizations, aimed at helping defenders prepare for a world in which these capabilities exist. Logan Graham, who leads offensive cybersecurity research at Anthropic, publicly told NBC News he expected comparable capabilities to be widely distributed within six to twelve months, notably via Chinese open-source models. U.S. Treasury Secretary Scott Bessent convened the country's leading financial institutions to discuss the matter.

The most useful analysis for our purposes is not Anthropic's, but that of AISLE, an independent AI security research firm that published a counter-expertise. AISLE took the flagship vulnerabilities Anthropic showcased in its announcement and submitted them to small, cheap open-source models. The result is unequivocal: eight out of eight models detected Anthropic's flagship FreeBSD exploit. A model with only 3.6 billion active parameters, accessible at $0.11 per million tokens, correctly identified the buffer overflow and computed the residual buffer space. A 5.1 billion parameter model reconstructed the exploitation chain of the 27-year-old OpenBSD bug. The conclusion is that these capabilities, far from being the preserve of closed frontier models, are already accessible via open-source models that any actor — state, criminal, or activist — can download and run on their own hardware.

This inversion produces an asymmetry that needs to be named precisely. Linus's law was an assertion of human arithmetic: a sufficient number of human eyeballs eventually sees every bug. But that arithmetic assumed defenders were at least as numerous and motivated as attackers when it came to scrutinizing code. Yet the previous sections have already shown that this assumption no longer holds: Ingress-NGINX, deployed on 40% of the world's Kubernetes clusters, had only two maintainers; XZ Utils, a dependency of 30,000 Debian packages, had only one. On the defenders' side, the arithmetic was already unfavorable.

With Mythos-level agentic AI, the attacker's arithmetic shifts qualitatively. An AI model can exhaustively comb through a codebase of several million lines in minutes, with a persistence and exhaustiveness no human is capable of. Defenders can do the same, in theory — provided they have the resources, expertise, and tools. And, as we have seen, resources are not what characterizes the maintainers of critical libraries. The net result is that code transparency, which was a defensive advantage when only humans were reading code, becomes — in the AI era — a much more useful offensive advantage for anyone with the right tools.

The proof of usage already exists. According to a CNN investigation published in April 2026, citing Amazon Web Services' security research unit, a Russian-speaking cybercriminal jointly used Claude and the Chinese open-source model DeepSeek as early as January 2026 to compromise more than 600 devices protected by a popular firewall product across more than 55 countries. AWS notes that the attacker had limited technical capabilities — AI allowed them to industrialize and scale techniques they could not have mastered alone.

What this new reality adds to the sovereignty debate is crucial. To the four levels of dependency identified in section V — license, governance, hosting, ecosystem — a fifth must now be added: the informational asymmetry between attackers and defenders created by AI. Open-source code, because it is by construction publicly scannable, is the ideal hunting ground for a hostile AI agent. For states and companies that migrated to open source thinking they would gain sovereignty and security through transparency, the risk calculus must be redone. Not in order to conclude that we should return to proprietary software — security through obscurity is, and remains, a chimera. But to recognize that the defensive posture of a state or company resting on critical open source today demands active investment: sustained funding for maintainers, defensive deployment of the same AI capabilities to audit dependencies, drastic acceleration of patch and distribution chains, and the capacity to maintain hardened security forks for the components that truly matter.

Without these investments, open source is no longer a sovereignty strategy: it is an optimal attack surface for a properly equipped adversary.

VIII. Proof by contrast: what China and Russia understood before everyone else

The most powerful argument in favor of this analysis comes, paradoxically, from the most authoritarian regimes. If using Linux and the global open-source ecosystem were enough to guarantee technological sovereignty, China would never have felt the need to invest massively in a parallel infrastructure. Yet it did.

In June 2020, under the auspices of the Ministry of Industry and Information Technology, and with the support of Alibaba, Baidu, Huawei, Inspur, Qihoo 360, and Tencent, the OpenAtom Foundation was created — the first Chinese foundation dedicated to open source, explicitly designed as the national equivalent of the Linux Foundation. It hosts OpenHarmony (the distributed operating system derived from Huawei's HarmonyOS), openEuler (Huawei's Linux distribution used in national power grids), OpenAnolis (Alibaba's distribution that replaced CentOS across much of Chinese industry), as well as projects in EDA (electronic design automation) and the RISC-V architecture — precisely the domains targeted by U.S. export controls.

In parallel, China has developed Gitee, its own code-hosting platform, officially designated as the reference hosting platform for the national community. Gitee has more than 12 million users and hosts the majority of critical Chinese open-source projects.

The Chinese reasoning is clear, and it ought to inspire a sober European reflection: an open-source project is genuinely available only if you simultaneously control the license (first level), the foundation that governs it (second level), the platform that distributes it (third level), and the ecosystem of maintainers that maintains it (fourth level). Below that threshold, the sovereignty being claimed is cosmetic.

Europeans have begun to understand this, but with structural delay. Germany's Sovereign Tech Fund has been funding the security of critical digital infrastructure components since 2022. The NeoNephos initiative, hosted by the Linux Foundation Europe and aligned with an IPCEI-CIS effort estimated at €3.5 billion, aims to build a sovereign European cloud-edge continuum. But these initiatives, salutary as they are, remain embryonic and fragmented compared to the coordinated Chinese effort or the American ecosystem. France, in particular, has an open-source sovereignty policy that is largely declarative, without the structural investment commensurate with what is at stake.

IX. Stepping out of the misunderstanding: toward a clear-eyed sovereignty policy

The point of this article is not to discourage the use of open source. Free software remains, in the vast majority of cases, a better choice than proprietary software for anyone who cares about transparency, auditability, and long-term independence. Giving up open source in favor of American SaaS would be a sovereign suicide.

But we need to step out of a lazy equation that says open source = sovereignty. Open source is a necessary but largely insufficient condition of technological sovereignty. True independence requires structural investment at multiple levels: a maintained capacity to fork, national or European legal foundations, mirrors of packages and containers hosted under one's own jurisdiction, sustained public funding for critical maintainers, a training ecosystem, and above all — the hardest thing to acquire — a critical mass of developers paid to maintain, secure, and evolve the building blocks on which national infrastructure rests.

As long as states and companies confuse the adoption of free software with the conquest of their technological independence, they will continue to expose themselves to a strategy that no longer hides itself: one that turns free into a tool of normative domination. The nuance, here, is not a rhetorical detail. It is the difference between a state that believes itself sovereign and one that actually is.

Sources

Primary documents (official texts and statements)

Geopolitical studies and analyses

On sanctions and U.S. jurisdiction

On the corporate concentration of open source

On the supply chain and XZ Utils

On IngressNightmare and the retirement of Ingress-NGINX

On AI, vulnerability discovery, and the inversion of transparency

On the Chinese strategy and the Asian response

Top comments (0)