Choose the right document for the task
The license, the working local toolkit, the browser record and the historical design draft are separate layers. Their version numbers describe different things.
A compatibility map
| Layer | Version | Purpose | Boundary |
|---|---|---|---|
| Published license | 3.0 | The current published legal text | The canonical file governs its terms |
| Review draft | 3.1 | A separate proposal for rights and evidence | No automatic migration from 3.0 |
| Local toolkit | 0.1.0 | Real single-file ML-DSA-65 signatures | A bounded profile with separate documented limits |
| Browser record | 0.1 | An unsigned record with a local SHA-256 digest | No post-quantum signature or independent issuer check |
| Historical toolkit design | 0.5.1 | A planning document for a broader implementation | Not the format accepted by toolkit 0.1.0 |
| Historical fixtures | 0.4 | Data shapes and a reference generator | Committed cryptographic fields contain placeholders |
The local toolkit has a named profile
Toolkit 0.1.0 uses SHA-256, ML-DSA-65 and RFC 8785 JSON canonicalization. It writes one sidecar manifest for one artifact. It signs the artifact hash and the other manifest fields using an explicitly documented encoding rule.
qgpl.single.ml-dsa65.v1
The useful limit
This profile does not implement the historical root-key hierarchy, hybrid signatures, revocation or multi-file manifests. It also does not implement the rights map, evidence status and license-text binding proposed for QGPL 3.1.
A valid toolkit signature is a useful integrity check. Complete license compliance still requires a separate assessment of rights, notices and delivery.
A browser record is an unsigned first step
The browser tool can calculate a local file digest and help prepare a record. The resulting profile 0.1 record has no post-quantum signature, independently verified identity or trusted timestamp. It cannot satisfy the mandatory release-signature requirement by itself.
Open the browser record toolKeep the design history available
Draft 0.5.1 explores a broader design including root keys, hybrid signatures and archival verification. Fixtures in the directory named spec 0.4 preserve an earlier annex. Some details evolved after that annex was named, so read the change notes in the specification.