SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Family 2 · ~10 min read

Foundations under foreign jurisdiction

Cases that demonstrate that the governance of an open source project is legally anchored in the jurisdiction of the foundation hosting it.

Theses illustrated 04 · 07

The open source projects most structuring for the world’s digital infrastructure are coordinated by foundations whose jurisdiction is neither neutral nor theoretical. That jurisdiction applies in fact, and its effects are documented. The cases that follow show that foundation “neutrality” is a legal convention, not operational independence.

Linux Foundation — The removal of Russian maintainers (October 2024)#

Date of the main event : October 2024 Status : confirmed Manifesto theses illustrated : 4, 5, 7, 11

The fact#

On 18 October 2024, the Linux project removed 11 Russian maintainers from the kernel’s MAINTAINERS file, in line with a legal opinion from Linux Foundation lawyers, in application of US Office of Foreign Assets Control (OFAC) sanctions related to the invasion of Ukraine. The maintainers concerned worked on drivers for Baikal processors and for Acer or Cirrus hardware. Linus Torvalds confirmed the decision on the kernel mailing list, citing “compliance requirements”.

The decisive argument was put forward by the Software Freedom Conservancy, an organisation otherwise committed to software freedom: the open source community cannot operate independently of international sanctions programmes, because those sanctions are the law of the country where the foundation is based. The Linux Foundation is a US non-profit organisation, fiscally registered in the United States. Linus Torvalds and Greg Kroah-Hartman, two key kernel figures, operate from US territory. The code is open, but the institution coordinating it is not.

What it demonstrates#

This case is probably the most important documented to date for the open source sovereignty debate. It concretely proves that:

  1. A US foundation can, in practice, apply US foreign policy to projects used worldwide, even when the strict legal obligation is contested. Maintainer Felipe Contreras and the Software Freedom Conservancy publicly argued that the decision was not formally required by OFAC sanctions — approving a patch is not obviously a “transaction” within the meaning of sanctions, and OFAC’s exact reach over unpaid contributions remains legally open. The Linux Foundation nevertheless chose to comply pre-emptively, on the advice of its own lawyers. For the sovereignty debate, that is precisely what counts: a legally cautious posture, exercised by a US entity, suffices to exclude foreign contributors, regardless of whether the underlying obligation is binding (thesis 4).
  2. An open source project whose coordination is centralised in a foreign jurisdiction is subject to that jurisdiction’s trade-offs, regardless of the code’s licence (thesis 7). The code stays open, the project is not closed — but who can actively contribute, who appears on the official maintainers list, depends on legal decisions made by the host entity.
  3. The “chilling effect” — pre-emptive self-compliance — is just as effective as a formal legal obligation. Whether the decision is legally compulsory or merely defensive, its practical effect is the same.

For anyone depending on software coordinated from the United States, the conclusion is plain: their software supply is subject to decisions made under the pressure of Washington’s foreign policy.

Sources#

GitHub — Account blocks in sanctioned zones (July 2019)#

Date of the main event : July 2019 Status : confirmed, in force Manifesto theses illustrated : 4, 7

The fact#

Following the application of US sanctions, in July 2019 GitHub blocked access for developers resident in Iran, Syria, Crimea, Cuba and North Korea to several paid services. Concretely, those users lost access to their private repositories and paid accounts (GitHub Marketplace, private organisations); public repositories remained accessible. An Iranian developer, Hamed Saeedi Fard, recounted losing access to his own private repositories without notice or backup option. The CEO at the time, Nat Friedman, publicly justified the decision: GitHub is subject to US commercial law, like any company operating in the United States. The use of VPNs to circumvent the measure is explicitly prohibited by the platform’s terms of service.

What it demonstrates#

This case predates the Linux Foundation case by five years, and it sets the precedent that makes the latter foreseeable. The world’s reference forge for source code — used by virtually every open source project — unilaterally applies US sanctions, including on private code its users believed was theirs. For a developer resident in a sanctioned country, accumulated work becomes inaccessible overnight. For European organisations hosting their code on GitHub, it is the concrete reminder that their repository is subject to the same rules.

