CueCruxVaultCrux

Contributing · 8. Licence, security, governance

Crux Daemon is Apache License, Version 2.0 — OSI-approved, permissive, no copyleft. You may run, read, audit, modify, redistribute, and even host it for third parties. Redistribution asks for four things: include the licence, state your changes, keep notices intact, pass on NOTICE.

This chapter quotes the operative clauses rather than paraphrasing them. A licence summarised is a licence misrepresented, and this one is short enough to read in full.

This is reference material. It is not legal advice. The authoritative text is LICENSE in the repository.

8.1 What the licence is, and is not

The Apache License, Version 2.0, the unmodified upstream text, at LICENSE:1.

This replaced the CueCrux Community Licence (CCL v1.0) (CHANGELOG.md, "chore: relicense Crux Daemon from CCL v1.0 to Apache-2.0"), a source-available, BSL-style licence that withheld redistribution-in-competing-products and third-party-hosting rights. The CCL already named Apache-2.0 as its eventual Change Licence; the relicense brought that conversion forward for all versions immediately, rather than waiting out each release's separate three-year clock. If you are reading a document anywhere in this set that still describes a CCL clause, a six-rights/three-prohibitions split, or a Change Date, that document is describing the retired licence — docs/LICENCE-FAQ.md is the up-to-date plain-English companion to this chapter.

Source-available no longer applies; this is open source. Apache-2.0 is OSI-approved and GPL-compatible. If your organisation's policy requires OSI approval, this licence meets it.

Scope. The licence covers the daemon code. The curated content assets under content/ are covered separately by the CueCrux Content Licence v1.0 at content/LICENCE-CONTENT.md. If you are touching content/, read that file too.

8.2 Permitted uses, verbatim

