SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Famille 2 · ~11 min de lecture

Les fondations sous juridiction étrangère

Cas qui démontrent que la gouvernance d'un projet open source est juridiquement ancrée dans la juridiction de la fondation qui l'héberge.

Thèses illustrées 04 · 07

Les projets open source les plus structurants pour l’infrastructure numérique mondiale sont coordonnés par des fondations dont la juridiction n’est ni neutre ni théorique. Cette juridiction s’applique réellement, et ses effets sont documentés. Les cas qui suivent montrent que la « neutralité » des fondations est une convention juridique, pas une indépendance opérationnelle.

Linux Foundation — Le retrait des mainteneurs russes (octobre 2024)#

Date du fait principal : octobre 2024 Statut : confirmé Thèses du manifeste illustrées : 4, 5, 7, 11

Le fait#

Le 18 octobre 2024, le projet Linux retire 11 mainteneurs russes du fichier MAINTAINERS du noyau, conformément à un avis juridique des avocats de la Linux Foundation, en application des sanctions du Bureau du contrôle des avoirs étrangers américain (OFAC) liées à l’invasion de l’Ukraine. Les mainteneurs concernés travaillaient sur des pilotes pour les processeurs Baikal et pour du matériel d’Acer ou de Cirrus. Linus Torvalds confirme la décision sur la liste de diffusion du noyau, en invoquant des « exigences de conformité ».

Le contexte juridique#

L’argument décisif est formulé par la Software Freedom Conservancy, organisation pourtant attachée à la liberté logicielle : la communauté open source ne peut pas opérer indépendamment des programmes de sanctions internationaux, parce que ces sanctions sont la loi du pays où la fondation est domiciliée. La Linux Foundation est une organisation à but non lucratif américaine, fiscalement enregistrée aux États-Unis. Linus Torvalds et Greg Kroah-Hartman, deux figures clés du noyau, opèrent depuis le territoire américain. Le code est ouvert, mais l’institution qui le coordonne ne l’est pas.

Ce qu’il démontre#

Ce cas est probablement le plus important documenté à ce jour pour le débat sur la souveraineté open source. Il prouve concrètement que :

  1. Une fondation américaine peut, en pratique, appliquer la politique étrangère américaine à des projets utilisés dans le monde entier, même quand l’obligation juridique stricte est contestée. Le mainteneur Felipe Contreras et la Software Freedom Conservancy ont publiquement argumenté que la décision n’était pas formellement requise par les sanctions OFAC — approuver un patch n’est pas évidemment une « transaction » au sens des sanctions, et la portée exacte de l’OFAC sur des contributions non rémunérées reste juridiquement ouverte. La Linux Foundation a néanmoins choisi de se conformer préventivement, sur conseil de ses propres avocats. Pour le débat sur la souveraineté, ce qui compte, c’est précisément cela : la posture juridique de prudence, exercée par une entité américaine, suffit à exclure des contributeurs étrangers, indépendamment du caractère contraignant ou non de l’obligation sous-jacente (thèse 4).
  2. Un projet open source dont la coordination est centralisée dans une juridiction étrangère subit les arbitrages de cette juridiction, indépendamment de la licence du code (thèse 7). Le code reste ouvert, le projet n’est pas fermé — mais qui peut y contribuer activement, qui figure sur la liste des mainteneurs officiels, dépend des décisions juridiques prises par l’entité-hôte.
  3. Le « chilling effect » — l’autoconformité préventive — est tout aussi efficace qu’une obligation légale formelle. Que la décision soit juridiquement obligatoire ou seulement défensive, son effet pratique est le même.

Pour quiconque dépend de logiciels coordonnés depuis les États-Unis, la conclusion est limpide : son approvisionnement logiciel est soumis aux décisions prises sous la pression de la politique étrangère de Washington.

Sources#

GitHub — Le blocage des comptes en zones sanctionnées (juillet 2019)#

Date du fait principal : juillet 2019 Statut : confirmé, en vigueur Thèses du manifeste illustrées : 4, 7

Le fait#

Suite à l’application des sanctions américaines, GitHub bloque en juillet 2019 l’accès des développeurs résidant en Iran, en Syrie, en Crimée, à Cuba et en Corée du Nord à plusieurs services payants. Concrètement, ces utilisateurs perdent l’accès à leurs dépôts privés et aux comptes payants (GitHub Marketplace, organisations privées) ; les dépôts publics restent accessibles. Un développeur iranien, Hamed Saeedi Fard, raconte avoir perdu l’accès à ses propres dépôts privés sans préavis ni possibilité de sauvegarde. Le CEO de l’époque, Nat Friedman, justifie publiquement la décision : GitHub est soumis au droit commercial américain, comme toute entreprise opérant aux États-Unis. L’utilisation de VPN pour contourner la mesure est explicitement interdite par les conditions d’utilisation de la plateforme.

Ce qu’il démontre#

