Paths into standards

Where each mechanism could be standardized, and what each route costs

Published by: LexLintSean McDermott, Co-Founder and CEO
Draft 1: 28 October 2026Comments to open@lexlint.io
License: CC BY 4.0Adopt it, fork it, improve it

Legal information, not legal advice. This paper describes where two mechanisms, the repository declaration and jurisdictional context, could be standardized and how each venue says it works. It recommends no venue and decides no legal question; what a venue's terms commit a participant to is a question for counsel. See the notice in the footer.

Summary

Two mechanisms, the repository declaration and jurisdictional context, are texts anyone may adopt today. Each could also be carried into a standards body, and the bodies differ in who decides, what a contributor licenses, how long a text has taken there and what could go wrong. This paper sets out those options venue by venue, beside option zero, in which the text stays where it is: how each venue decides, its terms and its record of time as its own pages state them, and what it would own and what could go wrong as this paper reads them. It opens with the order an earlier text followed, the specification behind the license identifiers in files and packages, from a community text to tools to an international standard a decade later, and both mechanisms are at the first of those stages. The requirements the mechanisms meet are cited, not standardized. A reader can reject a venue and keep the mechanism, or reject a mechanism and keep the need.

1How a text becomes a standard

A text does not have to begin inside a standards body to end as a standard. The specification behind the license identifiers that files and packages carry, SPDX, took three steps over about a decade, by its own record, and that order frames everything below.

A community text. Drafting began in February 2010 in a work group under the Linux Foundation, and specification 1.0 is dated August 2011. Its list of licenses gives each one a standardized short identifier.
Adoption in tools. The Linux kernel's commit adding the identifier to the files that carried no license is dated 1 November 2017, and the kernel's license rules now require it in all source files. npm's documentation tells package authors to state a license by its identifier, and PEP 639, now final, added a License-Expression field to Python's core metadata.
A de jure standard. The project's timeline marks version 2.2.1 as prepared for submission to ISO in August 2020, and ISO/IEC 5962 as available in August 2021. The project states that its specification is recognized as ISO/IEC 5962:2021.

CycloneDX, the bill of materials format behind two of the venues in section 2, has taken the same road: its version 1.6 was published on 9 April 2024, the first edition of Ecma International's standard for it is dated June 2024, and Ecma lists that standard with an ISO/IEC number at the draft stage.

Both mechanisms weighed here are at the first step.

Mechanism	Stage	What exists
The repository declaration, ACTIVITIES.md	1, a community text	A file format and an open activity registry, published on this site since 15 October 2026, and filed at no venue (section 2)
Jurisdictional context	1, a community text	Draft 2 of a proposal on this site, dated 28 October 2026, after draft 1 of 9 October 2026, and filed at no venue (section 3)
The requirements both mechanisms meet	Cited, not standardized	Stated in two papers, and cited by number by each mechanism (section 4)

Sections 2 and 3 take one mechanism each, in one table. Its first row is option zero, in which the text stays where it is. Each row after it is a venue, named by a link to its own page, and says seven things: the venue and its group, the narrowest piece it would own, how it decides, its intellectual property rights (IPR) terms for patents and copyright, the time a text has taken there by its own record, where things stand, and the risks. In a venue's row, how it decides, its IPR terms and its typical time say what the venue's own pages state, or that the venue does not state it, and where things stand says what is public at the venue, linked. What it would standardize and the risks are this paper's own reading of each venue, which the venue may not share. Nothing here ranks the venues: a reader can reject every venue in a table and still adopt the mechanism, or reject the mechanism and still hold to the requirements it meets.

2The repository declaration

The venues below were read on their own pages on 25 October 2026. ACTIVITIES.md is a file at the root of a repository in which a project declares the activities its code performs or enables, drawn from an open registry, and the counterparties it cannot run without. It meets D1 to D7, which the paper You already think about law states for any declaration of what code does. Each venue would own a different piece of it: a property name, a catalog entry, a profile, or a field in a file or in a package's metadata.

