OpenRoots

Stewardship

Who publishes this, and what holds without us.

Three questions decide whether an instrument can be depended on. Who publishes it, whether counsel has reviewed it, and what happens to adopters if publication stops. The answers are a committee of developers with a board alongside it, not yet, and nothing changes, because the guarantee here is fixed public bytes rather than an institution that has to stay alive.

Governance
Committee and board
Instruments
4
Counsel review
None yet
Adopting repos
42

Direct answers

The questions a legal team asks first, answered up front.

Every answer links the page that proves it, including the answers that are no.

Who publishes these instruments?

A committee of working software developers, with a small board alongside it for the decisions that are not engineering decisions. The people who set the terms ship the kind of artifacts those terms govern, which is the point of the arrangement. Against that, the guarantee an adopter actually depends on is structural rather than institutional: published versions are never edited, every correction ships as a new version, and every canonical text carries a digest anyone can check.

/governance

Has external counsel reviewed the text?

Not yet, and that is stated here rather than left for an adopter to discover. The instruments were drafted by developers who had lived the failure each clause exists to prevent, and every design decision is published with the alternatives that were rejected. That is a different thing from counsel review and is not offered as a substitute for it. An adopter whose risk posture requires counsel should obtain their own before relying on any clause.

/review

What happens if OpenRoots stops publishing?

Nothing changes by time alone. The version an adopter received remains the governing version, and any copy can be checked against its published digest. No fallback conversion is triggered by silence. OpenRoots intends to preserve every canonical URL, and no publisher of any size can guarantee permanent hosting, so adopters should retain the canonical text and digest with each release. That is the same advice a prudent adopter follows with any licence.

Can a published version change under me?

No. Section 16.2 of every instrument states that 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. The published SHA-256 of the canonical text lets an adopter prove the bytes they hold are the bytes that were published.

/versions

Does OpenRoots tooling collect usage data or insert funding telemetry?

No. The website has no analytics, accounts, advertising, or session recording, and the configurator runs locally in the browser. OpenRoots licence files and generated notices contain no executable collection mechanism. If project infrastructure ever begins collecting data, disclosure must precede collection; a funding request is never a substitute for consent.

/privacy

How does enforcement begin?

For curable licence breaches, Section 10.1 requires written notice and a thirty-day cure period before rights terminate. Trademark mistakes begin with a correction request under the trademark policy. OpenRoots does not promise that every infringement is curable or waive remedies a Licensor may hold, but it does reject surprise termination as the ordinary compliance process.

/trademark

Who decides what goes into the next version?

The committee, after a public review window, with the board deciding the questions that are not engineering ones. Governance grows with adoption, so the structure is written down as it currently stands rather than as it might look later, and any change to it is published here with the reasoning.

/governance

Is this open source?

No. The Canopy tier requires a royalty above a revenue threshold, and clause 1 of the Open Source Definition forbids requiring a royalty.

/status/open-source

How do I report a defect in a licence?

Publicly, on the tracker, for anything that is a drafting error or an ambiguity. Privately, to info@openroots.org, for anything where public disclosure would create exposure for an adopter before a correction exists.

/report

Community evidence

What the research changed, and what it did not.

A raw discovery set covering 41 Reddit threads, 62 Hacker News stories, and 20 GitHub items was screened for recurring licensing and trust failures. Reddit collection was rate-limited, only 33 dated items were from the preceding seven days, and popularity was treated as discovery evidence rather than legal authority.

Items screened

123

From last 7 days

33

Decisions recorded

6

The set is noisy, unevenly sampled, and contains unrelated material. It cannot establish legal validity, market prevalence, or consensus. Each adopted response must also be supported by the instrument text or an explicit project policy.

ThemeObserved gapOpenRoots responseDecision
ClassificationUsers repeatedly confuse source availability with open-source approval.Every public status surface labels OpenRoots source-available and states the specific Open Source Definition conflicts.adopted
RelicensingSilent or unilateral licence changes impose downstream review and migration costs.Published versions are immutable, later versions are opt-in, and no or-later clause moves existing releases.adopted
CompetitionBroad noncompete language creates uncertainty about integrations, consulting, marketplaces, and customer deployments.Section 4 and the scenario explorer publish the prohibited acts, substitution test, and explicit carve-outs separately.adopted
Funding and privacyUndisclosed telemetry used for maintainer funding can erase trust in an otherwise useful dependency.OpenRoots keeps payment terms in the instrument and commits not to hide identity or usage collection in its tooling.adopted
EnforcementRestrictions without an understandable cure path increase legal-team risk and encourage defensive removal.Section 10.1 uses written notice and a thirty-day cure period for its listed curable breaches.adopted
Project failureDelayed-open advocates use automatic conversion as protection against abandonment or hostile stewardship.Declined for current releases. Continuity comes from fixed versioned grants, retained canonical bytes, and published digests, not a future permissive fallback.declined

Adoption

What the instruments are actually used on.

