If you run a white-label deployment of VBWD, or you resell it to your own customers, sooner or later you hit the same question: how do you hand a specific customer a license that unlocks a specific set of capabilities, without shipping them a fork or babysitting a spreadsheet of who paid for what? The answer VBWD is designing for is a two-part system: a License Server that mints signed license tokens, and a License Client baked into every instance that verifies them. This piece walks through how that model is built, how a key gets issued and checked, and where the honest boundaries are.
Some of what follows is running and some of it is still being built. Treat this as the designed architecture, not a purchase button. VBWD is source-available under BSL 1.1, self-hosted, and built on Python/Flask, Postgres, Vue 3, and Docker — the same agnostic-core plugin platform everything else in the ecosystem sits on. The licensing design follows the same rules as the rest of it.
The whole model comes down to keeping two responsibilities apart.
The License Server is a hub instance running a license-authority plugin. It holds the Ed25519 private key. It is the only thing in the entire system that can issue, sign, or revoke a license token. Nothing else has the private key, and nothing else needs it. If you are the OEM partner selling VBWD downstream, the License Server is yours — it is where your customer relationships, your plans, and your signing authority live.
The License Client is the opposite: a small core module shipped inside every VBWD instance, including your customers'. It holds only the public key. It can verify a token and enforce what the token says, but it cannot create one, cannot alter one, and cannot sign anything. It does its job offline. It never calls home to check a license.
That asymmetry is the point. The private key stays on one machine you control. The public key ships everywhere. A customer instance can be air-gapped, behind a corporate firewall, or running in a region with no route back to your hub, and license verification still works, because verification is pure math against a public key — no network round-trip required.
Walk it through end to end.
A customer buys a license tariff plan on your hub — the same tariff-plan and subscription machinery VBWD already uses for any other paid product. That purchase is the trigger. From their dashboard plan page, the customer manages their own license codes: they generate a code, and behind the scenes the license-authority plugin on the License Server signs a token with the Ed25519 private key.
The token is a compact, signed statement. It carries an identity (who this license is for), whatever validity window applies, and — this is the part that does the real work — a features list. That list is what gates capabilities inside the instance. The signature is what makes the whole thing tamper-evident: change a single byte of the features list and the signature no longer verifies.
The customer takes that token and drops it into their own VBWD instance. From here the License Server is out of the loop entirely. The License Client in the customer's core reads the token, checks the signature against the public key it already holds, and if it verifies, reads the features list. Every place in the code that guards a licensed capability — the enforcement seams — asks the same local question: does the verified token grant this feature? No feature in the list, no capability.
Because the check is offline and cryptographic, there is no license server to be down, no latency on every request, and no telemetry leaking back about how the customer uses their install. Revocation is handled by the Server refusing to re-issue and by the token's own validity terms, not by a live heartbeat.
The business half of this matters as much as the crypto. Issuing licenses is not a support ticket. It is a product.
You define a license tariff plan the way you define any plan on VBWD — price, terms, and the feature bundle it grants. Your customer buys it, lands on their plan page, and manages their license codes themselves: generate, view, and rotate them without waiting on you. That is the same self-serve subscription surface VBWD already ships for billing, reused for licensing instead of bolted on beside it. If you have seen how plans and subscriptions work in the platform documentation, the license plan is not a new concept to learn; it is that concept pointed at a different deliverable.
For an OEM partner this is the difference between licensing being a cost center and being a channel. You set the plans. The customer transacts and self-manages. The signing happens automatically on purchase. You are not in the loop for routine issuance, only for the policy decisions you actually want to make.
VBWD has a hard architectural rule, enforced by an automated oracle in CI: the core stays agnostic. The core does not know about your domain, your plugins, or your business. Domain knowledge lives in plugins. If licensing were done carelessly, it would violate that rule immediately — licensing is about as business-specific as it gets.
The design gets around this with one principle: mechanism in core, policy in plugin.
The mechanism — verify an Ed25519 signature, read a features list, enforce at a seam — is generic. It has no opinion about what the features mean or who is allowed to sell them. That is safe to put in core, and it is exactly what the License Client is: a verifier and nothing more. It carries the public key and the checking logic. It carries no policy.
The policy — who gets issued a license, which plans map to which features, how signing and revocation are governed — lives in the license-authority plugin on the hub. That is where all the business-specific judgement sits, and plugins are exactly where business-specific judgement is supposed to sit.
Split this way, the core carries only a generic cryptographic verifier, so the core-agnosticism oracle stays green. A customer instance ships a public key and a checker; it does not ship your pricing model or your customer list. The same discipline that keeps every other plugin in the ecosystem from leaking into the core keeps licensing out of it too. The License Client is a core module because verification is a universal mechanism every instance needs; the License Server is a plugin because issuing authority is a policy only your hub should hold.
This part matters, and glossing over it would be dishonest.
VBWD is source-available. Your customers can read the code, including the code of the License Client. The Ed25519 signature is strong: it stops forgery. Nobody without the private key can mint a valid token, alter a features list, or fabricate a license out of thin air. That guarantee is real and it holds.
What cryptography does not stop is someone with the source deleting the check. A determined party can, in principle, edit the enforcement seams out of their own copy. No client-side license system on source-available software can prevent that, and pretending otherwise would be selling you a fantasy. Crypto raises the cost and removes the easy paths — casual tampering, forged tokens, feature lists edited in a text editor — but the final backstop is legal, not technical. The BSL 1.1 license and your commercial terms are what govern use. The signed token is what makes a violation unambiguous and provable, not what makes it physically impossible.
To be equally clear about scope: VBWD is licensed under BSL 1.1, never CC0 or any public-domain dedication. Source-available is not the same as unlicensed, and the licensing system is built to make the terms enforceable, not to give the software away.
One more honest note: parts of this are still being built. The two-key split, the offline verifier, and the self-serve plan model are the designed architecture. If you are planning a rollout, plan against the design and check the current plans and terms for what is available today rather than assuming a finished turnkey product.
The License Server hub is a small idea applied carefully. One machine holds a private key and turns purchases into signed tokens. Every other machine holds the matching public key and verifies those tokens offline, enforcing a features list at the seams. The business side is a self-serve tariff plan your customers manage themselves. The architecture side is mechanism-in-core, policy-in-plugin, which keeps the whole thing inside VBWD's agnostic-core rules instead of fighting them. And the limits are stated plainly: signatures stop forgery, terms stop misuse, and the two work together rather than one pretending to be the other.
The features list is where most of the interesting product decisions live — how granular the gates are, how bundles map to plans, how capabilities degrade when a license lapses. That deserves its own treatment rather than a paragraph here.
Next in this series: how the features list gates capabilities inside an instance — the anatomy of a license token and what a seam actually checks.