Venue	What it would standardize	How decisions are made	IPR terms	Typical time	Where things stand	Risks
Option zero: stays a LexLint-published text under CC BY 4.0	Nothing. The file's format, its schema and its activity registry stay as published at ACTIVITIES.md, for anyone to adopt or fork.	The publisher decides each change and dates each version of the registry. Anyone may fork the text without asking.	CC BY 4.0 for the registry's text, its identifiers and the schema. The license grants no patent or trademark rights.	None: the text is published, and it changes when its publisher dates a new version.	Published as ACTIVITIES.md since 15 October 2026, with its registry and schema.	One publisher's text: anyone can adopt it, but no one else decides its next version, and a tool maker may wait for a venue before building on it.
CycloneDX, its property taxonomy	A registered top-level property namespace in CycloneDX's official registry, and the property names under it, with the namespace's taxonomy documented in the registrant's own repository.	Anyone creating custom properties outside the `internal` namespace is recommended to register a namespace, by opening an issue. A namespace starts as reserved, and its taxonomy is expected to be public before use. The project calls itself meritocratic and consensus-based, and its core team decides when community consensus cannot be reached.	The registry table is marked CC0 1.0, and the repository is under the Apache License 2.0. A patent policy for the taxonomy: not stated by the venue.	From the venue's pull requests: two namespaces merged within three days of being opened, in August and September 2026; a property registration merged in 27 days; and two namespace requests open since 12 August 2026 and 7 October 2026. A target time: not stated by the venue.	Nothing filed: the registry lists no namespace for ACTIVITIES.md.	A namespace gives the identifiers a home inside CycloneDX bills of materials only, and the queue shows requests that stay open for weeks without a merge.
Ecma International, Technical Committee 54 (TC54), a CycloneDX 2.0 activity card	A predefined perspective: an entry in the CycloneDX perspectives catalog that a bill of materials can take in by its identity, under the reserved `cdx:` namespace, as pull request 1067 in the specification's repository proposes for the model card.	Two stages, which the labels in the CycloneDX specification's repository name: a public notice sent to the CycloneDX mailing list for consideration and a vote accepted, then promotion to TC54, its review by TC54 and its acceptance; pull request 1067 carries each of those labels. In TC54, members are representatives of Ecma members, a vote is by simple majority with one vote per member, the committee is asked not to vote unless progress is impossible without one, and a new work item needs the support of at least three Ecma members, at most one of them not-for-profit. A non-profit may apply for annual not-for-profit membership, and an associate member takes full part in technical committee work without a vote in the General Assembly. TC54 welcomes contributions from the community.	TC54 works under Ecma's Royalty-Free Patent Policy: each participating entity files a registration form with a royalty-free patent license statement for its essential claims, and may exclude patents it identifies. Copyright in contributions: not stated by the venue in the pages read.	The venue's record: CycloneDX 1.6 was published on 9 April 2024 and the first edition of its Ecma standard is dated June 2024; 1.7 was published on 21 October 2025 and the second edition is dated December 2025. The 2.0 milestone, created on 14 November 2019, is open, with a due date of 31 August 2026 and 87 open and 96 closed issues.	Nothing started or filed.	The card would wait on a 2.0 release that is past its milestone date, and the `cdx:` namespace is reserved to the CycloneDX project, so the entry would belong to CycloneDX.
SPDX, the Software Package Data Exchange working group (Linux Foundation), a profile of the SPDX 3 model	A profile, one of the model's compliance points, or content under its Extension Profile, carrying what a software element does.	Formal membership is not required to take part in developing the specification. Teams decide by consensus, which the team lead determines, and the steering committee decides when community consensus cannot be reached. A profile working group works on its own branch with at least one maintainer, the SPDX technical group reviews it, and it is merged to the development branch and then to main.	Specifications after version 2.2.1 are under the Community Specification License 1.0, under which each contributor grants a royalty-free license to its necessary patent claims. Contributions are made under the project's contributor license agreement by the act of contributing.	The venue's timeline: the 3.0 effort merged with a tool-to-tool bill of materials effort in February 2021, a 3.0 release candidate with Security, Build, Dataset and AI profiles came in May 2023, and 3.0.0 was released in April 2024. Version 3.0.1 lists nine profiles, an Extension Profile among them.	Nothing started or filed.	The model is built for bills of materials and licenses, so a profile for declared activities would be new content for it, and the profile process asks for a working group and a standing maintainer.
OpenSSF, the Security Insights specification	A field in the Security Insights file or, at the narrowest, a reference from it to ACTIVITIES.md.	Decisions are guided by the consensus of community members who have reached maintainer status. A change is proposed as a Security Insights Enhancement Proposal; one from a non-maintainer needs a maintainer's sponsorship; discussion runs for no longer than 30 days; and a favorable quorum on a change to the specification must include maintainers from at least two organizations.	Specifications in the repository are under the Community Specification License 1.0, and the OpenSSF charter names that license for specifications and CC BY 4.0 for other documentation. A separate patent policy: not stated by the venue.	A discussion window of at most 30 days. Releases: 1.0.0 on 2 October 2023, 2.0.0 on 1 January 2025, 2.1.0 on 9 May 2025 and 2.2.0 on 31 January 2026. A proposal-to-release time: not stated by the venue.	Nothing started or filed.	The project's principles favor a minimal format and say new entries must be added with caution, and the file reports a project's security practices, so a field about what software does is a stretch for it.
Python Packaging Authority, core metadata, through a PEP	A new core metadata field and its `pyproject` key, as PEP 639 added `License-Expression`.	A new specification is proposed as a Standards Track PEP, and an author who is not a core developer needs a sponsor. The Steering Council is the final authority, and a PyPA core reviewer may offer to serve as its delegate, with the authority to approve or reject.	Each new PEP is placed under a dual license of public domain and CC0 1.0 Universal. A patent policy: not stated by the venue.	The venue's record for PEP 639: created on 15 August 2019, now Final, last modified on 24 January 2025. A target time: not stated by the venue.	Nothing started or filed.	Core metadata describes a distribution package, so a field there would reach Python packages only, and the one comparable change in the record spans years.
npm, the `package.json` manifest, through the npm proposals process	A field in `package.json`, proposed by a pull request to the repository of proposals for the npm command line tool.	The process follows a rough consensus model, similar to the IETF's. The npm CLI team holds the final authority to ratify a proposal, and anyone can fork the repository of proposals and open a pull request.	The repository of proposals is under the ISC License, copyright npm, Inc. A patent policy: not stated by the venue.	Not stated by the venue. The one record read, proposal 55, was created, accepted and implemented on the same day, 18 June 2026, which is no measure of a proposal period.	Nothing started or filed.	One tool's manifest: the process holds that other package managers declining to implement a proposal is not in itself reason enough to drop it, so a field there may reach npm alone.

