SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Family 3 · ~10 min read

Captive distribution chains

Cases that demonstrate that the use of free software does not prevent infrastructure dependency: registries, CDNs and forges are massively concentrated under foreign jurisdiction.

Theses illustrated 06 · 07 · 11

Using free software does not prevent infrastructure dependency. Code transits through forges, binaries are distributed by registries, artefacts are served by CDNs. Yet these infrastructure layers are massively concentrated under foreign jurisdiction, and their past incidents show that they can fail, block or vanish. The cases that follow document this captivity of the chain.

GitHub — The world’s reference forge under Microsoft ownership#

Date of the main event : acquisition June 2018, ongoing operation Status : confirmed, in force Manifesto theses illustrated : 2, 4, 7

The fact#

GitHub is today the world’s dominant code forge, hosting around 90% of open source projects. Acquired by Microsoft in June 2018 for $7.5 billion, it is legally a US company subject to US law, including for its European users. The source code of virtually every open source project worldwide — including Europe’s critical infrastructure bricks — is versioned, shared and collaborated on there.

What it demonstrates#

This concentration creates a structural dependency that exceeds simple tool choice. When the source code of the world’s open ecosystem transits through and is versioned on the infrastructure of a single private American company, it is that company that holds:

  • The contribution metadata (who modifies what, when, from where)
  • Access control over user organisations’ private repositories
  • The application of US sanctions (see family 2)
  • The associated tooling ecosystem: Issues, Pull Requests, Actions (CI/CD), Packages, Copilot

This concentration of essential software-production functions in a foreign jurisdiction is one of the most structuring points of the sovereignty debate.

European alternatives exist — Codeberg (~117,000 projects, a German non-profit), Forgejo (free self-hostable software, a fork of Gitea), and self-hosted GitLab instances operated in Europe — but none approaches GitHub’s contribution mass. Inter-instance federation is still embryonic; the asymmetry of adoption is itself a state of affairs this family documents.

Sources#

npm — The dominant JavaScript registry, owned by Microsoft#

Date : acquisition March 2020 (npm Inc. by GitHub, hence Microsoft) Status : confirmed, in force Manifesto theses illustrated : 2, 7

The fact#

The npm registry is the dominant registry for JavaScript packages consumed worldwide. It has been owned by GitHub, and therefore by Microsoft, since March 2020. More than 3.1 million packages are published on it, downloaded tens of billions of times each month to feed the frontend builds of virtually every modern web and mobile application.

What it demonstrates#

The npm registry is the archetype of an entire programming ecosystem’s single point of failure. Any organisation developing in JavaScript or TypeScript depends, several times a day, on a service operated by a single American company. No European alternative of comparable scale exists. This dependency is invisible — it is hidden in package.json and npm install — but it is universal.

Sources#

  • npm registry : https://www.npmjs.com/
  • Microsoft, press release on the acquisition of npm Inc. by GitHub (March 2020).
  • npm download statistics.

Docker Hub — The container registry without a European alternative#

Date : since 2014 Status : ongoing Manifesto theses illustrated : 2, 7

The fact#

Docker Hub is the reference registry for container images, owned by Docker Inc. (a US company based in Palo Alto). It hosts several million images, downloaded tens of billions of times each month to feed Kubernetes and containerised deployments worldwide. No European equivalent at comparable scale exists to date.

What it demonstrates#

Modern cloud-native orchestration, dominated by Kubernetes (see family 4), mechanically relies on Docker Hub for the distribution of its base images and components. The official images of critical open source projects — Postgres, Redis, Nginx, Node, Python, etc. — are distributed primarily via Docker Hub. European organisations deploying containers consume Docker Hub, even when they use a French or European cloud for execution. The orchestration layer may be sovereign; its supply source is not.

Sources#

PyPI and Maven Central — The captive Python and Java registries#

Date : ongoing Status : confirmed Manifesto theses illustrated : 2, 7

The fact#

