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 written into the statutes:

A published waiver lets both the organisation and anyone checking coverage see the same record. It also makes the project’s choices transparent.

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 of code it registers for others (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 holds no rights in the code it registers for others — and for a project the Association itself owns, a waiver is still the administrator’s act, witnessed and recorded, never a licence grant issued in the steward capacity.

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 keeps the record tied to verified repository authority.
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

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. A waiver revoked inside the window vests nothing, but revocation never makes earlier permitted use unlawful.

The window allows co-administrators to review a new waiver before its coverage becomes permanent, while making it usable immediately. Repositories with several administrators may additionally opt into two-administrator approval.

Revocation, and what survives it

Revocation is prospective only. It reaches versions published after the revocation, never what is already vested.
Once the 72-hour window has closed with the waiver still current, 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. A waiver revoked inside the window vests nothing.
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

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

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. A repository can name a public contact in its PURPOSE.yml (display.contact), but the registry does not read that file yet, so no registry page shows one today.
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

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

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.

Companies: buying and complying — the paid lanes, and when to ask instead
Adoption guide — claiming a repository, which is what unlocks waiver powers
Leaving — what happens to waivers you granted
What we can never do — including selling one