Adoption guide

The intended adoption step is one unchanged LICENSE file. No application to the Association, signature, account, annual renewal or ongoing report is required simply to use the licence. The Association handles the shared funding administration; you keep running your project.

Prerequisites

As with any licence change, check that you have the rights to apply it, keep the notices that came with existing code, and choose the first release to use the new terms. Tell contributors and users what is changing. Your project’s contribution and distribution policies still apply.

These are checks on the code and its existing permissions, not an Association application process. Leaving is equally straightforward for future releases.

The inbound-licence gate

Review your repository’s licence history and its dependencies separately:

Code you own: you can choose its future licence, subject to any rights or commitments already granted.
Permissively licensed code: licences such as MIT, BSD and Apache-2.0 generally allow redistribution within a work under different terms while requiring preservation of their notices and other conditions. The original grant remains available for that code.
Copyleft or mixed code: review the actual combination and its obligations. You may need rightsholder permission, a different dependency or a release that excludes the affected code. Do not assume that a licence change on the repository resolves compatibility.
Unknown provenance: establish the permissions before changing the terms.

An optional public discussion or consent-tracking issue can help a community make the decision together. A change does not reach backwards to releases already published.

Notice preservation

Keep the original copyright, patent, attribution and licence notices for incorporated code. An existing licence text can live beside the new LICENSE file, for example in NOTICE, LICENSE-MIT or a third-party notices directory, with a clear reference to the code it covers. A new project licence does not erase those obligations.

The one file

Commit the canonical text of Purpose Source License 1.0, unchanged, as LICENSE or LICENSE.md. There are no per-project fields to fill in. The Association’s identity and registry address are constants of the shared licence.

The licence page provides the exact text and its SHA-256 hash. Verify the bytes before committing. Use the published version, Purpose Source License 1.0. The adoption helper on the project page linked below hands you exactly that text. If an adoption pull request proposes any other text, do not merge it; commit the canonical text instead.

Do not add a preamble or edit the clauses. A translation may sit alongside as a non-authoritative reading aid; the canonical English text remains authoritative. Keeping one text makes review consistent across projects.

The project page provides the adoption tools. A suggested change is reviewed and committed under your own repository identity.

The optional second file

PURPOSE.yml is optional. Its published format can carry display information, advisory category defaults (allocation.defaults, a list of category slugs), bounded attribution exclusions and overrides, a successor designation and informational mirrors of the licence. It has no weight-class field, it does not change the licence, and it assigns nobody a legal role.

The registry does not read the file yet, so committing one changes nothing today. The manifest reference lists every field and says what the registry reads from it.

What adoption changes, precisely

Stays familiar	Added by Purpose Source
Public code and ordinary repository collaboration	Covered use by larger organisations requires an Entitlement, waiver or other recorded permission
Forks, modifications and redistribution	The Purpose Source component keeps its coverage condition; your other code does not inherit it
Free use for individuals acting for themselves and organisations below both thresholds	Fees from larger users support listed public-benefit recipients after published costs
Your team controls merges, roadmap and releases	The Association administers the shared schedule and public funding records
Contributors keep their copyright	No copyright assignment to the Association
Earlier releases keep their original terms	Each new Purpose Source release becomes Apache-2.0 after four years

The licence conditions its copyright and patent grants for larger organisations, with one carve-out: non-production evaluation, security review and preparing and submitting contributions need no credential (section 4). The review pack explains this distinction.

The fork question

A previous permissive release remains available under its original terms, including to people who want to maintain a fork. Purpose Source releases may also be forked under their terms, and each converts to Apache-2.0 after four years. That continuity applies when joining and leaving alike.

Telling your community

A short release note can explain the essentials:

the first release affected and the reason for the choice;
continued public code, collaboration and contributor copyright;
the coverage condition for larger users;
which public-benefit causes fees support and where the records appear;
each release’s four-year conversion and the project’s ability to leave for future releases.

Link to the comparison, the contributor guide and the canonical text. Contributors can start with the discussion proposal.

Claiming a repository (optional)

Adoption, registration and a claim are separate. A repository under the unchanged licence text is registered once the platform’s checks find it, and a registered repository is listed, with its own page and badge, whether or not anyone claims it. A claim adds the administrators’ own powers: their statement of authority, waivers, their designations and the project dashboard. It never adds the listing, coverage or a money share. A claim is made on the platform:

Sign in through the repository host.
Verify administrative permission for the repository.
Accept the claim terms, covering the platform relationship and authority for that repository.

None of this is live yet. No repository is registered or listed, no registration badge is shown and no waiver can be granted until the public registry and the claim flow are live.

The claim does not transfer ownership of the code. A Project Steward designation belongs in this verified flow, not in a file that anyone with push access can edit. The terms of use describe the relationship. Availability follows the platform’s published stage.

Weight class

A repository’s weight class is one of two, Standard and Major, and every repository is Standard until a change is recorded. Administrators never set prices; the weight class is the only pricing input they touch. A move to Major is requested on the project dashboard, with a justification, and takes effect only when the steward approves it; a move back to Standard is immediate. The class in force is shown on the repository’s registry page.

PURPOSE.yml has no weight field, and the registry does not read the file yet: no file can request or grant a class. A class is not a licence restriction, and it says nothing about whether a dependency combination is compatible.

The badge

The badge comes with the public registry, which opens with the first registered projects. It asserts registration only for a registered repository.

Once the registry opens, registered projects may display the official badge, linked to their current registry entry. It reflects the registry’s current state; a project that leaves, is suspended or is delisted displays a neutral status. Unknown repositories are marked not registered.

The API reference gives the endpoint format. The brand policy covers official artwork and links.

After adoption

There is no project fee, renewal or reporting duty simply for adopting. You continue using your usual issue tracker, contribution process and release workflow. The Association handles Entitlement sales and recipient administration; published records answer company coverage questions.

Optional platform powers, such as granting a waiver, have their own rules. You can leave at any time for future releases, with no exit fee or notice form. Read leaving for what continues to protect earlier releases and their users.