Forges that do not depend on US jurisdiction exist: Codeberg (a German non-profit, hosting roughly 117,000 projects), Forgejo (free self-hostable software stemming from a fork of Gitea), and any GitLab instance self-hosted on European infrastructure. None has GitHub’s critical mass; none either applies US sanctions. For a European project that wants to avoid the precedent described here, these alternatives exist and are functional, even if the network effect remains to be built.

Sources#

Apache Software Foundation — A US foundation over ~350 projects#

Date : founded 1999 Status : ongoing Manifesto theses illustrated : 4, 6

The fact#

The Apache Software Foundation (ASF) is a US 501(c)(3) non-profit organisation, legally incorporated in Delaware. It hosts approximately 350 projects, including several critical bricks of the world’s infrastructure: Kafka (data streaming), Spark (distributed computing), Cassandra (distributed database), Tomcat (Java server), Hadoop (big data), Airflow (task orchestration). These projects are used massively across Europe.

What it demonstrates#

The ASF is a textbook example of a foundation perceived as “neutral and international” when it is legally American. Its governance, its contribution rules (Contributor License Agreement), its intellectual property all fall under US law. The obligations applying to any US 501(c)(3) organisation apply to the ASF, and the practical reach of those obligations depends on how the geopolitical context evolves — as the Linux Foundation case showed in 2024.

Sources#

Cloud Native Computing Foundation (CNCF) — The cloud-native arm of the Linux Foundation#

Date : announced June 2015, formalised December 2015 Status : ongoing Manifesto theses illustrated : 4, 5

The fact#

The Cloud Native Computing Foundation (CNCF) is a sub-foundation of the Linux Foundation, announced on 21 June 2015 and formalised in December 2015, to host Kubernetes after Google’s donation. It hosts today over two hundred projects at various stages of maturity (graduated, incubating, sandbox), most of the modern cloud-native ecosystem: Kubernetes, Prometheus, Envoy, Istio, OpenTelemetry, Helm, etcd, containerd, Argo. Its technical governance is dominated by “platinum” sponsors, who are overwhelmingly American: Google, Microsoft, AWS, IBM, Intel, Cisco, Oracle.

To ensure Kubernetes’s takeoff, in August 2018 Google contributed to the CNCF a grant of $9 million in cloud credits intended to fund the testing and distribution infrastructure. At the time of the donation, more than half of Fortune 100 companies were already using Kubernetes for their containers.

What it demonstrates#

The CNCF is the textbook case of normative capture by standardisation. Google turned its internal architecture (Borg) into a universal grammar: any system that wants to interact with the modern cloud now speaks Kubernetes. AWS, Microsoft Azure and Google Cloud built managed services (EKS, AKS, GKE) on this foundation; three American companies now monetise global orchestration. Any subsequent cloud-native innovation (service mesh, observability, progressive delivery) must fit the conceptual mould of Kubernetes, on pain of non-adoption.

This mechanism directly illustrates thesis 12: European providers distributing managed Kubernetes do not create sovereignty; they join a grammar whose definition lies beyond their reach.

Sources#

Kubernetes — CNCF governance and the European contribution deficit#

Date : project donated to the CNCF in March 2016; analysis as of April 2026 Status : ongoing Manifesto theses illustrated : 4, 5, 6, 8, 12

The fact#

Kubernetes is governed by the Cloud Native Computing Foundation (CNCF), created in 2015 and hosted by the Linux Foundation, a US non-profit registered in Delaware. The project was originally developed by Google from Borg, Google’s internal orchestration system, then donated to the CNCF in 2016 to neutralise the asymmetry of influence and ease adoption by Google’s competitors.