PyPI (Python Package Index) is operated by the Python Software Foundation, a US 501(c)(3) non-profit. It is technically hosted on Fastly, a CDN also American. It distributes more than 500,000 Python projects, that is, several million files, downloaded billions of times each month.

Maven Central, the reference registry for Java and JVM-ecosystem packages, is operated by Sonatype, a US company.

What it demonstrates#

The Python and Java ecosystems — used massively by European scientific research, the European financial industry, and enterprise applications — depend entirely on US registries for their daily supply. The Python foundation is legally American, hence subject to US sanctions like the Linux Foundation. Sonatype is a commercial company that may change strategy or shareholder at any time.

Sources#

The left-pad incident — Operational fragility revealed#

Date of the event : 22 March 2016 Status : historical, exemplary Manifesto theses illustrated : 2, 7, 8

The fact#

On 22 March 2016, developer Azer Koçulu pulled 273 packages from npm, including an 11-line micro-package named left-pad, following a dispute with npm Inc. concerning another of his packages (Kik). Although the content of left-pad was trivial — it adds spaces or characters to the left of a string to reach a fixed length — it was used by thousands of dependent packages (notably via Babel, the JavaScript transpiler). Within hours, thousands of builds worldwide failed: CI/CD pipelines blocked, companies could no longer deploy their applications, and the global JavaScript ecosystem wobbled for several hours.

Within ten minutes, another developer, Cameron Westland, republished a functionally identical 1.0.0 version. But because many dependency chains explicitly required version 0.0.3 of the package, the errors continued. npm Inc. then unilaterally decided to restore the original 0.0.3 version under the authority of a new maintainer, without the original author’s consent — which in turn sparked controversy over software ownership and freedom. Following the incident, npm changed its policy: a package can no longer be unpublished after 24 hours if it has at least one dependency.

What it demonstrates#

The left-pad incident is one of the most pedagogical textbook cases of the modern software supply chain’s fragility. It shows simultaneously:

  1. The opacity of dependencies. No one knew, before the incident, how much the JavaScript ecosystem depended on an 11-line package. This is a proxy for the general invisibility of transitive dependencies.
  2. The unilateral power of the registry. npm Inc. was able to restore a package against its author’s will. This shows that registry control prevails over individual intellectual property.
  3. The absence of any continuity plan. No user organisation had a local mirror or fallback strategy. The disruption was immediate and unrecoverable without npm’s intervention.

Sources#

  • The Register (March 2016), How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript : https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
  • Azer Koçulu, personal post, I’ve Just Liberated My Modules (March 2016).
  • David Haney, NPM & left-pad: Have We Forgotten How To Program?

OpenShift — A Red Hat product redistributed as sovereign infrastructure#

Date of the event : product launched 2011; analysis as of April 2026 Status : ongoing Manifesto theses illustrated : 5, 6, 7, 12

The fact#

OpenShift Container Platform is a proprietary Red Hat product, an IBM subsidiary since the July 2019 acquisition ($35 billion). This is an important legal and industrial point: OpenShift is not a project under open governance, it is not a CNCF project, it is not a foundation.

OpenShift is built on open source components — primarily Kubernetes, but also many other CNCF projects — to which Red Hat adds an integration layer, development tools (OpenShift Developer Tools), specific Kubernetes operators, security components (Red Hat Advanced Cluster Security, formerly StackRox), and an enterprise support cycle. This integration layer is under Red Hat’s exclusive control. OpenShift’s roadmap, support calendar, pricing policy, licence conditions, and third-party integration choices are arbitrated at Red Hat headquarters in Raleigh (North Carolina) and ultimately at IBM headquarters in Armonk (New York).

A part of OpenShift is published as open source under the name OKD (Origin Community Distribution of Kubernetes), but OKD is not equivalent to OpenShift Container Platform: the gap concerns precisely the enterprise components that constitute the product’s value. Building one’s PaaS offer on OKD does not provide access to the integrated functions that justify a sovereign qualification — that is precisely the product’s commercial proposition.

