Adoption guide

Adoption is one committed licence file, and it is complete on merge. No account, no registration, no handover, no copyright assignment. This page is the long version of that sentence, including the checks worth running first — and the exit is documented at the same depth, one click away, at leaving.

Prerequisites

Five things, in the order they can stop you:

You hold administrative control of the repository, and you can represent that you have sufficient authority to adopt a licence for it. Copyright stays with the rightsholders; nothing here transfers rights to anyone.
The inbound licences permit it — the gate below. This is the one check that can make adoption impossible rather than merely inconvenient.
The project is not a widely redistributed library. Package registries and language distributions will not ship a conditionally licensed project, so this licence is explicitly not intended for libraries. Applications, services, tools, and infrastructure are its target.
You have weighed the contribution cost. Some employers and programme offices bar contributions to licences that are not OSI-approved. That cost is real, and this guide will not tell you it is zero.
Your community hears it from you, before they read it in a diff. There is a script for that below.

Not prerequisites: an account, a claim, a manifest, an email to anyone, or permission from the Association. The licence is fully operative without any of them.

The inbound-licence gate

Run this first.

List the licence history of your own repository, and separately your dependencies’ licences.
Permissive inbound (MIT, BSD, Apache-2.0) — proceed. You may convert future releases by commit without contributor consent, not because contributors implicitly agreed, but because permissive licences grant the right to redistribute within a work under different terms, provided the original notices are preserved. Preservation is a duty, not a courtesy: see the next section.
Copyleft inbound (GPL, AGPL, LGPL in a linked form) — stop. A copyleft obligation and this licence’s condition cannot both be satisfied by the same distribution. The paths are a dependency change, or explicit permission from the rightsholders, and neither is something a guide can shortcut. A per-contributor consent process is the honest route, and declining to adopt is a perfectly good outcome.
Unknown or mixed history — stop and get it reviewed. Adopting a licence over code whose provenance you cannot state is not a licensing decision, it is a liability.
Third-party contributions already in your history — those contributors licensed their work to you under the licence in force at the time. Adoption is forward-looking: it changes the terms of future releases, never of releases already published.

An optional sixth step, legally unnecessary for a permissive repository and communally wise for one with a large contributor base: ask anyway. Run a tracking issue, collect acknowledgements in public, and let the answer be visible. Nobody is required to, and a project that does is easier to defend later.

Notice preservation

Tooling adds the Purpose Source LICENSE and never deletes what was there.

Keep the previous licence text as a third-party notice for the pre-existing code — commonly as LICENSE-MIT, NOTICE, or a third-party/ directory, referenced from your readme.
Keep every copyright, patent, and attribution notice you received with any code you incorporated. The Purpose Source License carries the same duty forward, and adopting it never wipes an inbound notice.
Understand, and say out loud, what this implies: the pre-existing fragments remain extractable under their original terms by anyone diligent enough to separate them. In practice, for an evolving codebase, nobody does — but the honest statement is that the old grant did not evaporate.

The one file

LICENSE — the canonical text, byte-exact, plus the single canonical notice line. This is the whole of adoption.

# Fetch the byte-exact text and verify it against the published hash before committing.
curl -sS https://purposesource.org/license/PurposeSource-1.0-draft.txt -o LICENSE
curl -sS https://purposesource.org/license/PurposeSource-1.0-draft.json | jq -r .textSha256
sha256sum LICENSE
# the two hashes must match, character for character
git add LICENSE && git commit -m "Adopt the Purpose Source License"

Do not reflow it, do not add a preamble, do not parameterise it, do not translate it in place. One canonical text with zero variants is the reason a programme office reviews this category once instead of once per project — and the licence’s name may be used only for the unchanged text.

The optional second file

PURPOSE.yml — optional, and the normal case is not to have one. It carries operational metadata only: display fields, cause-category defaults, a weight-class request, attribution exclusions, and an address for waiver requests.

# PURPOSE.yml — operational metadata only. The LICENSE file governs.
schemaVersion: 1
display:
  summary: A command-line client for the public registry.
causes: { education: 50, research: 30, health: 20 }   # advisory; must sum to 100
weight: { requested: infrastructure }                  # a request, reviewed
attribution:
  exclude_paths: ['vendor/**', '**/*.generated.ts']
contact: { waivers: opensource@example.invalid }

The rule that makes it safe: any legal-looking field in it is an informational mirror, non-authoritative — the LICENSE file governs. A file anyone with push access can edit can never designate a legal role. Every field, its default, and the constraints are in the PURPOSE.yml reference.

What adoption changes, precisely

