What is open source and what is not
The open-core split, stated plainly — and which component falls on which side.
Written By Dustin
Last updated 35 minutes ago
TOVIO is open core. Every component declares its own licence as an SPDX identifier in its own manifest, so the split is machine-readable rather than a matter of interpretation.
Where the line actually falls
Not at networked, and not at paid. It falls at the collaboration platform.
The Apache-2.0 CLI contains a real bidirectional TLS server: tovio serve handles clone, fetch and push, and enforces your per-file permission policy on every push. So the free tier is complete version control, including cryptographically enforced per-file permissions, with no collaboration platform on top — no proposals or review, no checks or merge queue, no lock arbitration, no events or webhooks, no admin roster, no multi-repository operations, no replication.
That is a capability boundary, not a licence asterisk. Nothing in the free tier is deliberately crippled to sell you an upgrade; the Forge is a different product that sits above it. The comparison the project uses for itself is Git and GitHub: the format and the protocol are open and permissively licensed, and the collaboration server is a product.
If you have seen Elastic-2.0 mentioned
Elastic License 2.0 was originally assigned to the Forge and has since been retired from the project entirely. No component carries it. Nothing was taken away from anyone: no ELv2 grant was ever published, because no release was ever tagged. The reasoning behind the change is on the record — ELv2 restricted reselling the Forge as a service but not using it, which meant the customer most able to pay was entitled to run the whole product for nothing.
Do not describe any part of TOVIO as source-available on the strength of an older document. The Apache-2.0 parts are open source; the Forge is proprietary.
Why this particular split
The parts that must be inspectable to be trustworthy — the cryptography, the permission enforcement, the object format, the wire protocol, the token contract — are Apache-2.0 and publicly versioned. You do not have to take the project's word for how permissions are enforced. You can read it, and you can implement it: alternative implementations are an explicit goal rather than a tolerated side effect.
The open specification, not the Forge's licence, is what carries the anti-lock-in promise. The two were deliberately kept as separate decisions.
How the separation is kept honest
Commercial code lives in this source tree under a single private/ directory that is its own build workspace, excluded from the public one. Two rules make that equivalent to a separate repository:
- The dependency arrow points one way. Nothing outside
private/may depend on anything inside it — not by path, not by name, not through a build feature. A boundary checker enforces this in continuous integration rather than leaving it to review. No public component depends on the Forge either, which is why extracting it stays a move rather than a refactor. - The open tree yields a working client and a complete, implementable specification. The engine, the CLI, the SDKs, the built-in server, the storage, wire, crypto and policy contracts, and the conformance corpus are all Apache-2.0 and all stand on their own.
One honest caveat about how that is checked: the boundary is verified structurally — the checker reads the workspace membership and exclusion entries and the packaging definitions. It is not currently proven by deleting the private directory and running a full build. An earlier decision record claimed it was; a later one corrected that claim rather than leaving it standing, which is the kind of correction the decision-record archive exists to make visible.
None of the commercial code is included in any Apache-licensed package, container, software bill of materials, or release artifact — releases build named public packages rather than a whole workspace.
Verifying for yourself
The LICENSE file at the repository root is the licensing overview and names each component. Each package manifest carries its own SPDX identifier. The governance document restates the same split. This article is a summary of those files, not a substitute for them.