Apache-2.0's grants, drawn from LICENSE:66 (Grant of Copyright License) and LICENSE:73 (Grant of Patent License), summarised as seven rights:

  1. Run it for any purpose — internal, commercial, or production.
  2. Read, audit, and verify the source, including confirming the integrity of CROWN receipts, BLAKE3 chains, and tenant isolation.
  3. Modify it, for internal use or to ship to others.
  4. Redistribute it, in source or binary form, including inside a proprietary or competing product.
  5. Offer it as a managed, hosted, or cloud service to third parties.
  6. Sublicense it, including under a different licence, subject to the redistribution conditions in 8.3.
  7. Use it for academic research and publication. Citation is appreciated (CITATION.cff at the repository root drives GitHub's "Cite this repository" button) but is no longer a licence condition.

Two of these matter more than they look.

Clause 2 is a standing invitation to audit. Verification is not merely tolerated, it is an enumerated right, and the repository ships the tooling for it: corecruxctl verify-store --strict, corecruxctl replay --strict, scripts/demo-receipt-tamper.sh and scripts/assert-context-custody.sh. See 4.9. If you find that a claim does not hold, that finding is itself a welcome contribution.

Clauses 4 and 5 are new relative to the old licence. The CCL prohibited redistribution inside a competing product and third-party hosting outright; Apache-2.0 imposes neither restriction. Legally you may now fork, redistribute, and host Crux Daemon for other people. Section 8.8 still applies regardless: stripping receipt generation is legal under this licence, but a build that does so cannot honestly claim the integrity properties this documentation set describes.

8.3 Redistribution conditions

Apache-2.0 does not prohibit redistribution — it conditions it. Four requirements apply whenever you redistribute the Software or a derivative work, from LICENSE:89 (Redistribution):

  1. Include the licence. Ship a copy of LICENSE with any distribution.
  2. State your changes. Modified files must carry prominent notices saying they changed.
  3. Retain notices. Keep the copyright, patent, trademark, and attribution notices from the source you copied, including the per-file headers.
  4. Pass on the NOTICE. Include the attribution text from NOTICE.

That is the whole redistribution obligation set. There is no copyleft: your own modifications and surrounding code can be licensed however you like (LICENSE:130, Submission of Contributions, covers the inbound side — see 8.4).

Notice requirements are not a configuration choice. Removing licence headers or attribution notices from a redistributed build breaks clause 3. If you are contributing a change that touches the receipt path or the header tooling, understand that you are touching a licence-adjacent surface.

This is also why the licence-header CI gate exists. scripts/check-licence-headers.sh enforces the Apache-2.0 header on every .rs file under crates/ as part of the required Lint check. See 5.5 for the exact four lines.

8.4 Trademarks, and what you are not agreeing to

Apache-2.0 grants no trademark rights (LICENSE:138, Trademarks). "CueCrux", "Crux", and "CROWN" are trade names of CueCrux Ltd. Saying "built on Crux Daemon" is fine; calling a fork "CueCrux-anything", or presenting it as official, is not.

Contributions are inbound=outbound. LICENSE:130 (Submission of Contributions): unless you state otherwise, anything you submit is licensed under Apache-2.0 on the same terms as the rest of the work. You keep your own copyright; there is no separate CLA to sign.

No warranty, no liability. LICENSE:143 (Disclaimer of Warranty) and LICENSE:153 (Limitation of Liability): the software is provided "AS IS", and contributors are not liable for damages arising from its use.

8.5 Machine-readable licence metadata

Apache-2.0 is a registered SPDX identifier, so licence detection is straightforward: GitHub's licensee and comparable scanners resolve the repository licence directly from the verbatim LICENSE file. Three signals are published.

SignalWhereEnforced by
Repository licence fileLICENSE, the unmodified upstream Apache-2.0 textWhat heuristic detectors match against
SPDX Apache-2.0The second line of every .rs header under crates/ (// SPDX-License-Identifier: Apache-2.0)scripts/check-licence-headers.sh:20, in the required Lint check
Cargo metadatalicense = "Apache-2.0" at Cargo.toml:46, inherited by every member via license.workspace = truecargo metadata and CycloneDX SBOM generators report Apache-2.0 for all crates

Apache-2.0 is in the cargo-deny allowed-licence list at deny.toml:20, so the workspace's own crates pass cargo deny check licenses.

The crates are marked publish = false and are not on crates.io — the workspace uses unversioned path dependencies that a registry publish would reject. That is a packaging detail, not a licensing one.

8.6 Security disclosure

Do not open a public GitHub issue for a security vulnerability (SECURITY.md:5).

Email security@cuecrux.com with four things (SECURITY.md:7):

#Include
1A description of the vulnerability
2Steps to reproduce
3Affected versions
4An impact assessment; your best estimate

The stated response timeline (SECURITY.md:16):

StageTarget
Acknowledgment48 hours
Assessment7 days
Fix release30 days

Scope (SECURITY.md:26):

In scopeOut of scope
The corecruxd daemonThe VaultCrux hosted platform
The corecruxctl CLIThird-party dependencies, report those upstream
All corecrux-* cratesSocial engineering
CROWN receipt generation and verification
BLAKE3 chain integrity
Tenant isolation

Supported versions: 0.5.x is the current release; anything below 0.5 is best effort (SECURITY.md:35).

One severity rule is worth quoting because it tells you what the project cares about (SECURITY.md:22):

"CROWN receipt integrity bugs are treated as critical severity regardless of exploitability."

Recognition: accepted reports receive credit in CHANGELOG.md and in any published advisory. Encryption: request the PGP key via the same address.

Security-relevant checks run continuously, not just on demand: Cargo audit against the RustSec advisory database and Cargo deny policy are both required checks and also run on a weekly cron. Container images are Trivy-scanned with a CRITICAL gate before any push (9.6).

8.7 The trust contract

TRUST-CONTRACT.md states five clauses the daemon is expected to satisfy (TRUST-CONTRACT.md:5). All five, quoted verbatim:

  • "free-tier operation is local-first, CPU-only, accountless, and offline-capable"
  • "wire egress is capability-token gated"
  • "local documents remain on the daemon unless a token explicitly authorises the relevant data class"
  • "every call produces a receipt with the token-selected receipt class"
  • "community mods cannot bypass token policy"

For a contributor, the operative paragraph is TRUST-CONTRACT.md:15:

"Every clause is verifiable by reading the source, the receipt verifier, the capability-token spine, the JWT auth path, the vaultcrux-local content-signature gate, and the crux-router decision matrix all live in this tree."

That is the standard your change is held to. If your change could weaken one of those five clauses, say so in your pull-request description; do not leave a reviewer to find it.

The document is equally explicit about the boundary (TRUST-CONTRACT.md:17): the hosted VaultCrux API that crux-sync optionally pushes to is operated by CueCrux Ltd and is not in this repository. A self-hosted deployment without it runs local-only, returning DegradedLocal decisions on hosted-tier capabilities. You can audit the local half by reading this tree. You cannot audit the hosted half from here.

Release bundles ship TRUST-CONTRACT.md next to LICENSE, and scripts/assert-daemon-release-boundary.sh enforces its presence in the bundle.

Three related documents:

DocumentCovers
docs/THREAT_MODEL.mdTrust boundaries and stated limitations
docs/assurance-coverage-matrix.mdPer-event-class assurance: what is captured, what can bypass capture, and what a receipt does and does not prove
docs/quality-threat-refs.mdThe threat reference identifiers used across the workflows and scripts

8.8 What a receipt does not prove

Stated here because it is the easiest thing in this project to overclaim, and because a contributor who misunderstands it will write the wrong test.

A CROWN receipt is a verifiable record of what was stored and retrieved. It is tamper-evidence over the daemon's own record. It is not an attestation that an agent behaved in a particular way. The daemon can prove that a given record was written, that it has not been altered since, and that a retrieval returned what it says it returned. It cannot prove what a model reasoned, or that a human read the result.

The repository is careful about this in its own documentation, and docs/assurance-coverage-matrix.md is the file that draws the line, per event class, including what can bypass capture. Read it before you write documentation or a test that asserts a stronger property than the code delivers.

The same discipline applies to the runtime posture: 3.3 notes that route-auth scope classification defaults to shadow mode, which logs rather than rejects. A route being classified is not the same as a route being enforced.

Sources