# QGPL 3.1 Open Evidence Edition

Review draft 2026-10-24

This is a proposal for substantive review. QGPL v3.0 remains the current published license. Its canonical text is unchanged. The separate candidate is [QGPL_v3.1_Open-Evidence_DRAFT.txt](../QGPL_v3.1_Open-Evidence_DRAFT.txt). No legal review, SPDX listing, OSI approval, or FSF endorsement is claimed.

## Proposed changes

| Area | Proposed behavior | Practical limit |
| --- | --- | --- |
| Component boundaries | Identify data, model weights, code, inputs, and outputs separately. Copyleft follows applicable rights and an actual Modified Work. | Using a model does not automatically make every output subject to QGPL. Facts remain subject to applicable law. |
| Rights and evidence | A signed machine-readable manifest maps artifacts to the exact license text and separately records supplied evidence. | A rights claim in metadata cannot create ownership or relicense third-party material. |
| Minimal disclosure | Manifests omit private keys, credentials, and unnecessary personal data. A key or organizational identifier may replace a personal profile. | Hashes and pseudonyms are not automatically anonymous. Lawful disclosure still needs separate assessment. |
| Honest assurance | Record byte integrity, issuer trust, time evidence, and content assessment as independent checks. Unperformed checks remain not assessed. | A valid signature does not establish identity, a trusted date, scientific truth, or lawful publication. |
| Renewed evidence | Optional signed renewal records link the artifact and prior evidence to new cryptography while retaining the history. | Re-signing after a break cannot retrospectively prove an earlier existence time. No perpetual archive service is required. |
| Transport clarity | Preserve a post-quantum or hybrid key-establishment obligation for encrypted transfers and distinguish it from release signatures. | A KEM does not authenticate an endpoint. The draft does not claim that hybrid key agreement makes an entire TLS session post-quantum. |
| Version discipline | Use `LicenseRef-QGPL-3.1-draft` with the draft date and a hash of the included terms. Existing v3.0 grants do not migrate automatically. | Adoption requires authority over the relevant rights. A new draft is not a replacement for copies already licensed under v3.0. |

## Material policy choices for review

The candidate changes the definition and treatment of model outputs, makes machine-readable rights and evidence records mandatory for covered distributions, adds minimal-disclosure conditions, and clarifies transport scope. These are proposed license conditions, not cosmetic website corrections. The existing toolkit specification and fixtures have not been upgraded to implement this draft, and no working 3.1 toolkit is claimed.

The transport clause now addresses key establishment explicitly. It does not repeat the v3.0 wording that could be read as requiring post-quantum endpoint authentication as well. Review should decide whether this narrower, technically explicit obligation is the desired policy. A distributor still needs to assess the actual protocol, authentication, and negotiated transfer.

The candidate permits unassessed issuer identity, time, and content checks while requiring an honest status record. Mandatory time-stamping or institutional identity would raise the adoption burden and is not proposed here. An organization may apply stricter internal verification policies without changing the permissions granted by the license.

The signed status record contains the issuer's declarations before signing. If a later verifier distributes a verification verdict or report, it must be separate from the signed record and tied to the artifact or signed-payload digest, avoiding a self-referential verification result. Private checks do not require a separate record. Old signatures may be reused only while their algorithms remain permitted at redistribution. A withdrawn algorithm requires new compliant evidence for a later distribution, while prior records remain history. Ordinary noncompliance can terminate and provisionally restore patent permissions under Section 7, while patent-litigation termination under Section 6.2 is not restored by curing a different violation.

Minimal disclosure is a design condition, not a claim that a manifest satisfies the GDPR or any other law. Distribution to lawful limited recipients does not require publishing their data to the world. If even the mandatory minimum cannot lawfully be supplied, a distributor needs separate permission or must refrain from that distribution in reliance on this draft.

The proposal retains copyleft and a mandatory quantum-resistant release signature. It does not introduce a software-source delivery obligation, a certification scheme, a scientific truth guarantee, automatic compatibility with GPL or Creative Commons, or permission to use third-party material. These boundaries need legal and implementation review before a stable release.

## Suggested implementation boundary

An eventual format should keep the artifact rights map separate from the evidence status record, while signing both in one reproducible payload. It must document serialization, signature boundaries, key encodings, and hybrid acceptance policy. A human-readable summary may accompany that payload. The candidate intentionally does not claim that the existing draft 0.5.1 manifest implements all of these requirements.

For a first demonstration, publish a synthetic dataset with its exact license text, a component rights map, a post-quantum signature, and an evidence status record. Mark issuer trust and independent time as not assessed unless a demonstrable verification process exists. Then demonstrate a renewal link and a failed verification without overstating what either result proves.

## Primary sources informing the proposal

The sources support the stated technical and legal boundaries. They do not endorse QGPL or establish the enforceability of the proposed conditions.

- [Creative Commons guidance on facts and database rights](https://creativecommons.org/faq/#which-components-of-databases-are-protected-by-copyright) explains the distinction between factual contents and protected database elements. This informs Sections 0 to 2.
- [SPDX license-expression specification](https://spdx.github.io/spdx-spec/v3.0.1/annexes/spdx-license-expressions/) provides the custom `LicenseRef-` form. The proposed reference is not a registered SPDX identifier. Its draft date and text digest distinguish exact revisions.
- [GDPR Article 5 in EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679) includes data minimisation. The [European Commission explanation](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) informs the minimal-disclosure proposal in Section 4.
- [NIST FIPS 204](https://doi.org/10.6028/NIST.FIPS.204) and [NIST FIPS 205](https://doi.org/10.6028/NIST.FIPS.205) define ML-DSA and SLH-DSA. Signature verification and the broader evidence claims are kept distinct in Section 5.
- [NIST FIPS 203](https://doi.org/10.6028/NIST.FIPS.203) defines ML-KEM for establishing a shared secret. Section 5.6 distinguishes that function from endpoint authentication.
- [NIST SP 800-208](https://csrc.nist.gov/pubs/sp/800/208/final) specifies approved stateful signature profiles. Its operational requirements matter as well as an algorithm's name.
- [NIST FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) and [NIST FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) specify the SHA-2 and SHA-3 digest families used in the proposal.
- [RFC 3161](https://www.rfc-editor.org/rfc/rfc3161) defines a time-stamp protocol. [RFC 4998](https://www.rfc-editor.org/rfc/rfc4998) describes long-term evidence and renewal. Sections 5.4 and 5.8 use these as background without claiming automatic compliance with either protocol.

Sources checked on 2026-10-24. The candidate text is a proposal, not legal advice or a completed independent assessment.