Open
Public verifiability made enforceable — SPDX and license on every source, an SBOM that bounds the dependency set, and content-addressed artifact provenance bound on-chain so a deployed identity can be checked byte-for-byte.
LP-0014: Open
Abstract
LP-5 commits Lux to open source as a policy. This LP is the enforcement: the property that anyone can verify, byte-for-byte, what is running. That property holds only where it is checked at a boundary — a license header on every source file, an SBOM that bounds the dependency set, a content-addressed hash bound on-chain so a deployed artifact can be matched against what its owner signed off on.
Motivation
"Open source" as a license choice is necessary but not sufficient. A reader can see the code in a repo and still have no way to answer: is this the code that is deployed? what does it depend on transitively? who attests to it? Those are verifiability questions, and they are answered by mechanisms, not by a license file. LP-5 is the policy; this LP names the mechanisms that make the policy checkable by an outsider with no special access.
Specification
The invariant: every artifact carries the provenance needed to verify it independently. License travels with the source; the dependency set is enumerated; the deployed identity is content-addressed and bound on-chain. Three boundaries enforce it.
1. License on every source — SPDX
Every source file carries an SPDX-License-Identifier header. This is the machine-readable license that travels with the file regardless of where it is copied; it is not inferred from a repo-root LICENSE. The on-chain federation registry's own Solidity sources demonstrate the convention — // SPDX-License-Identifier: BSD-3-Clause (lp-0011-onchain-federation-registry.md). A file without an SPDX header has unknown license provenance and fails the check; the header makes provenance explicit per file, not per repository.
2. Bounded dependency set — SBOM
The set of things that ship is enumerable, not open-ended. LP-7 specifies the supply-chain control that makes the SBOM finite and verifiable (lp-0007-supply-chain-control.md): a counted internal-package inventory, pinned external versions, and reproducible counts —
go list -m all | wc -l # unique modules
go list -m all | grep -v luxfi | wc -l # external surface
The point is not the specific numbers but that they are reproducible: an auditor regenerates the same SBOM from the same source and confirms nothing undeclared was pulled in. A bounded, pinned dependency set is what makes "open" mean "fully auditable" rather than "source-available somewhere".
3. On-chain artifact provenance — content-addressed binding
A deployed identity is bound to its source artifact by a content hash recorded on-chain, so a consumer verifies the live artifact against the chain rather than trusting whoever currently serves it.
LP-11 is the enforcement point (lp-0011-onchain-federation-registry.md). An app publishes (brandId, appId, domain, url, wellKnownHash, owner) to the on-chain resolver. A consumer queries the chain for who claims a given identity, fetches the live https://<domain>/.well-known/<appId>.json, canonicalizes it under RFC 8785 (JSON Canonicalization Scheme, so re-serialization by a CDN cannot change the hash), and confirms it matches wellKnownHash byte-for-byte. A short-lived DNS hijack or TLS-terminating proxy cannot substitute a forged record, because the forged document hashes differently from the one the owner bound on-chain. Owner authority is a key — secp256k1, or ML-DSA-65 (FIPS 204) under strict-PQ — and domain control is proven by a re-attested challenge-response.
This is the artifact-provenance analogue of SPDX-on-source: the hash travels with the deployed identity and is checkable without trusting the server.
Distinction from LP-5
| LP-5 (Open Source) | LP-14 (Open) | |
|---|---|---|
| Kind | policy | enforcement |
| Asks | should it be open? | can an outsider verify it? |
| Artifact | a license choice | SPDX header, SBOM, on-chain hash |
| Checked by | review | a boundary check that fails closed |
LP-5 decides Lux forks and publishes; LP-14 makes the result independently verifiable. Reading LP-14 as a restatement of LP-5 misses the point — the value here is the check, not the intent.
Rationale
Each mechanism puts provenance where it cannot be separated from the thing it describes: license in the file, dependencies in a reproducible manifest, deployed-artifact hash on-chain. None depends on trusting a central authority at verify time — the SPDX header is in the source, the SBOM regenerates from source, the wellKnownHash is read from the chain. That is what makes the property "open" in the enforceable sense.
Backwards Compatibility
States and composes existing mechanisms (SPDX convention, LP-7 SBOM, LP-11 registry). No code changes.
Security Considerations
Content-addressed provenance is only as strong as the canonicalization: without RFC 8785, a server that re-serializes JSON changes the hash and breaks verification, so the canonical form is mandatory (luxfi/well-known-canonical). On-chain binding proves what an owner published, not that the published artifact is itself benign — provenance is necessary for trust, not sufficient. An SBOM bounds the audit scope; it does not by itself prove the bounded set is free of vulnerabilities.
Copyright
Copyright and related rights waived via CC0.