The venues' pages read for this table

CycloneDX: the property taxonomy, governance, the taxonomy's pull requests
Ecma International: TC54, the TC54 site, the CycloneDX standard, rules, by-laws, the royalty-free patent policy; CycloneDX's pull request 1067, releases and milestones
SPDX: about and timeline, governance, the governance documents and license, contributing to the 3 model, conformance in 3.0.1
OpenSSF: Security Insights, its governance, its releases, the OpenSSF charter
Python: PyPA specifications, and PEP 1 and 639
npm: the proposals repository, proposal 55

3Jurisdictional context

The venues below were read on their own pages on 25 October 2026. Jurisdictional context carries, for each party to a piece of work, which jurisdiction's law reaches that party: as a structured HTTP header across trust boundaries, as baggage inside them, and through bindings to message queues and the agent protocols. It meets R1 to R9, which the paper Whose law was that? states for any record of a piece of work. Its parts could go to different venues: the header to one, the vocabulary to another, and the attribute names and the agent-protocol bindings to others again.

Venue	What it would standardize	How decisions are made	IPR terms	Typical time	Where things stand	Risks
Option zero: stays a LexLint-published text under CC BY 4.0	Nothing. The model, the bindings and the rules stay as published in jurisdictional context, for anyone to adopt or fork.	The publisher dates each draft, and the draft number moves when the text changes in substance. Comments go to open@lexlint.io, and anyone may fork the text without asking.	CC BY 4.0 for the text and its figures. The license grants no patent or trademark rights.	None: draft 1 is dated 9 October 2026, and draft 2 is dated 28 October 2026.	Draft 2 of jurisdictional context, published on this site.	A header name and a vocabulary that one publisher holds interoperate only between the implementers who adopt the same draft, and a protocol maintainer may wait for a venue's text before building on it.
IETF, an individual Internet-Draft toward the HTTP API working group	A new HTTP header field, defined as a Structured Field: the kind of output the group's charter names, new HTTP header and trailer fields.	Anyone can contribute, and decisions are made by rough consensus, in the sense of RFC 7282. The charter asks that an adopted proposal have public support from several implementers or deployments before it goes to the Internet Engineering Steering Group.	Contributors grant the IETF Trust a perpetual, irrevocable, non-exclusive, royalty-free license under their copyrights in a contribution. On patents the IETF requires disclosure and disclaims any responsibility for identifying or evaluating them. A royalty-free requirement for patents: not stated by the venue in the policy read.	The venue's record: the Deprecation header draft was at revision 01 on 25 December 2020 and was published as RFC 9745 on 17 March 2025. The RateLimit header fields draft was at revision 01 on 11 May 2021 and at revision 11 on 23 May 2026, still a working group document.	Nothing started or filed.	The charter says the group will not take on work items for HTTP APIs for specific applications or services, which a field about legal context could be read as, and the records above run to years.
W3C, a Community Group	A vocabulary, the terms for the readings, incubated and published as a Community Group specification.	Anyone may join any Community Group, with no fee and no membership. No charter is required, only a short scope statement and five supporters to create the group. Decision-making is self-determined, but required to be fair.	Contributors sign the Community Contributor License Agreement, a royalty-free copyright license, and signers of a Final Specification Agreement commit to license their essential patent claims royalty-free.	Not stated by the venue: a Community Group has no chartered end date.	Nothing started or filed.	The venue says Community Groups do not create W3C standards, so the output would be a group report until a standards-track group takes it up.
OpenTelemetry, semantic conventions	Attribute names: a registry namespace for span, metric and log attributes that could carry the readings or the declared activities.	A new area needs a group of people familiar with the domain who commit to be its point of contact. A non-trivial change, new conventions included, needs a project proposal approved by the Governance Committee and the Technical Committee before work begins, and should be prototyped in instrumentation.	Contributors sign the Cloud Native Computing Foundation's contributor license agreement, and the repository is under the Apache License 2.0. A separate patent policy: not stated by the venue in the pages read.	Not stated by the venue.	Nothing started or filed.	The scope is telemetry, and the venue says conventions specific to a single runtime, library or narrowly scoped implementation should be defined in that implementation's own repository.
Model Context Protocol, a specification enhancement proposal through the nearest group	A metadata key, or an Extensions Track proposal, that carries the readings in MCP messages. The protocol has no group named for agent identity: Agent Identity and Enterprise-Ready Security is priority area 3 of its roadmap. Its interest groups include Agents, Authorization, Enterprise-Managed Authorization and Security.	Prior discussion is required: the author discusses the idea with the relevant working or interest group before opening the proposal. A core maintainer or maintainer sponsors it, core maintainers review in formal meetings every two weeks, and a prototype is required before acceptance. The repository accepts pull requests from collaborators only. Interest groups decide by rough consensus, which binds no one; working groups bind by lazy consensus, then a vote, then escalation.	Code and specification contributions are made under the Apache License 2.0 and documentation under CC BY 4.0. The text of a proposal itself is in the public domain or under CC0 1.0 Universal.	Not stated by the venue. Its index lists final proposals with the day each was created, the Skills Extension on 23 April 2026 among them, and gives no day of acceptance.	Nothing started or filed.	The venue says proposals outside current priorities are more likely to face delays, so a proposal would have to ride a roadmap priority.
Agent2Agent protocol (a Linux Foundation project), an extension	A data-only extension, identified by a URI and declared in the Agent Card, carrying the readings in the metadata map of the protocol's core structures.	Anyone may define, publish and implement an extension. For an official one, any community member proposes it, a maintainer sponsors an experimental repository, and the Technical Steering Committee votes on graduation, with at least half its voting members present and a majority of those present approving. The committee has nine seats, each held by a company.	Official extensions must be under the Apache License 2.0, and contributors grant the Linux Foundation and recipients a royalty-free license to their contribution.	Not stated by the venue.	Nothing started or filed.	Extensions are off by default and not required for conformance, so a declared reading reaches only the clients that opt in.
Agentic AI Foundation, the Governance, Risk and Regulatory Alignment working group	The Legal Context Schema, which a charter change proposes as a standardized schema defining an agent's operative legal context: jurisdiction, delegation of authority and compliance boundaries.	Open to the public, to individuals and organizations, and members take part as individuals. The charter's default is chair-led consensus with voting as a fallback, and the chairs were appointed by the group's Platinum and Gold members. A charter change is a pull request to the group's repository.	Code under Apache-2.0, documentation and specifications under CC BY 4.0, and contributions with a Developer Certificate of Origin sign-off. A patent policy: not stated by the venue in the charter.	The venue's record: the first charter pull request was opened on 21 April 2026 and merged on 11 June 2026, with the charter dated approved 1 June 2026. Its initial goal for 2026 is three report-style deliverables.	The pull request that names the schema was opened on 13 October 2026 and is under review, and the charter on the main branch does not contain it, so the schema is not chartered work. This paper's publisher's public comments in the group's issues, the first on 23 September 2026, set out which roles the EU AI Act's logging duties bind, in the thread on monitoring and logging, and offer the binding legal requirements for each of the group's themes as rows, in a first theme card and an issue offering the format.	The charter's current deliverables are guidance documents and reports, and its stated limits exclude legal advice and compliance solutions.
IETF OAuth working group: the Identity Assertion JSON Web Token Authorization Grant and OAuth Transaction Tokens	In the authorization grant, the content of an `authorization_details` object, as RFC 9396 defines detail objects; in Transaction Tokens, a name inside the transaction context, `tctx`, whose content is determined by the token service.	As for the HTTP API working group: anyone can contribute, and decisions are made by rough consensus. The charter lists complex delegation, for automated agents acting across administrative domains. Its milestones name Transaction Tokens and OAuth 2.1 among others, and not the authorization grant draft.	As for the HTTP API working group: the royalty-free license to the IETF Trust, and disclosure of patents.	The venue's record: Transaction Tokens revision 02 was approved on 21 June 2024, and revision 11, dated 30 July 2026, is at working group consensus and waiting for its write-up, against a milestone to submit it to the Internet Engineering Steering Group in December 2026. The authorization grant draft was at revision 01 on 19 October 2025 and revision 04 on 21 May 2026. Identity and Authorization Chaining Across Domains went from revision 02 on 8 July 2024 to revision 17 on 19 July 2026, and is in the RFC Editor's queue.	Nothing started or filed.	Transaction Tokens is at working group consensus, so a new element there would arrive as a change request to a nearly finished document, and that draft makes the transaction context the token service's to set. The authorization grant draft is earlier, a working group document at revision 04.
OpenID Foundation, the AuthZEN working group	A profile or a defined context for the Authorization API that carries the readings between a policy enforcement point and a policy decision point. The group already runs profiles of that kind as working group drafts, among them a Profile for Obligations.	Work is by mailing list, calls and meetings, and the charter treats work as complete when three independently developed implementations are proven to interoperate. The Foundation requires every contributor to sign its contribution agreement.	Under the Foundation's intellectual property policy, contributors grant the Foundation and others a copyright license in their contributions and make a patent non-assertion agreement, and the patent promise covers only the working groups listed in a contributor's agreement.	The venue's record: the Authorization API 1.0 implementer's draft was approved in November 2024 and the final specification in January 2026.	Nothing started or filed.	The charter puts higher-level policy for an executive audience out of scope, and the group is about authorization decisions, which the readings are not.
Open Secure AI Alliance, the SAFE working group	The fields of SAFE's incident record that name jurisdictions. Version 1.0 of the compact already says to record affected jurisdictions and any applicable external reporting duty, responsible party, deadline and filing status, and asks submissions to use a versioned machine-readable minimum record where available.	Any Alliance member may propose a working group to the steering committee and join any working group. Each working group member has one vote, a charter change goes by pull request or by a change request to the steering committee, and a merge needs the approval of at least one working group member.	The repository is under CC BY 4.0. A patent policy: not stated by the venue in the pages read.	Version 1.0 of SAFE is dated 21 October 2026, and a new working group has an interim leadership for an initial period of six weeks. A proposal-to-text time: not stated by the venue.	This paper's publisher's public comments on the drafts and on version 1.0, the first on 22 September 2026, raise the jurisdictions an incident reaches and the reporting duties they carry: an issue proposing that a report record its jurisdictions and the statutory reports the incident triggered, an issue listing AI incident-reporting duties that a proposed list of legal carve-outs left out, and a comment of 23 October 2026 asking that jurisdictions and the external reporting duties go into the machine-readable minimum record. The publisher also joined the working group's roster through a public pull request, opened on 23 October 2026 and merged on 26 October 2026.	Participation in SAFE is a commitment to the compact, so taking part to shape a field also commits the participant to its reporting.

