Skip to content
Purpose Source docs

Waivers

A waiver is a repository administrator’s power to excuse a named organisation from the licence’s condition, for that repository, on any terms or none. It is recorded in the public registry, and the beneficiary receives a signed waiver certificate.

Two properties are absolute, and both are never-reopen articles of the statutes:

Why publicity is not negotiable: an invisible waiver makes coverage unanswerable, and an unanswerable coverage question is exactly where side deals live. Publicity also protects administrators — a large organisation cannot lobby quietly for something that will appear in a public list.

What a waiver is, legally

Section titled “What a waiver is, legally”

The administrator is not licensing anyone’s copyright. The licence’s condition is already satisfiable by a recorded waiver, and everyone who licenses contributions under the licence accepts that — so granting a waiver causes an existing condition to be satisfied rather than granting a new right. That is why an administrator can do it without holding anyone else’s rights, and why the Association can record it without becoming a licensor (Art. 4).

The artifact the beneficiary receives is a waiver certificate: a signed statement of a recorded fact. It is never “a licence from the Association”, because the Association owns nothing to license.

Who may grant one

Section titled “Who may grant one”
  • Any verified administrator of the repository, proved through the registry’s claim flow. A designation made anywhere else — a repository file, a pull-request description, an email — has no effect.
  • An unclaimed repository has no waivers. Waiving requires the claim, because a legal power cannot hang on a file that anyone with push access could edit. This is an accepted trade for having one source of truth.
  • Every co-administrator is notified at grant and at revocation, and every action lands in a shared per-repository log. Disagreements among co-administrators are the project’s own governance: the registry records outcomes and never arbitrates.
  • Granting is a privileged operation: it requires a recent re-authentication, not merely a live session.

The cooling window

Section titled “The cooling window”

A waiver is effective immediately — the beneficiary is covered from the moment it is recorded — but permanent vesting attaches only when a 72-hour cooling window closes. Revocation inside the window voids the waiver from the start, so nothing vests.

The reason is a compromise scenario, stated rather than glossed: re-authenticating an administrator cannot detect an administrator whose account has been taken over. The cooling window removes the permanence of such an attack while keeping instant waivers usable. Repositories with several administrators may additionally opt into two-administrator approval.

Revocation, and what survives it

Section titled “Revocation, and what survives it”
  • Revocation is prospective only. It reaches versions published after the revocation, never what is already vested.
  • Vesting follows the same formula as every credential: a version is vested if its publication date falls on or before the end of the term — and for a waiver, “term end” means revocation or expiry.
  • The verify record keeps both the original coverage window and the revocation date, so a reader can see what was true when.
  • Revocation is recorded with a reason class, not a free-text accusation.

What a waiver does not give the beneficiary

Section titled “What a waiver does not give the beneficiary”
  • No impact claim. A waived organisation receives a licence-status certificate (“Purpose Source Licensed Organisation — waiver”) and never a supporter or impact certificate. It funded nothing, and a certificate implying otherwise would be a misleading claim under EU, UK, and Swiss rules — which is why the certificate type differs rather than the wording being left to good taste.
  • No coverage for other repositories. Waivers are repository-scoped. A conglomerate with waivers from four projects and none from the fifth is not covered for the fifth.
  • No warranty of anything. The same limit as an Entitlement: the credential attests a recorded fact, not that any code is free of third-party rights.

Asking for one

Section titled “Asking for one”

There is no waiver request form on this site, and that is deliberate: the decision is the project’s, not the Association’s, and routing requests through us would make us look like a gatekeeper of something we do not control.

  • Ask the project, in its own channels. Some repositories publish an address for exactly this in their PURPOSE.yml (contact.waivers), which the registry listing shows.
  • Say who you are, which repository, and why. “We are above the threshold and use this in a non-commercial internal tool” is a reasonable case; so is “we are a public-sector body with a procurement process that cannot buy this in this budget year”.
  • A refusal is normal and needs no reason. The power is granted on any terms or none.
  • Nobody may charge you, and if anybody offers to sell you one, report it — abuse route. That report leads to a delisting, and the delisting and its ground are published.

How to check a waiver

Section titled “How to check a waiver”
  • The global list: the waiver registry — searchable, and correctly empty until the claim flow opens.
  • Per repository: GET /v1/waivers/{node_id}.json, byte-exact passthrough of a published artifact — see the API reference.
  • A certificate: verify it yourself. The coverage answer a waiver produces is yes-via-waiver, and a waiver inside its cooling window still answers yes-via-waiver — the cooling window changes permanence, never coverage.

What is true today

Section titled “What is true today”

The claim flow has not opened yet, so no waiver has been granted and the registry correctly shows an empty list. The rules above are published now so they can be criticised before the first one is granted, and so nobody has to take on trust later that they were the rules all along.

Section titled “Related”