Three structuring players in the French SecNumCloud landscape explicitly rely on OpenShift in their PaaS offer:

  • Cloud Temple. In June 2023, Cloud Temple announced a PaaS offer based on Red Hat OpenShift, on its SecNumCloud-qualified cloud (since 2022). Cloud Temple obtained SecNumCloud qualification for its OpenShift PaaS in May 2024, becoming the first French operator to obtain this qualification on this stack. The development of this offer benefited from Bpifrance support under the SecNumCloud qualification assistance scheme.

  • NumSpot. A consortium founded in 2023 by Banque des Territoires (36%), Docaposte (26%), Dassault Systèmes (19%) and Bouygues Telecom (19%), NumSpot has made the Red Hat OpenShift managed service one of the founding bricks of its offer. Its CTO Éric Fredj told MagIT in October 2024: “We have a number of prospects, particularly within ministries, who have invested in OpenShift and want to find that ecosystem offering added value above a Kubernetes cluster.” NumSpot filed its SecNumCloud qualification dossier in September 2024 and is targeting qualification in H1 2026, which would cover the full stack including managed OpenShift.

  • S3NS. A Thales–Google Cloud joint venture, S3NS obtained its SecNumCloud 3.2 qualification on 17 December 2025, covering IaaS, PaaS and CaaS in a single decision — the first ANSSI decision to cover these three levels together. The S3NS container layer relies on Google Kubernetes Engine (GKE) in autopilot mode, with Kubernetes versions 1.28 to 1.34. This is technically different from OpenShift, but the redistribution pattern is analogous: a French SecNumCloud-qualified provider distributes, under a sovereign label, a managed Kubernetes distribution whose roadmap is arbitrated in Mountain View.

The director general of ANSSI, Vincent Strubel, told the Senate commission of inquiry on public procurement on 28 May 2025 that the Bleu (Microsoft) and S3NS (Google) arrangements are “compliant, on paper, with SecNumCloud requirements” and that, according to the legal analyses commissioned by ANSSI, they are “in principle immune to the Cloud Act and the FISA Act.” This protection is real: it concerns the inaccessibility of data and operations to extraterritorial US requests, which is the primary objective of the framework.

What it demonstrates#

This protection does not, however, cover unilateral decisions that Red Hat-IBM might take on OpenShift, or Google on GKE, in their role as producer of the brick. If Red Hat decided tomorrow to alter OpenShift’s licence conditions (as it did in June 2023 on RHEL sources — see family 1), to remove certain third-party operators, to drop support for certain configurations, or to change pricing policy, the SecNumCloud providers distributing OpenShift would be in the same position as the CentOS distributors of June 2023: informed at the same time as their customers, with no recourse.

This dimension is, by construction, outside the current SecNumCloud framework’s perimeter. The framework verifies sovereign operation, not the sovereignty of the brick’s producer. This is consistent with its mandate. But it is a dimension that public buyers interpreting SecNumCloud as an end-to-end sovereignty guarantee should explicitly address, either by additional requirements in tenders (technological continuity plan in case of producer flip), or by requesting a detailed Sovereignty Profile on the provider’s contributive status.

Note: what this analysis is not. This case is not a critique of the named providers (Cloud Temple, NumSpot, S3NS), who do real and documented qualification, operation and security work. Nor is it a critique of the SecNumCloud framework, which rigorously covers what it claims to cover. It is a structural observation about a dimension not covered: the technological independence of redistributed bricks, distinct from the operational independence the framework verifies. Public and private buyers who understand this distinction are better equipped to decide with eyes open; those who ignore it risk taking commitments they will not be able to honour if the brick’s producer unilaterally changes the rules.

This dissociation between operational independence and technological independence is precisely what the new cross-cutting section of the inventory of gaps (“The distributor syndrome”) operationalises, and what the Sovereignty Profile format proposes to make publicly readable.

Sources#

→ Related operational commitments#

Infrastructure captivity is not solved by licence choice: it is solved by hosting, forge and distribution choices, and by the requirement of visibility over the actual chain.

Full catalogue of commitments →

Read the manifesto →