The venues' pages read for this table

IETF HTTP API: charter, documents, participating, RFC 7282, 5378 and 8179, and the histories of the Deprecation header draft, of RFC 9745 and of the RateLimit header fields draft
W3C: Community Groups, their process, the contributor license agreement, the final specification agreement
OpenTelemetry: contributing to semantic conventions, project management
Model Context Protocol: proposal guidelines, governance, roadmap, working and interest groups, the proposal index
Agent2Agent: extensions, extension governance, project governance
Agentic AI Foundation: the working group, its charter, its pull requests
IETF OAuth: the working group, Transaction Tokens, the authorization grant, Identity and Authorization Chaining Across Domains, and each draft's history
OpenID Foundation: AuthZEN, its charter, its specifications, intellectual property
Open Secure AI Alliance: SAFE version 1.0, the working group, working group formation, contributing

4The requirements themselves

The requirements are cited, not standardized. R1 to R9 are stated in the paper Whose law was that?, and D1 to D7 in the paper You already think about law. Each says what must be true and never how, and each cites the passage of its paper it rests on. Every mechanism names, by number, the requirements it meets; a venue that takes up a mechanism can cite them the same way, or meet them in a text of its own without naming them. They stay with the argument they rest on, so an objection to one is an objection to that argument, and to no venue.

