Ship the source and a license check becomes a suggestion. Anyone who runs your code can read the function that decides whether they are allowed to run it, and readable code is editable code. This is not a flaw in your implementation. It is the definition of source-available software. So the honest question is not "how do we make the check unbreakable" but "how do we build a licensing system that a real business has no reason to break, and that leaves a paper trail when someone does."
VBWD is self-hosted and source-available. We had to answer this question for ourselves, and the answer we arrived at is layered, incentive-based, and deliberately not marketed as DRM. Here is the reasoning, including the parts that do not work.
Start with the uncomfortable truth. When the source ships, a license check is legally enforceable, not technically enforceable. A determined licensee can find the branch that reads a token, gates a feature, or counts seats, and delete it. Recompile, redeploy, done. No signature scheme, no obfuscation, and no runtime attestation changes that fundamental fact, because the person defeating the check controls the machine, the interpreter, and the disk the code sits on.
Most vendors respond to this by pretending it is not true. They ship a boolean, wrap it in some string juggling, and call it protection. That is worse than doing nothing, because it implies a guarantee the code cannot keep. We took the opposite position: state plainly that the source is readable, that the check is defeatable by anyone willing to modify the code, and then design so that defeating it is expensive, evidence-generating, and pointless for the people who actually owe money.
VBWD is distributed under BSL 1.1. It is free for commercial use while annual VBWD-attributable sales stay below the value of 6.7 BTC; above that, a commercial license is required, and the whole thing converts to Apache-2.0 on the change date. That structure matters for the argument below, because the only parties who ever hit a paid gate are running real revenue through the platform. Hold that thought.
The first job is narrow and completely solvable: make license tokens unforgeable. A VBWD license is a signed claim set — who the licensee is, which plugins are entitled, seat and usage limits, expiry — signed with an Ed25519 private key that only the license authority holds. The product ships the public key and verifies the signature before trusting a single field.
This does not stop someone from editing the verifier. It stops something more specific and more common: a licensee minting their own token that grants themselves the enterprise tier, or tampering with the seat count inside an otherwise legitimate token. Without a signature, a license file is just editable JSON. With one, any change to the claims invalidates the signature, and forging a valid signature means recovering a private key you never had. Ed25519 is fast, the keys are small, and per-plugin signing lets each plugin carry its own entitlement independently. This is the one layer that is genuinely hard to break rather than merely expensive, and it is worth doing precisely because it is cheap and absolute within its scope. The way entitlements flow from signed claims into the plugin system is described in the architecture overview.
A signature you can simply skip is not much of an obstacle, so the second layer attacks the "just delete the branch" move directly. We call it entanglement: derive real product behaviour from the license claims rather than gating on them.
The naive design reads the token, evaluates if not licensed: raise, and otherwise runs identical code paths. Deleting that one line restores full function. 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, not compared and discarded. The plugin registry asks the license which plugins are entitled and enables exactly those. The seat enforcement reads its ceiling from the token. There is no hardcoded fallback that means "everything on."
Now removing the check does not unlock the product; it breaks it. Strip the verifier and the plugin registry has no list to enable, the seat ceiling is undefined, and the features that read their configuration from the token go dark. To keep the product working after deleting the check, the attacker has to reconstruct all the values the token would have supplied and wire them back in by hand — effectively re-implementing the entitlement system from the vendor's side. That is real work, it has to be redone on every upgrade, and it scales with how deeply the platform's behaviour is tied to its claims. Entanglement does not make the check impossible to remove. It makes removal a maintenance burden the licensee carries forever. The plugin catalogue shows how per-plugin entitlement is structured, which is the surface this layer leans on.
The first two layers assume the attacker can read the verifier. The third layer raises the cost of that reading. Python is trivially inspectable — the source is right there, and even bytecode decompiles cleanly. So the verifier that matters is not shipped as readable Python. It is compiled to a native extension with Cython or Nuitka and shipped as a wheel.
Be precise about what this buys. 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 and the tools. What changes is the effort gradient. Editing a line of Python takes seconds. Locating the equivalent logic in an optimized native binary, understanding it, patching it, and rebuilding a working wheel takes a skilled reverse engineer real time — and it, too, must be redone each release. Combined with 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 fed the rest of the system.
This is the ceiling of what technology can do here. It moves the work from "trivial" to "annoying and ongoing," and for a source-available product that is the honest upper bound. Anyone who claims a compiled verifier makes their software uncrackable is selling something. The packaging details for how the verifier ships alongside the plugins live in the documentation.
The technical layers buy time and raise cost. They never reach certainty, and they are not meant to. The actual backstop is legal. The license is a contract. It obligates compliance, and the threshold that triggers a fee 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, and patching it to avoid payment is a deliberate breach of a signed agreement rather than a clever technical exploit.
What the technical system contributes to enforcement 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 does not phone home for permission to function, and it does not stop working if the network is down. The telemetry exists so that a licensee's own activation record establishes the facts: this deployment, this scale, this duration. In a dispute, that record is the difference between an accusation and a documented pattern. Design it as a truthful log, disclose that it exists, and keep it minimal, and it does its job as evidence without becoming surveillance.
Stack the layers and here is the honest ledger. Signatures guarantee that tokens cannot be forged or tampered with — that one is close to absolute. Entanglement guarantees that removing the check is expensive and must be maintained across upgrades, not that it is impossible. The compiled verifier guarantees that the expense is higher still, not that the binary is opaque. Legal enforcement plus telemetry guarantees that a violation is a documented breach of contract, not that the breach is technically prevented.
Nothing on that list says uncrackable, because none of it is. A sufficiently 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 the person capable of it has no reason to be that person.
That is the incentive argument, and it is the load-bearing one. The only licensees who ever owe a fee are, by construction, running a business large enough to cross a revenue threshold denominated in Bitcoin. That business has customers, employees, auditors, and reputational exposure. Weigh a licensing fee assessed against large revenue against the cost of a discovered, deliberate contract violation — reverse-engineering a compiled binary on every release, carrying the maintenance forever, and doing it all as documented breach with the vendor's activation logs on the other side of the table. For a real company, proper licensing is simply cheaper and safer than the crack. The model works because the incentives point the same direction as the license.
Licensing source-available software honestly means refusing two temptations: pretending a technical check is unbreakable, and giving up because it is not. The productive path is layered. Make tokens unforgeable with signatures. Make check removal expensive with entanglement. Make it more expensive with a compiled verifier. Then rest the real weight on a contract and an evidence trail, and design the whole thing for people whose incentives already favor compliance. That is not DRM, and it should not be sold as DRM. It is an honest system that aligns with how the software is actually used and priced — the same logic that shapes the pricing model.
If you want to see how the signature, entanglement, and verifier layers fit into the wider platform, start with the architecture overview and read the licensing section alongside the plugin entitlement docs.