Ce cas est antérieur de cinq ans à celui de la Linux Foundation, et il donne le précédent qui rend le second prévisible. La forge de référence mondiale pour le code source — utilisée par la quasi-totalité des projets open source — applique unilatéralement les sanctions américaines, y compris sur du code privé que ses utilisateurs croyaient leur appartenir. Pour un développeur résident dans un pays sanctionné, son travail accumulé devient inaccessible du jour au lendemain. Pour les organisations européennes qui hébergent leur code sur GitHub, c’est le rappel concret que leur dépôt est soumis aux mêmes règles.

Des forges qui ne dépendent pas de la juridiction américaine existent : Codeberg (association allemande, héberge environ 117 000 projets), Forgejo (logiciel libre auto-hébergeable issu d’un fork de Gitea), et toute instance GitLab self-hosted sur infrastructure européenne. Aucune n’a la masse critique de GitHub ; aucune n’applique non plus les sanctions américaines. Pour un projet européen qui veut éviter le précédent décrit ici, ces alternatives existent et sont fonctionnelles, même si l’effet réseau reste à construire.

Sources#

Apache Software Foundation — Une fondation américaine sur ~350 projets#

Date : fondation 1999 Statut : continu Thèses du manifeste illustrées : 4, 6

Le fait#

L’Apache Software Foundation (ASF) est une organisation à but non lucratif 501(c)(3) américaine, constituée juridiquement dans le Delaware. Elle héberge environ 350 projets, dont plusieurs briques critiques de l’infrastructure mondiale : Kafka (streaming de données), Spark (calcul distribué), Cassandra (base de données distribuée), Tomcat (serveur Java), Hadoop (big data), Airflow (orchestration de tâches). Ces projets sont utilisés massivement dans toute l’Europe.

Ce qu’il démontre#

L’ASF est un exemple type de la fondation perçue comme « neutre et internationale » alors qu’elle est juridiquement américaine. Sa gouvernance, ses règles de contribution (Contributor License Agreement), sa propriété intellectuelle relèvent du droit américain. Les obligations qui s’appliquent à toute organisation 501(c)(3) américaine s’appliquent à l’ASF, et la portée pratique de ces obligations dépend de l’évolution du contexte géopolitique — comme l’a montré le cas de la Linux Foundation en 2024.

Sources#

Cloud Native Computing Foundation (CNCF) — Le bras cloud-native de la Linux Foundation#

Date : annonce juin 2015, formalisation décembre 2015 Statut : continu Thèses du manifeste illustrées : 4, 5

Le fait#

La Cloud Native Computing Foundation (CNCF) est une sous-fondation de la Linux Foundation, annoncée le 21 juin 2015 et formalisée en décembre 2015, pour héberger Kubernetes après son don par Google. Elle abrite aujourd’hui plus de deux cents projets à divers stades de maturité (graduated, incubating, sandbox), dont la majorité de l’écosystème cloud-native moderne : Kubernetes, Prometheus, Envoy, Istio, OpenTelemetry, Helm, etcd, containerd, Argo. Sa gouvernance technique est dominée par les sponsors « platinum », qui sont massivement américains : Google, Microsoft, AWS, IBM, Intel, Cisco, Oracle.

Pour assurer le décollage de Kubernetes, Google a versé à la CNCF en août 2018 une subvention de 9 millions de dollars en crédits cloud destinée à financer l’infrastructure de tests et de distribution. Au moment du don, plus de la moitié des entreprises du Fortune 100 utilisaient déjà Kubernetes pour leurs conteneurs.

Ce qu’il démontre#

La CNCF est le cas-type de la capture normative par standardisation. Google a transformé son architecture interne (Borg) en grammaire universelle : tout système qui veut interagir avec le cloud moderne parle désormais Kubernetes. AWS, Microsoft Azure et Google Cloud ont construit des services managés (EKS, AKS, GKE) sur ce socle ; trois entreprises américaines monétisent désormais l’orchestration mondiale. Toute innovation cloud-native ultérieure (service mesh, observabilité, déploiement progressif) doit s’inscrire dans le moule conceptuel de Kubernetes, sous peine d’inadoption.

Cette mécanique illustre directement la thèse 12 : les fournisseurs européens qui distribuent du Kubernetes managé ne créent pas de souveraineté ; ils rejoignent une grammaire dont la définition leur échappe.

Sources#

Kubernetes — La gouvernance CNCF et le déficit européen contributif#

Date : projet donné à la CNCF en mars 2016 ; analyse à avril 2026 Statut : continu Thèses du manifeste illustrées : 4, 5, 6, 8, 12

Le fait#

Kubernetes est gouverné par la Cloud Native Computing Foundation (CNCF), créée en 2015 et hébergée par la Linux Foundation, organisation à but non lucratif de droit américain enregistrée dans l’État du Delaware. Le projet a été initialement développé par Google à partir de Borg, le système d’orchestration interne de Google, puis donné à la CNCF en 2016 pour neutraliser l’asymétrie d’influence et faciliter l’adoption par les concurrents de Google.

La gouvernance technique de Kubernetes s’organise autour de plusieurs instances :

  • Le Steering Committee, qui arbitre les décisions stratégiques transverses au projet.
  • Une trentaine de Special Interest Groups (SIGs), chacun responsable d’un domaine technique : SIG Architecture, SIG Auth, SIG Network, SIG Node, SIG Storage, SIG Security, SIG Release, SIG API Machinery.
  • Plusieurs Working Groups transverses sur des sujets émergents.
  • Le rôle de TOC (Technical Oversight Committee) au niveau de la CNCF, qui supervise l’admission, la graduation et la dépriorisation des projets de la fondation.

