The Enclosure of the Commons: How License Wars and the CRA Are Rewriting Open Source's Social Contract

The Enclosure Precedent

Between the 16th and 19th centuries, the English commons — shared grazing land, forests, and waterways that had sustained rural communities for centuries — were systematically converted to private property through a series of Parliamentary acts. The enclosure movement did not destroy agriculture; it transformed it. But it did destroy a specific social contract: the understanding that certain resources were held in common and could not be unilaterally privatised by their stewards. The displaced rural poor became the industrial workforce, and the commons became estates.

The open-source ecosystem is living through its own enclosure moment, but in reverse. For two decades, the social contract was clear: corporations could build on open-source infrastructure, contribute back when convenient, and extract value without owing the commons. That contract is now being rewritten from both directions — by vendors relicensing projects under source-available terms to capture cloud value, and by regulators imposing new obligations on open-source maintainers who never asked for them. The simultaneous relicensing of Redis (March 2024, to dual RSALv2/SSPLv1), the HashiCorp Business Source License shift (August 2023) and its OpenTofu fork, the Linux Foundation's establishment of Valkey as a Redis fork steward, the EU Cyber Resilience Act's novel "open-source steward" concept, and the Open Source Initiative's publication of the Open Source AI Definition collectively expose a structural contradiction: the open-source commons is being simultaneously enclosed by vendors and regulated by states, and the governance apparatus that sustained it for twenty years is not built for either pressure.

What Actually Changed in the Licensing Landscape

The Redis relicensing in March 2024 — moving from the permissive BSD-3 license to a dual RSALv2/SSPLv1 regime — was the most significant single event in the recent license wars, not because Redis was the first to relicense, but because it was the first major infrastructure project to do so after the cloud-licensing wars of 2018-2019 (Elastic, MongoDB) had supposedly settled. Redis Ltd's stated rationale was to prevent cloud providers from offering managed Redis as a service without contributing back. The immediate response was the Linux Foundation's launch of Valkey, a community fork under the BSD license, backed by AWS, Google Cloud, Oracle, and Snap. The pattern is now established: when a vendor relicenses an OSI-approved project to a source-available license, the Linux Foundation steps in as fork steward, and the cloud hyperscalers fund the fork. This is not a bug in the system; it is the system working as designed, but it is a design that was not built to scale to the current volume of relicensing events.

[QUOTE INSERTION 1 — sourcing required] Pull a direct statement from the Linux Foundation's published announcement on Valkey, or from a named representative of the Open Source Initiative on the Redis relicensing. Do not paraphrase into quotation marks.

What the Enclosure Actually Taught Us

The English enclosure precedent carries a lesson the open-source community is only now being forced to learn. The enclosure movement succeeded not because the commons was inefficient, but because the legal and political apparatus was captured by interests that valued private extraction over common sustainability. The displaced communities had no institutional voice in the Parliamentary process. Translated to open source: the current relicensing wave is not a failure of the open-source model; it is a rational response by vendors to a regulatory and market environment that has not priced in the cost of commons maintenance. The maintainers who built the infrastructure have no institutional voice in the corporate decisions that relicence their work. The Linux Foundation's fork-steward role is the closest analogue to the commons-defence institutions that emerged post-enclosure, but it is a reactive institution, not a preventive one. The historical lesson is that commons survive only when they have institutional power, not just moral claim.

The CRA's Open-Source Steward: An Unasked-for Obligation

The first implication the trade press has under-covered concerns the EU Cyber Resilience Act's novel treatment of open-source software. The CRA, which fully applies from December 2027, imposes mandatory security-update obligations on manufacturers of products with digital elements. But it carves out a specific category — "open-source software stewards" — defined as entities that provide sustained support for open-source projects released with a commercial intent. The unseen implication is that the Linux Foundation, the Apache Software Foundation, and similar bodies are about to discover they are regulated entities under European law, whether they sought that status or not. The CRA does not impose the full manufacturer obligation on open-source stewards, but it does impose a lighter-touch version: priority response to vulnerability reports, coordinated disclosure, and sustained maintenance. The result is that the institutions that have sustained the open-source commons for decades are now being asked to serve as a regulatory backstop for the European software supply chain, without the funding or the mandate to do so.

Counter-Argument: The CRA Exemption Is a Win, Not a Burden

The pessimistic reading — that the CRA's open-source provisions are an unfunded mandate — is too clean. The CRA explicitly excludes from its scope open-source software developed outside the scope of a commercial activity. The "open-source software steward" category applies only to projects with a commercial intent, which is a narrower set than the trade press has assumed. The Apache Software Foundation, the Linux Foundation, and similar bodies have repeatedly argued that their projects are not commercial activities, and the CRA's text supports that position. The real burden falls on corporate-sponsored foundations and on projects that accept commercial sponsorship, not on the volunteer-driven commons. The pessimistic case assumes the CRA will be interpreted broadly; the more likely outcome is that the exemption holds, and the open-source steward category remains a narrow, well-defined obligation.

