Why Knolo Is Apache-2.0 and Local-First

Knolo is the open-source, local-first Knowledge Image runtime and format maintained by Hive AI. The reference runtime, @knolo/core on npm, is licensed under Apache-2.0, and a Knowledge Image is meant to be mounted and checked on your own machine. Those two choices are connected. This note explains why Knolo uses a permissive license, what "local-first" means in practice, and where the Knolo name has its own boundaries.

Why Knolo uses Apache-2.0

The Knolo licensing page states it directly: Knolo Core currently uses the Apache License 2.0, and canonical license texts live with each project. Software rights come from that license and its notices. Anyone can reuse the implementation and implement the contract within those terms.

A permissive license fits the kind of thing Knolo is. A Knowledge Image is supposed to outlive the model or product that first used it. If reading, verifying or re-implementing the format depended on one vendor's permission, the artifact would not really be portable. Apache-2.0 keeps the format and the reference code open to more than one implementation.

What local-first means for a Knolo Knowledge Image

Local-first is a design rule, not a slogan. A V5 Knowledge Image is a bounded, content-addressed artifact with deterministic encodings, domain-separated SHA-256 roots and a commit history, as the Knolo specifications page describes. You can copy it, mount it and verify it without asking a server whether it is valid.

The same holds for sharing. Knolo Hub lists public images, but you pin a digest and mount the bytes locally; Hub does not run the query. Verification checks the bytes against the roots they declare, and a mismatch fails closed. Anyone can run that check with the open tools. To make sure you are looking at the real project, the Knolo verification center lists the official Knolo domains.

Knolo compatibility is not Knolo endorsement

Open code does not mean open use of the name. The licensing page is clear that you may implement the specification and use the software, but you may not imply official approval, call an independent implementation "official," or use "Knolo Certified" without a real program. Trademarks are a separate right from the software license.

The Knolo compatibility page sets the expectation for independent work: compatibility claims should link to versioned tests or documented support, with versions, fixtures and results. That protects users, who need to tell a compatible tool from an official one, and it protects implementers, whose honest claims are easier to trust when the rules are written down. The Knolo trademark policy covers the name itself: refer to the project accurately, such as "built with @knolo/core," and describe rather than impersonate.

What the Knolo public record says today

Knolo's public pages try to say plainly what is and is not published yet. The specifications index lists the Knowledge Image .knolo format with V5 as the current contract in source and V4 preserved for compatibility. Numbered, adopted specification records are not published yet, so the working contract lives in public source and documentation. The Knolo KIPs index shows the proposal format with labeled example drafts and states that no accepted standards are published. Unpublished is better than invented.

Read the Knolo source and docs

• Source code, issues and releases: the Knolo core repository on GitHub.
• Developer docs and packages: Knolo on knolo.dev.
• Specifications, licensing and the public record: Knolo on knolo.org.