Legible and independent proposals¶
Normative precision and independent proposals¶
A specification needs fixed rules for independent implementations to interoperate, without making its choices the only possible response to the problem. Maintainers decide what to incorporate into the edition they publish, while other participants can develop proposals with their own decisions and maintenance.
A rejected change can remain available, be discussed elsewhere or lead to another specification. Preserving those possibilities is consistent with the thesis guiding Legible.
Names for derived proposals¶
Use a distinct name and your own versions. Legible Aurora, for example, could name an independent proposal; Legible Aurora 1.0, one of its editions. The number would not place it in an official sequence of succession to Legible.
Maintainers permit compound names using Legible within the rights they control. Identify authors, maintainers, edition and address, preserve attribution of reused materials and explain the differences. The shared name helps readers recognize the origin; explicit identification of the proposal avoids confusion over who maintains it.
This permission grants no third-party rights and does not authorize presenting another proposal as a publication or service of these maintainers. See the licenses and publication notices.
Identification and conformance¶
The name identifies the proposal; the edition fixes the contract; tests show which operations interoperate. A higher number demonstrates neither quality nor succession. To distinguish artifacts with similar names, also supply authorship, URI and the specification's hash.
When declaring conformance, identify the specification, edition and implemented profiles. Keep draft status visible. “Compatible with Legible” without those details does not say which contract was tested.
Mirrors, implementations and independent specifications¶
A mirror redistributes the same normative text. An implementation fork can change the code while remaining conformant with the same edition. An independent specification can change the contract and needs to explain where it differs.
The .legible folder is this specification's storage convention.
Where contracts are incompatible, distinguish schemas, signature namespaces
and storage where necessary. Different declarations should not appear
equivalent. Changing only the project name does not require changing the bytes
of records that remain conformant.
Shared origin or name does not create joint maintenance or endorsement. Each publication identifies its maintainers. This site does not need to host, catalogue or moderate independent proposals.
How to publish an independent proposal¶
- Choose the edition and materials to reuse in the protocol repository. Check licenses, attribution and identification of changes.
- Define the name, edition, maintainers and a stable address. A repository or static site is enough; a separate domain is optional.
- Explain differences and preserved contracts. Use distinct identifiers where incompatible and publish conformance criteria.
- Include reproducible examples and tests with fictional keys, stating what was verified and the known limits.
- Where it accurately describes the origin, use wording such as “an independent proposal derived from The Legible Protocol, draft 0.4”, identifying the reused edition.
This description helps readers find and compare proposals through ordinary publication and search channels. There is no protocol registry guaranteeing discovery or search ranking. Trace and Nod are optional and do not replace attribution required by licenses.