OpenRoots

Certification

Three of these are permanently closed to us. One is worth having.

A registry that stays quiet about its own certification status invites the reader to assume the flattering answer. This page states the position on every recognised body, including the three that will never accept these instruments and the reason no amount of redrafting changes that.

SPDX

Earnable

A machine-readable licence identifier

The one that actually matters, and it is open to us

An SPDX identifier is what makes a licence legible to software bills of materials, dependency scanners, package managers, and corporate compliance systems. Without one, an instrument is invisible to the automated tooling that decides whether a company is permitted to install anything at all. Every source-available licence OpenRoots is compared against carries one.

The gate
Actual, substantial use such that the licence is likely to be encountered. This is an adoption gate, not an ideological one, which is why it is earnable rather than blocked.

Blue Oak Council

Open

A peer rating of licence quality

Available, lighter lift than approval bodies

Blue Oak publishes ratings of licences assessed by practising lawyers, graded on clarity and on how comfortably a company can rely on the text. It is a credibility signal rather than a certification, and it does not require open source compliance.

The gate
Submission and review. No adoption threshold is published.

Free Software Foundation

Blocked

Listing as a free software licence

Closed because the grant is not freedom to run for any purpose

The royalty is one conflict. The separately licensed AI Training Use and competing-offering restriction also prevent freedom to run and redistribute for any purpose.

The gate
A materially permissive or copyleft grant without Sections 4, 5, and 6 could be considered; ORL 1.1 cannot.

Debian

Blocked

Acceptance under the Debian Free Software Guidelines

Closed, and the cautionary case is instructive

Debian effectively requires compliance with the Open Source Definition for inclusion in main. The Server Side Public License was rejected by Debian, Red Hat, and Fedora, and that rejection did more damage to its adoption than any technical criticism of the text.

The gate
A DFSG-compatible variant would need to remove the royalty and the field, use, and competing-offering restrictions.

GitHub and choosealicense

Follows SPDX

Automatic detection of the licence in a repository

Becomes technically detectable after SPDX; listing remains downstream

An SPDX identifier makes standard detection possible, but it does not guarantee that every product or curated catalogue will display or recommend the licence. Each downstream service controls its own release and inclusion policy.

The gate
SPDX first, then verify each downstream implementation independently.

The SPDX criteria, and the one we fail.

Five requirements are definitive. 4 are satisfied today. The fifth is the entire gate, and it cannot be met by writing anything.

  1. 01 The text must not match a licence already on the list under the SPDX matching guidelines.

    No existing instrument combines a revenue threshold, a capped royalty, a no-fallback source-available continuity rule, a separate training licence, and an all-licensee competing-offering restriction. The comparison across thirteen licences identifies the unmatched combination.

  2. 02 The licence must not apply only to executables without source availability.

    Section 2.1 grants the right to use, reproduce, modify, and distribute the Work, and Section 8.1 requires the notice to travel with every copy.

  3. 03 The licence must have identifiable and stable text, and must not be in the midst of drafting.

    All four instruments are complete at version 1.1, each with sixteen sections and a fixed effective date. Version 1.0 remains frozen and reachable. Open legal questions are published alongside the text as a separate register, so the text itself carries no pending edits.

  4. 04 The licence steward must commit to not modifying the text and to versioning future changes.

    Section 16.2, identical word for word across all four instruments. A published version is never edited. A correction is issued as a new version, and every earlier version remains reachable at its canonical address permanently.

  5. 05 There must be actual, substantial use such that the licence is likely to be encountered.

    Twelve public first-party repositories carry archived 1.0 instruments. The committee additionally reports thirty private repositories, but that count is not independently verifiable. There is no public third-party adoption and no public adoption of current 1.1 terms.

SPDX is not an open source gate.

A common assumption is that an SPDX identifier requires open source approval. It does not. Of 733 licences on the list, a large share belong to source-available terms rather than open source ones.

Verified against list version e4c1f27, retrieved 2026-08-24.

IdentifierSteward
BUSL-1.1MariaDB

Delayed conversion, commercial restriction

SSPL-1.0MongoDB

Rejected by Debian, Red Hat, and Fedora

Elastic-2.0Elastic

Managed-service restriction

FSL-1.1-MITSentry

Fair Source, two year conversion

FSL-1.1-ALv2Sentry

The same instrument, Apache fallback

Parity-7.0.0Blue Oak Council

Strong reciprocal, source-available

PolyForm-Noncommercial-1.0.0PolyForm

Non-commercial restriction

Every identifier above is registered and none is approved by the Open Source Initiative.

The order this has to happen in.

Applying before the adoption criterion is met results in the request being closed, so the sequence is not a preference.

  1. 01Here

    Adoption first

    Real projects publishing under an OpenRoots instrument, with public repositories a reviewer can inspect. Nothing else can be attempted before this, and no amount of drafting substitutes for it.

  2. 02

    Submit to SPDX

    Through the SPDX Online Tool, naming adopting projects as evidence of substantial use. Review is conducted by the SPDX Legal Team via a public issue and on their fortnightly calls.

  3. 03

    Verify downstream detection

    After SPDX acceptance, test GitHub and other scanners individually. SPDX enables a standard identifier; it does not guarantee a curated listing or immediate product support.

See how the instruments compare on twelve dimensions