This volume builds a three-stage chain: first, why a licence protects a right to read but never hardware control (Act I); then, six concrete and distinct mechanisms by which capture actually operates, from a documented licence change to the phantom contribution that quietly steers a project toward a single type of hardware (Act II); finally, a reconquest architecture built on levers directly correlated to each pillar — neutral governance, a ban on emulation, blackholing of telemetry — before establishing the explicit link with the hardware sovereignty demonstrated elsewhere in this collection (Act III).

An open source licence guarantees one right: to read, modify, and redistribute source code. It guarantees no control over the physical infrastructure that runs it at scale. This distinction, rarely stated explicitly, produces a simple mathematical consequence: a community project whose usage value is expressed only in production, on machines it does not own, structurally becomes free raw material for whoever owns those machines in sufficient quantity.

Four public and documented licence changes introduce what this volume calls the mechanics of expropriation, before three distinct pillars each detail one precise mechanism: capture by interface, capture by usage, and capture from within the code itself.

In January 2021, Elastic switched Elasticsearch and Kibana from the Apache 2.0 licence to the Server Side Public Licence (SSPL), explicitly citing AWS's exploitation of the project via a competing managed service without proportional contribution back. MongoDB had made the same decision as early as 2018, itself introducing the SSPL licence for the same stated reason. HashiCorp switched Terraform and its other products from the Mozilla Public Licence to the Business Source Licence (BSL) in 2023. Redis did the same for its engine in 2024. In all four cases, the company behind the project publicly documents the same justification: a cloud provider exploits the project at a scale that generates significant rental value, without that value financing the maintenance of the commons in return.

A cloud provider can respond to a restrictive licence change in two technically distinct ways, which must never be conflated. Amazon OpenSearch is a fork in the strict sense: a copy of the Elasticsearch codebase predating the licence change, maintained and developed independently — the capture here concerns the source code itself, at a given point in time. Amazon DocumentDB is of a different nature: an emulation of MongoDB's network protocol (wire protocol), compatible with its drivers and commands, but resting on a distinct proprietary storage engine, sharing no line of MongoDB code. The capture then no longer concerns the code, but the developer's gesture, who continues to communicate in the same command language.

An open source project progresses partly through signals fed back by its real-world use in production: which code paths fail most often, which configurations degrade performance, which load volumes reveal limits unanticipated in the lab. A cloud provider hosting millions of managed instances of the same project accumulates this kind of signal at a scale no independent maintainer can reproduce on their own.

An organisation can scrupulously apply the measure documented in III.2 of this volume — refusing any managed emulation service, deploying a genuine open source engine (PostgreSQL, Kubernetes) on infrastructure it controls. A distinct capture mechanism nonetheless operates, at a different layer: that of identity and encryption.

Major cloud providers rank among the most active contributors to many leading open source projects, measured by commit volume. This volume of contribution is a public fact, verifiable in these projects' Git history. This pillar documents a specific subset of these contributions: those which, under cover of performance optimisation, introduce a functional dependency on a hardware or software component proprietary to the contributor.

Each pillar of Act II calls for a response of a different nature. Neutral governance answers the risk of licence change documented in the introduction to Act II — it answers neither capture by interface (Pillar A) nor telemetry asymmetry (Pillar B). This part adds the two missing architectural and material levers, before establishing the link with hardware sovereignty demonstrated elsewhere in this collection.

A project governed by a single commercial company presents a simple exposure structure: that company alone holds the power to change the licence under the pressure documented in the introduction to Act II. A project transferred to a neutral foundation — on the model of the Apache Software Foundation or the Cloud Native Computing Foundation — distributes this power among several member organisations, making a unilateral licence change more difficult.

Facing the capture by emulation documented in Pillar A, an organisation can act directly on its own architecture standards, without waiting for any change in the market or in regulation.

Facing the telemetry asymmetry documented in Pillar B, an organisation can act on its own outbound network flows, independently of any change on the managed service provider's side.

Another volume in this collection, The Cloud Illusion, demonstrated that no digital sovereignty is possible without mastery of the underlying hardware. This volume establishes the logical corollary for free software: code under a licence protected by the most neutral governance possible, run exclusively via managed services from the same actor whose capture mechanisms this volume documents, remains vulnerable to Pillars A and B — however solid its licence governance may be.

A commons without defence is not a commons protected by law. It is a free resource awaiting an operator large enough to harvest it at industrial scale.