The technical governance of Kubernetes is organised around several bodies:

  • The Steering Committee, which arbitrates strategic decisions cross-cutting the project.
  • About thirty Special Interest Groups (SIGs), each responsible for a technical area: SIG Architecture, SIG Auth, SIG Network, SIG Node, SIG Storage, SIG Security, SIG Release, SIG API Machinery.
  • Several cross-cutting Working Groups on emerging topics.
  • The role of TOC (Technical Oversight Committee) at CNCF level, overseeing admission, graduation, and de-prioritisation of foundation projects.

Admission to these bodies follows a process based on demonstrated and sustained contribution. Contributors become reviewers, reviewers become approvers, approvers become maintainers, maintainers may sit on SIGs and the Steering Committee. Without substantial upstream contribution, no company can claim a seat on these bodies.

According to the public Kubernetes Project Journey Report published by the CNCF, Google and Red Hat (IBM since 2019) accounted for 83% of contributions to the project before its entry to the CNCF in 2016. At the time of that report’s writing in 2023, these two companies still accounted for 46% of cumulative contributions, despite genuine diversification. Diversification has occurred mostly toward other US companies: Microsoft, Amazon, Intel, VMware (before its acquisition by Broadcom), and more marginally toward diversified corporate contributors.

Public statistics available at k8s.devstats.cncf.io confirm the persistence of this North American concentration. No European company appears in the top 10 corporate contributors to Kubernetes. SUSE (Luxembourg-based since November 2023, controlled by EQT, a Swedish fund) contributes, but at levels an order of magnitude below those of Google or Red Hat. Canonical (Ubuntu) also contributes, with a focus oriented more toward integration than the core. Mirantis (Russian-origin, now an American company) contributes substantially after its acquisition of the Docker Enterprise teams. No French company figures among the structural contributors to the project.

On the individual side, European contributors do exist — the Cloud Native Community Europe is active, KubeCon Europe attracts several thousand attendees each year — but their contribution is largely individual or carried by the European subsidiaries of US companies (Google Munich, Microsoft Berlin, Red Hat Brno) rather than by European companies employing those contributors.

What it demonstrates#

This distribution has mechanical consequences that any European provider distributing Kubernetes or its derivatives should document in their Sovereignty Profile:

  1. Security embargoes. When a critical CVE is discovered on Kubernetes, the embargo processes (which determine who learns of the vulnerability before the public, and therefore who can prepare patches before disclosure) favour major contributors to the project. Providers without full-time employees assigned to Kubernetes learn of the CVE at the same time as their customers.

  2. Roadmap trade-offs. Kubernetes evolutions — new APIs, deprecation of existing APIs, architectural choices, privileged integrations with one third-party component or another — are arbitrated within the SIGs. Without a presence in those SIGs, a provider absorbs these choices without being able to influence them.

  3. Compatibility. When an API change breaks compatibility with an earlier version (which happens regularly, Kubernetes having a fast release cycle), a provider not in the loop learns of the change through the release notes and must absorb the migration cost without notice.

  4. Licence and governance decisions. Although Kubernetes is under Apache 2.0 and the CNCF has a neutrality mandate, the experience of other open source projects shows that governance decisions (relicensing, fork, structural change) remain possible and may be decided by actors who do not represent the European ecosystem.

No SecNumCloud-qualified or in-qualification French provider (Outscale, OVHcloud, Cloud Temple, Worldline, Orange Business, S3NS, Bleu, NumSpot) has, as of April 2026, a significant presence on the Steering Committee or in the critical Kubernetes SIGs (SIG Architecture, SIG Auth, SIG Security, SIG Release). This does not mean those providers are not legitimate — their qualification, operation and compliance work is real. But it does mean that, at the container layer, they are in a structural distributor position, and their Sovereignty Profiles should make this explicit.

For the quantified figures of corporate contributions to Kubernetes, see family 4. For application to the OpenShift case and SecNumCloud providers, see family 3.

Sources#

→ Related operational commitments#

Faced with the jurisdictional anchoring of dominant foundations, the device proposes several concrete commitments to develop, support and prefer alternatives under European or neutral governance.

Full catalogue of commitments →

Read the manifesto →