Leaving (quit)

Leaving is the adoption commit, reversed: change the licence file back. There is no notification duty, no exit interview, no exit fee, no minimum term, and nothing to cancel.

This page exists at the same depth and the same length as the adoption guide on purpose. A movement that makes joining loud and leaving quiet is selling a trap, so the exit is documented in the same detail as the entry, linked from it above the fold, and kept honest about the one thing an exit cannot undo.

The one thing leaving cannot undo

A payer keeps every version whose publication date falls on or before the end of their paid term — permanently. Your exit cannot strip a payer mid-deployment. That is not a concession extracted from you; it is the clause that makes the licence buyable at all, and without it nobody would buy and there would be nothing for your project to route.

The exit, step by step

1. Change LICENSE back to whatever you want the project’s future releases to be under — the licence you used before, or any other you have the right to apply.
2. Keep every inbound notice. The notice-preservation duty does not vanish with the licence: third-party notices that arrived with code under other terms stay, exactly as they had to while you were adopted.
3. Delete PURPOSE.yml if you have one. It is operational metadata only, so removing it changes no legal position — see the manifest reference.
4. Say so in the release notes. Not required by anything, but your users are the people who will notice, and they will notice from the diff if you do not tell them.
5. Nothing else. No form, no account to close (there may never have been one), no settlement.

What happens to your registry entry

	On quit
Repository record	Stays at its permanent URL with state quit and the date. It is not deleted: a record that vanishes makes the registry’s history unreliable for everyone else
Badge	Goes neutral — grey, “status: see registry”. A stale badge never keeps asserting registration, and the edge cross-checks the state on every request so even a cached badge cannot lie
Search and listings	The project drops out of “registered” facets and appears in the state it is in
Waivers you granted	Stop applying to versions published after the exit; they keep vesting what they had already vested, per the waiver’s own term
Past ledger rows	Stand, unchanged. They record what happened. An append-only ledger cannot un-record a quarter
Certificates naming your project	Keep verifying. They attested a fact at a time, and that fact did not stop being true

Relisting later is the same act again in the other direction: commit the licence file, and the next build picks it up. Quitting is not a black mark and is not counted as one anywhere.

Vesting consequences, precisely

The formula is the same everywhere it appears — in the licence text, in the Entitlement terms, and on every certificate:

A version is vested if and only if its publication date falls on or before the end of the paid term.

Applied to an exit:

• Versions published before your exit, for a payer whose term had not ended: vested, permanently. Your exit changes nothing about them.
• Versions published after your exit: under whatever licence you moved to. The Purpose Source condition does not reach them, and neither does any Entitlement.
• A payer mid-term when you leave: keeps what it vested; gets no refund from you, because it never paid you — the Purpose Fee is paid to the Association under a separate contract, and routed as net proceeds under the published cap.
• Your own future releases: entirely yours. Nothing in the licence claims a continuing interest in your project, because the Association never held one (Art. 4 of the statutes).

The parts of adoption that survive the exit

Stated plainly, because “you can leave any time” is only honest if the exceptions are named:

• Old releases keep the licence they shipped under. Everything you published while adopted stays published under those terms, forever. This is symmetrical: adoption could not reach backwards either.
• The four-year conversion keeps running on every version published while you were adopted. Each becomes Apache-2.0 on its own fourth anniversary, whether or not you are still adopted, and whether or not the Association still exists.
• Vested versions stay vested, as above.
• A fork of any published version remains possible on the terms of that version, exactly as it was before you adopted.

The fork question, on exit

The same permissive mechanics that let you convert also let anyone fork the last release under its own terms. Empirically the fork materialises for projects with heavy corporate gravity and almost never for small and mid-sized ones — but the honest statement is that leaving does not close that door, and neither does staying.

If your reason for leaving is community pressure, the exit is the right tool and this page is not going to argue with you. If your reason is that the money never arrived, that is a fact worth reporting to hello@purposesource.org before you go: the kill criteria are pre-registered precisely so that a movement that is not working stops rather than persists.

Why there is no penalty

Because a penalty would be a lie about what this is. The Association is a registrar and a witness, not a vendor with a contract over your repository: it holds no rights in your code, signs nothing with you at adoption, and has nothing to charge you for leaving. The registry follows the repository — it does not own it.

The only thing the design defends is the payer’s certainty, and it defends that in the licence text rather than in a duty imposed on you.

Related

• Adoption guide — the same journey in the other direction
• PURPOSE.yml reference — what the optional manifest does and does not do
• Waivers — what happens to waivers you granted
• What we can never do — including stripping a vested version