WCL-1.1: The License That Cannot Be Taken Down
WCL-1.0 had a dissolution clause. WCL-1.1 removes it entirely. No dissolution. No reversion window. A federated node network where any party can light a new node with the license text as the only seed. The formula stays given.
By Ody, The Wellkeeper ·
WCL-1.0 contained a fail-safe clause: if WellSpr.ing ceases operations, all WCL-licensed software reverts to MIT automatically. The clause was well-intentioned. It was also wrong.
The problem is that 'ceases operations' presupposes a legal entity with a dissolution event. WellSpr.ing is not a legal entity. There is nothing to dissolve. The actual threat is not dissolution — it is capture: domain seizure, infrastructure takedown, or steward incapacitation. A reversion clause triggered by incapacitation creates a window for exactly the kind of adversarial action it was meant to protect against. A 90-day window where the license is in reversion-pending state is a 90-day window for a hijacked domain to claim authority over what the code becomes.
WCL-1.1 removes the dissolution clause entirely. There is no reversion. There is no window. The permissive grant is immutable at the moment of issuance — no event, no passage of time, and no state of any node or steward can alter it. The node network is self-sustaining. The license is the seed. The seed does not require the original gardener.
The architecture: nodes, not authority
WCL-1.0 centered on the Wellkeeper as the steward of the covenant economics layer. WCL-1.1 replaces that single-point architecture with a federated node model.
A WCL node is any server that hosts the canonical license text, maintains a hash registry of releases published under WCL, and exposes a verification endpoint. Any individual, organization, or community can operate one. git.wellspr.ing is the first node and the origin of the license. It is not the authority. The license text is the authority.
The node registry is a plain-text file mirrored to IPFS. Its authoritative state is the content-addressed IPFS version, not any particular domain's copy. If every current node goes dark, any party with the license text can stand up a new node and resume the network. No approval required. No steward action required. The formula is the franchise. The franchisor's continued operation is not a condition of the franchise.
This is not a new concept in open source — it is how DNS works, how Bitcoin works, how the Forgejo federation works. What is new is applying the federated resilience model to the licensing layer itself, so that the covenant economics infrastructure is as resistant to capture as the code it governs.
IPFS anchoring: the immutable record
Every WCL release should be anchored to IPFS at publication. The IPFS CID is content-addressed — it is computed from the content itself, not from any server's location. A file pinned to IPFS with the CID recorded in the release metadata is permanently retrievable by anyone with the CID, regardless of what happens to any domain or server.
The practical implementation: at release, compute the SHA-256 of the release archive, publish to the node's hash registry, pin to IPFS via at least two independent pinning services, and record the CID in the release tag metadata and README. The node registry itself is pinned to IPFS on each update.
This means: even if https://git.wellspr.ing is seized and redirected to serve hostile content, the legitimate releases remain retrievable via their IPFS CIDs. The CID is in the release metadata on every fork, every mirror, every download. The content-addressed record is not subject to DNS hijacking or server compromise.
For Replit deployment: the IPFS pinning can be automated via the Pinata or web3.storage APIs at release time. The node verification endpoint is a simple lookup against the hash registry. The total additional infrastructure for IPFS anchoring is modest — an API call at release time and a CID field in the release record.
On the permanence statement
WCL-1.1 contains an explicit Permanence Statement in Part VI:
'There is no dissolution clause in WCL-1.1. The license does not revert. The grant does not expire. The node network does not have a master off-switch. If every current node goes dark, any party with this text may light a new one. The formula is given freely. It stays given.'
This is not legal boilerplate. It is a design commitment made visible. The permissive grant in Part I is unconditional and irrevocable under standard copyright law — a license cannot be unilaterally revoked once granted. The Permanence Statement makes the covenant intent explicit so that it cannot be obscured by claims about the steward's status or any node's availability.
The covenant economics layer in Part III continues to operate from whichever nodes are active. If no nodes are active, the Part I grant remains in full force, permanently, independently. The Respect Mon pathways and ledgers are node-specific features, not conditions of the license.
Running a WCL node
The minimum viable WCL node:
- A Forgejo instance (or any git host with a public API) — the sovereign stack from NoFlare.org and NotGit.org works directly
- The canonical WCL-1.1 text hosted at {your-node}/wcl/license/1.1
- A verification endpoint at {your-node}/wcl/verify/{hash} — accepts a SHA-256, returns verified status and publication metadata
- A pull request to https://git.wellspr.ing/WellBuilder/wcl-nodes adding your node to nodes.txt
The pull request is the only gate. Any operator who can submit a pull request can run a node. The registry is a flat file. The network is the registry.
For organizations that want to run WCL nodes: universities, civic organizations, faith communities, industry consortia, companies that use WCL-licensed software and want to contribute to network resilience — the infrastructure cost is the same Forgejo instance you would run for your own sovereign git. The node is an additional endpoint on existing infrastructure.
What this means for existing WCL-1.0 releases
Software published under WCL-1.0 remains under WCL-1.0. The permissive grant in WCL-1.0's Part I is identical to WCL-1.1's. The difference between the two versions is in the fail-safe architecture, not in the permissions granted.
Publishers who want to move existing projects to WCL-1.1 can do so by noting in the README that the project is adopting WCL-1.1 from a specified version forward. Prior releases remain under WCL-1.0. New releases are under WCL-1.1. Both are compatible with MIT, Apache 2.0, and ISC.
The NotShop bundle — the first WCL release — will be updated to WCL-1.1 and re-anchored to IPFS. The updated CID will be recorded in the repository metadata and the git.wellspr.ing registry.
WCL-1.1 full text is at wellspr.ing/license/wcl-1.1. The WCL node registry is at git.wellspr.ing/WellBuilder/wcl-nodes. To run a WCL node, submit a pull request adding your node URL to nodes.txt. The NotShop bundle (the first WCL release) is at git.wellspr.ing/WellBuilder/notshop-bundle. NotGit.org has the Forgejo sovereign stack cookbook for node operators. IPFS pinning documentation is at docs.ipfs.tech. Pinata API docs at docs.pinata.cloud. Licensed under WCL-1.1.