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.

LicenceWhat it covers
Apache-2.0The engine, the CLI (including the TLS server built into it), the wire types, the Node bindings and TypeScript SDKs, the MCP server, the VS Code extension, the desktop and local-operations edges, the plugin SDK, the runner-neutral CI job contract — and the full specification and conformance corpus.
Commercial (LicenseRef-TOVIO-Commercial)The Forge in both of its deployment surfaces, the Forge web dashboard, the hosted CI platform and its authentication stack, the enterprise modules, and the managed service.

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.