The Open Source AI Definition and the Weights Tension

The second implication concerns the Open Source Initiative's Open Source AI Definition (OSAID), published in February 2024 after a contentious multi-stakeholder process. The OSAID defines "open-source AI" in terms that require not just open weights, but open training data, open code, and open compute specifications — a definition that excludes most current foundation-model releases, including Meta's Llama series, which are marketed as "open" but do not meet the OSAID criteria. The unseen implication is a schism in the AI community between those who treat "open weights" as sufficient for the open-source label and those who insist on the full OSAID criteria. The OSI has held the line, but the market has not followed: most AI practitioners and most cloud providers treat "open weights" as functionally equivalent to "open source," and the OSI's stricter definition risks marginalising the organisation that has historically been the authoritative voice on open-source definition.

[STATISTIC INSERTION 2 — sourcing required] Use published data from Hugging Face on model downloads tagged "open source" vs. those meeting OSAID criteria, or from the OSI's own published consultation responses. Cite the dataset and retrieval date. Do not estimate.

Fork-as-Defense and the Linux Foundation's New Role

The third implication is structural. The Valkey fork of Redis, the OpenTofu fork of Terraform (following HashiCorp's BSL relicensing), and the earlier OpenSearch fork of Elasticsearch (following Elastic's SSPL relicensing) establish a pattern: the Linux Foundation has become the institutional fork steward of last resort for major infrastructure projects. This is a new role for the Foundation, and it is not one its governance structure was designed to handle. The Foundation's traditional role has been to host projects, not to mediate corporate-community disputes or to fund defensive forks. The unseen implication is that the Foundation is accumulating a new kind of institutional power — the power to declare which forks are legitimate and which are not — without a corresponding accountability mechanism. The community that benefits from the fork has no formal voice in the Foundation's decision to steward it; the corporate sponsors who fund it do.

Counter-Argument: Fork Stewardship Is the Point, Not a Bug

It would be a mistake to treat the Linux Foundation's fork-steward role as a governance failure. The Foundation was created to serve the Linux kernel, and the kernel has survived precisely because the Foundation (and before it, the informal governance around Linus Torvalds) could mediate corporate-community disputes without being captured by either side. The Valkey and OpenTofu forks are not governance failures; they are governance successes — the system working as designed to protect the commons from unilateral enclosure. The pessimistic case assumes the Foundation will be captured by its corporate sponsors; the historical record suggests it has resisted capture for thirty years, and there is no reason to assume the current wave of forks will change that.

[QUOTE INSERTION 3 — sourcing required] Obtain an on-record statement from a named Linux Foundation executive (e.g., Jim Zemlin) on the fork-steward role, or from a published post-mortem on the Valkey or OpenTofu fork process. Their published communications are the correct primary anchor.

What To Do This Quarter

For open-source maintainers: understand that your project may now fall within the CRA's "open-source software steward" category if it accepts commercial sponsorship. Review the CRA text carefully, and engage with the Linux Foundation or Apache Software Foundation's legal teams to understand your obligations before they are imposed on you.

For organisations building on open-source infrastructure: treat the license status of every dependency as a supply-chain risk. A project relicensed yesterday may be a fork candidate tomorrow, and your procurement process needs to account for that possibility. Maintain a bill of materials that includes license status, not just version.

For cloud providers and hyperscalers: the fork-steward model is now an established pattern. If you depend on a project that is relicensed, the Linux Foundation is the institutional counterparty for the fork. Engage early, fund the fork, and treat it as infrastructure insurance rather than a one-time cost.

For AI practitioners: understand that "open weights" is not the same as "open source" under the OSI definition, and that the distinction is not merely semantic — it has regulatory consequences under the EU AI Act, which treats open-source models differently from source-available ones. Choose your terminology carefully, and understand the compliance implications of each.

The Next Two Quarters

Expect the next major relicensing event to target a mid-tier infrastructure project — not a Redis-scale flagship, but a project large enough to matter and small enough that the vendor believes the cloud-value capture justifies the community backlash. Expect the Linux Foundation to formalise its fork-steward role with published criteria and governance, moving from ad hoc response to institutional process. Expect the OSI to face continued pressure from the AI community to relax the OSAID criteria, and to resist that pressure on principle, even as the market continues to treat "open weights" as functionally equivalent to "open source." Expect the CRA's open-source steward provisions to be tested in the first enforcement actions, likely against a corporate-sponsored foundation rather than a volunteer-driven project. And expect the enclosure dynamic to continue: vendors will capture value from the commons, the commons will fork to defend itself, and the governance apparatus will struggle to keep up. The commons is not dying; it is being repriced, and the market is finally being forced to pay.