Stays the same	Changes
Source is public; anyone can read, learn, fork, modify	Organisations above the threshold need a current entitlement to use new releases
Issues, discussions, and pull requests work as before	Your repository can appear in the public registry once you claim it
Free for individuals, students, nonprofits, and organisations below the threshold	Your project accumulates a public record of fees routed to public-benefit causes
You control merges, roadmap, and releases	A published fee schedule applies — you never set prices
Contributors keep their copyright; no assignment, ever	Contributions arrive under the new licence from the adoption commit onward
Every already-published release keeps its old licence forever	Each new release converts to Apache-2.0 four years after its own release date

The fork question

The same permissive grant that lets you convert lets anyone fork the last permissive release and continue it. This is the honest risk of adoption and it deserves a paragraph rather than a footnote.

Empirically the hostile fork materialises for projects with heavy corporate gravity — the ones whose dependents have the engineering budget to maintain a fork — and almost never for small and mid-sized projects.
Assess your own gravity: how many organisations depend on you commercially, how replaceable your maintenance is, and whether a competitor would gain from a fork existing.
What reduces the risk: adopting at a version boundary with a clear rationale, publishing the reasoning, running the consent process even where it is not required, and being visibly reachable about waivers.
What does not reduce it: a licence clause. Nothing in any licence can prevent a fork of code already released permissively, and any project telling you otherwise is wrong.

The choice is yours, and it is reversible for the future but not for the past — which is true of the fork risk in both directions.

Telling your community

Say it plainly, in the release notes and the readme, including the part that costs you something:

what changed, and from which version;
that everything they do stays the same — public source, forks, pull requests, free for individuals, nonprofits, and organisations under the threshold;
that no copyright assignment is involved — they keep their copyright, with a one-line sign-off as the designed default and the instrument confirmed by counsel;
that some employers bar contributions to licences that are not OSI-approved, and that this is a real cost you have weighed rather than a risk you are hiding;
that every version becomes Apache-2.0 four years after its own release, in the licence text;
where the money goes, with the link, rather than a summary of it.

The wording is yours; the honesty is the requirement. A page for contributors that answers the same questions is contributors.

Claiming the listing (optional)

The licence is fully operative without this. Claiming adds the verified registry listing, the badge, and the power to grant waivers.

Sign in with the repository host, at minimal scope.
The registry verifies through the host’s API that you hold administrative permission on the repository.
One click-accept of the claim terms — the only place administrator-side terms live: the dashboard relationship, waiver issuance, certificates naming you, the “I have sufficient authority to adopt this licence here” attestation, and the delisting-and-appeal process. Never in the LICENSE, never in a pull-request description.
The repository moves from detected adopter (an aggregate-only public statistic) to a verified listing with a badge.

Re-designating who holds the Project Steward role happens only through this flow. A designation in a repository file has no effect, by design.

The claim flow opens in a later phase; the terms it will carry, in substance, are summarised in the terms of use, section 4.

Weight class

Weight class scales how a project’s share of routed funds is computed relative to other registered projects. Three classes: library, application, infrastructure.

You request a class in PURPOSE.yml; you never grant yourself one. Self-granted weight would be an attribution exploit within a week.
Requests are reviewed against published criteria — dependent count among registered projects, whether the project is a build-time or runtime dependency of others, and substitutability.
The default is library. A decision, and its reason, is recorded on the repository’s registry page.
The criteria and the algorithm version that consumes them are on algorithms and schedule versions.

The badge

A badge is a shields.io endpoint, so a readme can embed it directly:

[![Purpose Source](https://img.shields.io/endpoint?url=https%3A%2F%2Fapi.purposesource.org%2Fbadge%2FR_kgDOEXAMPLE01.json)](https://purposesource.org/registry/repo/R_kgDOEXAMPLE01)

The endpoint answers registered for a claimed, adopted repository.
A stale badge never keeps asserting registration. A repository that quit, was delisted, or was suspended answers the neutral grey form — “status: see registry” — and the edge cross-checks the state on every request, so even a cached badge cannot lie.
An unknown repository answers with an honest “not registered” label rather than a broken image.
Badge and endpoint details: the API reference.

After adoption

Nothing is due from you. There is no reporting duty, no renewal, and no fee for a project.
Coverage questions from organisations are answered by published artifacts, not by you.
Requests to sell a waiver should be reported: abuse route. Selling one is a delisting offence.
If you want to leave, leaving is the same act reversed, with no penalty.

Leaving (quit) — the exit, documented at parity
PURPOSE.yml reference — the optional manifest in full
Waivers — the power a claim unlocks
Contributors — the page to point your community at
OSPO and legal pack — for the reviewer who will be asked to approve it