OpenRoots

SPDX

SPDX is the achievable certification, and the more useful one.

An SPDX identifier is what makes a licence citable in a bill of materials. It does not require the licence to be open source, and a large share of the identifiers on the list belong to source-available terms. This page records where OpenRoots stands on getting one.

Identifiers proposed
4
Hard criteria
5
Currently met
3
Blocked
1

Criteria

Where each criterion stands.

Five are hard requirements. The sixth is soft, and it is the one adoption answers rather than drafting.

met

Is the licence substantively different from every identifier already on the list?

No listed identifier combines a revenue-triggered royalty, a no-fallback source-available continuity rule, a separate AI training licence, a competing-offering restriction, and an artifact-specific instrument family.

met

Is the licence text publicly available at a stable address?

Every version is published at a canonical URL, in HTML and as canonical plain text with a published SHA-256 digest.

partial

Is the text identifiable and stable, rather than in the middle of drafting?

The 1.1 text is complete and published with a SHA-256 digest for each instrument. Section 16.2 forbids editing a published version, so 1.0 remains frozen and reachable while 1.1 carries the current corrections.

met

Has OpenRoots committed not to modify a published version in place?

Section 16.2 of every instrument, word for word: a published version of this Licence is never edited. A correction is issued as a new version, and every earlier version remains reachable at its canonical address permanently.

blocked

Does an identifier require the licence to be an open source licence?

No. The Canopy royalty conflicts with free redistribution, while Sections 4 and 6 independently restrict competing commercial use and AI Training Use. These are design decisions, not drafting oversights.

partialsoft criterion

Does the licence see actual, substantial use such that it is likely to be encountered?

Twelve public first-party repositories carry archived 1.0 instruments. The committee reports 30 additional private repositories, but that count is not independently verifiable. No public third-party project and no public project on current 1.1 terms is recorded.

Identifiers

What is proposed, and what to use today.

ProposedFull nameCanonical textUse today
ORL-2.2OpenRoots License 2.2legalcode.txtLicenseRef-OpenRoots-ORL-2.2
ORD-2.2OpenRoots Data License 2.2legalcode.txtLicenseRef-OpenRoots-ORD-2.2
ORM-2.2OpenRoots Model License 2.2legalcode.txtLicenseRef-OpenRoots-ORM-2.2
ORA-2.2OpenRoots Agent License 2.2legalcode.txtLicenseRef-OpenRoots-ORA-2.2

Before an identifier exists

LicenseRef is correct SPDX and costs nothing to migrate.

SPDX defines LicenseRef- for licences that are not on the list. Using it is correct today and costs nothing to migrate later, because a granted identifier simply replaces the LicenseRef string.

PackageLicenseDeclared: LicenseRef-OpenRoots-ORL-2.2

SPDXRef-DOCUMENT describes the package; the LicenseConcluded field carries the LicenseRef, and an ExtractedLicensingInfo section carries the full text and its canonical URL.

A full SBOM fragment is on the templates page.

Process

What a submission actually involves.

Six steps in the order SPDX asks for them. Step four is the one most submissions underestimate.

  1. 01

    Confirm the licence is not already listed

    Search the SPDX licence list and the pending-request queue for anything substantively equivalent. A near-duplicate is refused, and the closest neighbour has to be named in the request.

    Artifact

    A short comparison naming FSL-1.1-ALv2, BUSL-1.1 and Elastic-2.0 and stating what differs.

  2. 02

    Publish the canonical text at a permanent address

    SPDX records a canonical URL per identifier and expects it to keep resolving. A licence whose text moves is a licence SPDX cannot reference.

    Artifact

    The legalcode.txt endpoint, plus the published SHA-256 for each version.

  3. 03

    Open a request on the SPDX licence-list issue tracker

    The request carries the full name, the proposed short identifier, the canonical URL, and the text itself. Ours states plainly that it is source-available rather than open source.

    Artifact

    One issue per instrument on spdx/license-list-XML.

  4. 04

    Supply the licence XML with matching markup

    SPDX stores each licence as XML with optional and replaceable text marked up, so that a scanner can match a real-world copy that differs in whitespace, a year, or a licensor name.

    Artifact

    ORL-2.2.xml and siblings, with alt and optional markup on the licensor, date and threshold fields.

  5. 05

    Provide test text

    A plain-text file used to verify that the matching markup actually matches. Without it the XML cannot be validated.

    Artifact

    One test file per identifier, drawn from a real adopting repository.

  6. 06

    Answer the legal-team review

    The SPDX legal team reviews on a roughly monthly cadence and asks questions in the issue. Responsiveness is itself part of the assessment.

    Artifact

    A named contact who answers in the thread.