Named repositories are publicly checkable. The private count is a self-reported inventory, not independently verified adoption evidence.

Public, named

12

Private, counted only

30

Total

42

This adoption is first-party and the named repositories currently carry archived 1.0 terms, not the current 1.1 instruments. It proves application, not third-party acceptance. The private count is self-reported. Full breakdown on the adopters page.

Decision log

Every choice in the text, with the reasoning attached.

What was decided, why, and what was rejected on the way. It is published so you can argue with the actual reasoning instead of guessing at it.

  1. 012026-08-24

    State a numeric revenue threshold, rate and cap rather than a good-faith obligation.

    Creative Commons signals ask for support based on a good faith valuation taking into account use and financial means. OpenRoots instead states the Canopy threshold, rate, and cap so a finance team can compute that obligation without first negotiating what good faith means. This does not make enforceability automatic, and the separate Compute licence uses its own metric.

    Considered and rejected

    • Good-faith contribution, as CC signals does. Rejected because it does not provide the numeric calculation this project wants adopters to be able to perform.
    • Flat annual fee. Rejected because it lands hardest on the smallest paying adopter.
    • Per-seat pricing. Rejected because it has nothing to do with the value derived from the artifact.
  2. 022026-08-24

    Permit AI training, on terms, rather than forbidding it.

    A licence that forbids training gets ignored by exactly the parties it most wants to reach, and produces no compliance and no revenue. Permitting it under the Compute tier gives those parties something they can actually comply with, and gives the licensor a claim that is worth asserting.

    Considered and rejected

    • Blanket training prohibition, as several source-available licences do.
    • Silence on training, which is the current position of most licences and leaves everyone guessing.
  3. 032026-08-24

    Remove automatic fallback conversion from current releases.

    The project cannot claim durable commercial protection while also promising that the same work later becomes permissively licensed by time alone. Current releases keep OpenRoots terms unless a later version expressly changes future terms.

    Considered and rejected

    • Automatic Apache or MIT fallback. Rejected because it contradicts the fair-code business-protection model.
    • Renewal periods. Rejected because they create another deadline system without solving the core contradiction.
  4. 042026-08-24

    Protect the names, free the text.

    Anyone may adopt an instrument unmodified at no cost and with no permission. What is protected is the name: OpenRoots, the instrument names, and the tier names may not be placed on a different text. That is how a reader can trust that two artifacts saying ORL-2.2 carry the same terms.

    Considered and rejected

    • Fully public-domain naming, as MIT effectively has. Rejected because it lets anyone publish a different text under the same name.
    • Restricting use of the text itself. Rejected outright; it would defeat the purpose.
  5. 052026-08-24

    Decline the Ecosystem Contribution element from CC signals.

    Payment runs to the named licensor. An obligation owed to an undefined ecosystem cannot be enforced by anyone or discharged by anybody, which makes it a statement of values rather than a term.

    Considered and rejected

    • Adopt it as an optional element alongside the royalty.
    • Route a share to a commons fund, which would require a fund to exist first.
  6. 062026-08-24

    Keep funding transparent and separate from telemetry.

    Community disputes around undisclosed package telemetry show that maintainers can destroy adoption trust even when the stated purpose is funding. OpenRoots may publish optional support routes, but its site, licence files, notices, and configurator do not identify users or transmit usage data.

    Considered and rejected

    • Bundled sponsorship detection. Rejected because a financial purpose does not create consent to collect identity or usage data.
    • Mandatory donation prompts in generated artifacts. Rejected because payment obligations belong in the legal text, not in surprise runtime behavior.
  7. 072026-08-24

    Use notice and cure as the ordinary enforcement path.

    A commercially restricted licence needs credible enforcement, but an ambiguous boundary combined with immediate termination creates avoidable adoption risk. Section 10.1 therefore requires written notice and thirty days to cure the listed breaches before rights terminate.

    Considered and rejected

    • Immediate termination for every breach. Rejected as disproportionate for remediable notice, reporting, or classification mistakes.
    • Non-enforcement. Rejected because a restriction that will not be enforced should not be represented as protection.
  8. 082026-08-24

    Make new versions opt-in and prohibit silent migration.

    Repeated ecosystem relicensing disputes show that downstream users need to know whether terms can change after adoption. OpenRoots publishes fixed versioned text, has no or-later clause, and cannot move an existing release to a later version by changing the website or registry.

    Considered and rejected

    • An or-later grant controlled by the publisher. Rejected because it delegates future legal terms without review.
    • Automatic migration on a review date. Rejected because a calendar event is not adopter consent.

Contact

How to reach us.

Two routes. Public for anything that benefits from one visible answer, private for anything that would create exposure before a correction exists.

Public

Drafting errors, ambiguities, compatibility questions and review comments go on the public record so the answer is visible to everyone who has the same question.

/report

Private

Anything where public disclosure would create exposure for an adopter before a correction exists. Routed through info@openroots.org and answered before it is published.

info@openroots.org