The one de jure route named here is the one SPDX took, ISO/IEC JTC 1, read on its own pages on 25 October 2026. SPDX reached it a decade after its community text, once the text was stable and a body stood ready to submit it. It is the precedent for where a mechanism could end, not a near-term step for any mechanism here, and not a route for the requirements, which are cited.

Venue	What it would standardize	How decisions are made	IPR terms	Typical time	Where things stand	Risks
ISO/IEC Joint Technical Committee 1 (JTC 1), information technology, the route SPDX took	A de jure standard for a mechanism's format, after a community text exists, by the route SPDX used: its timeline records that the Linux Foundation agreed to have the Object Management Group's Architecture Board approve the model and then submit it jointly to ISO by the fast-track procedure for publicly available specifications.	JTC 1 is a consensus-based, voluntary international standards group, and its experts represent their nation's standards body. It publishes a list of the organizations approved to submit publicly available specifications to it.	The common patent policy of the International Telecommunication Union, ISO and IEC asks participants to disclose the patents they know of, and a holder may declare itself willing to negotiate licenses free of charge, on a non-discriminatory basis and on reasonable terms. Copyright in the published standard: not read for this paper.	SPDX's record: specification 1.0 in August 2011, version 2.2.1 prepared for submission to ISO in August 2020, and ISO/IEC 5962 available in August 2021. Ecma lists the first edition of its CycloneDX standard, of June 2024, with the ISO/IEC number 27055 at the draft international standard stage.	Nothing started or filed.	In the one precedent it followed a stable community text and a sponsoring body by about a decade, and nothing on the venue's pages gives a shorter record.

