Your Customer Has the Deed, the Alarm Code, and the Wiring Diagram: Licensing Code You Give Away

When you ship the source, the customer can see and change every lock. So how do you license honestly? VBWD’s layered answer — signatures, entanglement, a compiled verifier, and law — is refreshingly candid.

Rewritten for redrobot.

Imagine handing someone the key to your house along with the deed, the alarm code, and a note explaining exactly which wire disarms the sensor. That is what shipping source-available software feels like when you also want to license it. The customer runs your code, so the customer can read the code, and the function that decides whether they are allowed to run it is sitting right there in plain view. Readable code is editable code. A determined operator can find the branch, delete it, recompile, and move on.

So the interesting engineering problem is not “how do I lock the door.” You cannot. The problem is “how do I build a system where breaking in costs more than paying, and leaves footprints everywhere if someone tries.” That is the puzzle VBWD had to solve for itself as a self-hosted, source-available platform, and the answer turned out to be less about cryptography and more about incentives.

The lie most vendors tell

Walk through the average commercial plugin and you will find a boolean somewhere. is_licensed returns true, some strings get shuffled to make the decompiler sweat a little, and the whole thing gets marketed as protection. It is theatre. The moment you ship source, a license check stops being technically enforceable and becomes legally enforceable — a distinction most vendors bury because admitting it feels like admitting weakness.

We decided to say it out loud instead. The source is readable. The check is defeatable by anyone willing to modify the code. Pretending otherwise implies a guarantee the software cannot keep, and a broken promise is worse than an honest limit. Once you accept that starting point, the real design goal snaps into focus: make defeating the check expensive, make it generate evidence, and make it pointless for the only people who ever owe you money. Because of how VBWD is priced — BSL 1.1, free for commercial use until annual VBWD-attributable sales cross the value of 6.7 BTC, then converting to Apache-2.0 on the change date — the only parties who ever hit a paid gate are running genuine revenue through the platform. That single fact reshapes everything downstream.

Start where cryptography actually wins

There is exactly one part of this that cryptography solves cleanly, so we lean on it hard: making tokens unforgeable. A VBWD license is a signed claim set — who the licensee is, which plugins are entitled, the seat and usage ceilings, the expiry — signed with an Ed25519 private key held only by the license authority. The product ships the public key and refuses to trust a single field until the signature checks out.

This does nothing to stop someone editing the verifier. What it stops is subtler and far more common: a licensee minting their own token that hands themselves the enterprise tier, or nudging the seat count up inside an otherwise legitimate file. Without a signature, a license is just editable JSON. With one, any change to the claims voids the signature, and forging a valid signature means recovering a private key you were never given. Ed25519 is fast, the keys are tiny, and signing per-plugin lets every plugin carry its own entitlement independently. It is the rare layer that is genuinely hard to break rather than merely annoying to break — so we spend it where it counts. How those signed claims flow into what the platform actually enables is laid out in the architecture overview.

Make the check load-bearing

A signature you can simply skip past is a speed bump, not a wall. The next move targets the “just delete the branch” reflex head-on. We call it entanglement, and the idea is to stop treating the license as a gate and start treating it as configuration.

The naive design reads the token, runs if not licensed: raise, and otherwise executes the exact same code either way. Cut that one line and the product runs at full strength. Entanglement refuses to keep the licensed values anywhere except inside the signed token. Seat limits, per-plugin enablement, feature flags, quota ceilings — these are read from the verified claims and used as live configuration, never compared and thrown away. The plugin registry asks the license which plugins are entitled and enables precisely those. Seat enforcement reads its ceiling from the token. There is no hardcoded fallback that quietly means “turn everything on.”

Now deleting the check does not unlock the product — it breaks it. Strip the verifier and the plugin registry has no list to work from, the seat ceiling is undefined, and every feature that pulled its configuration from the token goes dark. To keep things running, the attacker has to reconstruct all the values the token would have supplied and wire them back by hand, which is really just re-implementing the vendor’s entitlement system from scratch. That work has to be redone on every upgrade, and it grows with how deeply the platform’s behaviour is braided into its claims. The per-plugin structure this leans on is visible in the plugin catalogue. Entanglement never makes removal impossible; it makes removal a maintenance tax the licensee pays forever.

Raise the cost of reading

The two layers above assume an attacker who can read the verifier. So the next one taxes the reading. Python is transparent by nature — the source is right there, and even bytecode decompiles cleanly — which is fine for the platform but wrong for the one component that adjudicates licensing. That verifier ships compiled to a native extension with Cython or Nuitka, packaged as a wheel.

Be honest about the ceiling here: compilation is not encryption and it is not a security boundary. A compiled wheel is machine code, and machine code can be disassembled by anyone with the patience. What shifts is the effort gradient. Editing a line of Python takes seconds; locating the same logic inside an optimized native binary, understanding it, patching it, and rebuilding a working wheel takes a skilled reverse engineer real time — and that time gets spent again on every release. Stacked on top of entanglement, the compiled verifier means the attacker cannot just find and delete a branch. They have to reverse-engineer compiled logic and then reconstruct the entangled values it was feeding the rest of the system. That is the honest upper bound of what technology contributes here; the packaging details sit in the documentation. Anyone claiming a compiled verifier makes software uncrackable is selling you something.

Where the real weight rests

Every technical layer buys time and raises cost, and not one of them reaches certainty. The actual backstop is the contract. The license obligates compliance, and the fee threshold is defined against attributable revenue, not against whether some function returned true. A licensee over the line owes the fee whether or not they patched the verifier — patching it to dodge payment is a deliberate breach of a signed agreement, not a clever exploit.

What the technical system contributes to that contract is evidence. Activation and heartbeat telemetry record that an instance came online, what it claimed, and that it kept running. This is not a kill switch: the product never phones home for permission to function and does not stop if the network drops. The telemetry exists so a licensee’s own activation record establishes plain facts — this deployment, this scale, this duration. In a dispute, that is the gap between an accusation and a documented pattern. Keep it truthful, disclose it, keep it minimal, and it works as evidence without curdling into surveillance.

Line the layers up and the honest ledger reads: signatures make tokens unforgeable, close to absolute. Entanglement makes removal expensive and perpetual, not impossible. The compiled verifier makes the expense higher, not the binary opaque. Legal enforcement plus telemetry makes a violation a documented breach, not a technically prevented one. Nowhere does the word “uncrackable” appear, because a motivated engineer with time to burn can defeat every technical layer. The system is not built to stop that person. It is built so that person has no reason to exist — because the only licensees who ever owe a fee are, by construction, businesses large enough to cross a Bitcoin-denominated revenue line, with customers, auditors, and reputations to weigh against the cost of a discovered, deliberate, endlessly-maintained breach. For a real company, proper licensing is simply cheaper and safer than the crack. The incentives and the license point the same way — the same logic that shapes the pricing model. That is not DRM, and it should never be sold as DRM. It is just an honest system that matches how the software is actually used.