L’admission à ces instances passe par un mode opératoire fondé sur la contribution démontrée et soutenue. Les contributors deviennent reviewers, les reviewers deviennent approvers, les approvers deviennent maintainers, les maintainers peuvent siéger dans les SIGs et au Steering Committee. Sans contribution upstream substantielle, aucune entreprise ne peut prétendre à un siège dans ces instances.

Selon le rapport public Kubernetes Project Journey Report publié par la CNCF, Google et Red Hat (IBM depuis 2019) totalisaient 83 % des contributions au projet avant son entrée à la CNCF en 2016. Au moment de la rédaction de ce rapport en 2023, ces deux entreprises représentaient encore 46 % des contributions cumulées, malgré une diversification réelle. La diversification s’est faite principalement vers d’autres entreprises américaines : Microsoft, Amazon, Intel, VMware (avant le rachat par Broadcom), et plus marginalement vers des contributeurs corporate diversifiés.

Les statistiques publiques disponibles sur k8s.devstats.cncf.io confirment la persistance de cette concentration nord-américaine. Aucune entreprise européenne n’apparaît dans le top 10 des contributeurs corporate à Kubernetes. SUSE (luxembourgeoise depuis novembre 2023, contrôlée par EQT, fonds suédois) contribue, mais à des niveaux qui restent d’un ordre de grandeur inférieur à ceux de Google ou Red Hat. Canonical (Ubuntu) contribue également mais avec un focus plus orienté sur l’intégration que sur le cœur. Mirantis (origine russe, désormais société américaine) contribue substantiellement après son rachat des équipes Docker Enterprise. Aucune entreprise française ne figure dans les contributeurs structurels au projet.

Côté individus, les contributeurs européens existent — la communauté Cloud Native Community Europe est active, KubeCon Europe attire chaque année plusieurs milliers de participants — mais leur contribution est largement individuelle ou portée par les filiales européennes d’entreprises américaines (Google Munich, Microsoft Berlin, Red Hat Brno) plutôt que par des entreprises européennes employant ces contributeurs.

Ce qu’il démontre#

Cette répartition a des conséquences mécaniques que tout fournisseur européen distribuant Kubernetes ou ses dérivés devrait documenter dans son Profil de souveraineté :

  1. Embargos de sécurité. Quand une CVE critique est découverte sur Kubernetes, les processus d’embargo (qui définissent qui apprend la vulnérabilité avant le grand public, et donc qui peut préparer les correctifs avant la divulgation) privilégient les contributeurs majeurs au projet. Les fournisseurs qui n’ont pas d’employés affectés à plein temps à Kubernetes apprennent la CVE en même temps que leurs clients.

  2. Arbitrages de roadmap. Les évolutions de Kubernetes — nouvelles APIs, dépréciation d’APIs existantes, choix d’architecture, intégrations privilégiées avec tel ou tel composant tiers — sont arbitrées dans les SIGs. Sans présence dans ces SIGs, un fournisseur subit ces choix sans pouvoir les influencer.

  3. Compatibilité. Quand un changement d’API casse la compatibilité avec une version antérieure (ce qui arrive régulièrement, Kubernetes ayant un cycle de release rapide), le fournisseur qui n’est pas dans la boucle apprend le changement par les release notes et doit absorber le coût de migration sans préavis.

  4. Décisions de licence et de gouvernance. Bien que Kubernetes soit sous licence Apache 2.0 et que la CNCF ait un mandat de neutralité, l’expérience des autres projets open source montre que les décisions de gouvernance (relicensing, fork, changement de structure) restent possibles et peuvent être décidées par des acteurs qui ne représentent pas l’écosystème européen.

Aucun fournisseur français qualifié SecNumCloud ou en cours de qualification (Outscale, OVHcloud, Cloud Temple, Worldline, Orange Business, S3NS, Bleu, NumSpot) n’a, à la date d’avril 2026, de présence significative dans le Steering Committee ou dans les SIGs critiques de Kubernetes (SIG Architecture, SIG Auth, SIG Security, SIG Release). Cela ne signifie pas que ces fournisseurs ne sont pas légitimes — leur travail de qualification, d’opération et de mise en conformité est réel. Mais cela signifie qu’ils sont, sur la couche conteneurs, dans une position structurelle de distributeur, et que leurs Profils de souveraineté devraient l’expliciter.

Pour la quantification chiffrée des contributions corporate à Kubernetes, voir famille 4. Pour l’application au cas OpenShift et aux fournisseurs SecNumCloud, voir famille 3.

Sources#

→ Engagements opérationnels associés#

Face à l’ancrage juridictionnel des fondations dominantes, le dispositif propose plusieurs engagements concrets pour développer, soutenir et préférer les alternatives sous gouvernance européenne ou neutre.

Catalogue complet des engagements →

Lire le manifeste →