The venue's pages read for this table

ISO/IEC JTC 1: home, publicly available specifications, approved submitters; the common patent policy; SPDX's timeline; Ecma's CycloneDX standard

5Status, how to take part, and disclosure

Status: Draft 1, 28 October 2026. The venues were read on their own pages on 25 October 2026, and the publisher's own posts at them were checked on 27 October 2026; a venue's pages change, and every entry is as read on those days.
Comments: open@lexlint.io. A correction from a venue to its own row is the most useful comment this paper can receive. There is no repository yet; one is opened the day a second organization wants to edit the text.
Taking part: The pages cited for each venue, listed in the fold under its table, say who may take part there and on what terms.
License: Creative Commons Attribution 4.0. Adopt it, fork it or improve it, with credit, without asking.
Disclosure: LexLint publishes both mechanisms this paper weighs. Its publisher is an Associate Member of the Linux Foundation, of the Agentic AI Foundation and of the Open Secure AI Alliance: section 3 weighs a working group of each of the last two, and the Linux Foundation hosts several of the other venues. Its publisher also posted the public comments that section 3 records in the rows for those two working groups, and is on the SAFE working group's roster, through a public pull request merged on 26 October 2026. While its publisher supports the mission of all three, none of them reviews, certifies or endorses LexLint or this paper.

About this options paperDraft 1, 28 October 2026ShowHide

Published by LexLint; written by Sean McDermott, Co-Founder and CEO, with AI assistance.

Draft 1 sets out option zero and the candidate venues for the repository declaration and for jurisdictional context, each venue read from its own pages, frames them with the order SPDX followed into a standard, and says why the requirements both mechanisms meet are cited rather than standardized. It recommends no venue.

© 2026 UnGovr, publishing as LexLint. This options paper, its text and its tables, is licensed under Creative Commons Attribution 4.0: adopt it, adapt it, translate it, carry it into another document or a standards body, including commercially, with credit to LexLint (UnGovr).