Companies: buying and complying
This guide explains coverage for repositories released under the Purpose Source licence: which projects your organisation can use under an Entitlement, how to choose its scope and how to keep the coverage record. Browse the repository catalogue or start with the company overview.
The catalogue lists the registry’s published registration records. Project and Pass cover registered repositories within their stated scopes, so check the project’s registration record before relying on coverage. How the directory works.
1. First: does your use need coverage?
Section titled “1. First: does your use need coverage?”A dual test, measured across the whole consolidated group — the entity plus everything that controls it, is controlled by it, or is under common control with it, whether by ownership, votes, contract, or otherwise:
- fewer than 100 individuals working as employees and independent contractors, counted together; and
- total revenue below one million US dollars in the latest completed tax year (section 5; the figure is not indexed), converted at a published central-bank or IMF average rate, chosen consistently.
Both must be true to be below the threshold. If they are, you owe nothing, register
nothing, and hold no credential: the licence behaves permissively for you, and the coverage
answer is no-entitlement-required-under-threshold.
Above either threshold, use of the Purpose Source component needs recorded coverage unless another permission applies. The licence includes a 60-day cure period and keeps vested versions covered. It does not limit the size-based condition to releases published after the organisation grew.
2. The lanes
Section titled “2. The lanes”| Lane | Scope | Status |
|---|---|---|
| Project | Exactly one registered repository, chosen at checkout | Through checkout, at launch |
| the Pass | Every registered repository, present and future | Through checkout, at launch; by Paddle invoice above the card limit in the fee schedule |
The two scopes share one checkout and one published schedule. The signed record identifies the scope purchased.
Two schedule rules apply:
- The Pass covers all registered repositories. Compare it with the smaller scopes for your actual needs; its price is fixed by your revenue band.
- One published schedule for everyone. Prices are set only in the versioned fee schedule. Nobody — not a repository administrator, not the Association — agrees a private price, a discount, or a side term (Art. 11 of the statutes). A request for bespoke terms is answered by pointing at the amendment process: propose a change for everyone.
3. Bands and self-certification
Section titled “3. Bands and self-certification”Price depends on your band, which is a range of consolidated-group revenue. Every band’s price is published in the schedule, so its shape is predictable rather than negotiable.
You state your own band and confirm it at checkout:
- No audit or inspection right, and no ongoing reporting duty. These exclusions are part of the published commitments.
- Under-certification is a true-up. Certify low by mistake and the remedy is paying the difference for the period concerned. The Entitlement is voided only for a knowingly false certification, and a voided credential is recorded as voided, not deleted.
- Growth mid-term does not reprice the term. Crossing into a higher band takes effect at renewal.
- Your band is not printed in the registry record, but it is not secret. The ledger publishes the fee amount of each purchase, and against the published schedule an amount shows your lane and band. Nothing else about your revenue is published.
- You are named only if you ask. Tick List our organisation’s name publicly at checkout and your registered name appears on the list of covered organisations, in your signed coverage record and beside your ledger rows. Leave it unticked and you are listed as Unlisted organisation under a reference code that does not itself display your name. Your coverage, term dates and fee amounts remain public, and a domain you verify can connect that code to your organisation, so this does not guarantee anonymity. If your registered legal name is a person’s name, ticking publishes it.
4. Where your passed-on share is attributed
Section titled “4. Where your passed-on share is attributed”What is passed on of your Purpose Fee — after the published, capped costs of the fee stack — is attributed to registered repositories by the lane you bought, and from each repository it reaches the listed recipient organisations by the categories chosen for that repository, and otherwise under the allocation key the board publishes before each month. No project, contributor, owner or administrator ever receives any of it (Art. 5 of the statutes), and the attribution is advisory: the Association’s board decides finally (Art. 8 of the statutes).
- Project: all of your share is attributed to the one repository you chose.
- the Pass: naming the repositories you use is optional — name up to fifty, or none. Each named repository is attributed 1% of your share, and the rest is split equally across all registered repositories active at the lock, the named ones included. Name ten and ten percent is attributed to them while ninety percent is split equally; name none and all of it is.
- A repository that is not active at the lock — quit, suspended, delisted — drops out for that month: a Project’s share joins the equal split, and a named repository’s 1% returns to the equal split.
- A declaration is never published as a per-organisation list of dependencies — that would be a free dependency graph of your estate, which is nobody’s business.
- A declaration you get wrong is not a violation. It is set when you buy; a way to change it during a term comes with the dashboards on the roadmap. Coverage does not depend on it: a Pass covers every registered repository whether or not you named it.
- An honest note on incentives: a Project Entitlement’s coverage does depend on choosing the right repository. If you are unsure which repositories your build actually pulls in, the Pass removes the question, and that is a reason it exists.
What checkout asks, in order
Section titled “What checkout asks, in order”- Choose coverage and the revenue band. Project covers one registered repository; the Pass covers every registered repository and is the recommended, preselected option. You can choose either lane.
- Enter your details, confirm and continue to payment. Provide your organisation’s legal name and country. One required checkbox confirms your authority to act, the revenue band for your whole consolidated group in the prior tax year, and acceptance of the Entitlement terms and the refund policy in the Terms & purchase details. The full statements are on the purchase acceptance page. There is no audit or inspection right. Public naming is a separate, optional choice and starts unticked. Pass holders may also credit up to fifty favourite repositories they use. There is no separate review step.
Licence credentials are sold through our online reseller Paddle. Checkout opens at launch; no payment is taken before then.
What arrives, and what to check it against
Section titled “What arrives, and what to check it against”Issuance is asynchronous and ends with one message to the address you entered at checkout. It carries three things: the certificate PDF, its verification link, and the URL of your organisation’s signed coverage record.
Two properties make that delivery independently checkable:
- The link in it is not the trust path. The certificate is publishable before it is deliverable — its hash is in the transparency log first, which is what makes it checkable by anyone — so nothing in the message is required to verify it. Type the address in yourself: verify only at purposesource.org/verify. Any message offering a different verification address is not ours, and the message we send carries no click tracking that could rewrite one.
- A delivery failure never un-issues anything. If the mail bounces we retry to the billing contact registered with the payment provider, and the artifacts stay published and verifiable throughout — the record is not conditional on you having received a copy of it.
The offline verification procedure is the same one an auditor of yours would run, and it needs nothing from us.
5. Renewal, vesting, and lapse
Section titled “5. Renewal, vesting, and lapse”The formula, as the Entitlement terms and every certificate state it, per version:
A version is vested if and only if its publication date falls on or before the end of the paid term.
The licence itself (§9) vests per part rather than per version — a part is yours to keep once your credential covers it and it was public by the end of the term — and every part of a version public by the term’s end is such a part, so the sentence above never claims more than the licence gives. It can claim less: a part public before the term’s end but first released after it vests under §9 even though the sentence above does not reach it.
- At activation: the whole back catalogue of every covered project, plus everything published during the term.
- Renewal extends the term end into the next year’s releases. Terms are annual and renew automatically unless you turn renewal off, which you can do at any time before the renewal date; each renewal reminder gives the date, the price then in force and how to turn renewal off. The refund policy has the details.
- Vesting is permanent. Non-renewal, project exit, delisting, waiver revocation, and the Association’s own failure cannot reach a vested version. Lapse acts only on versions published afterwards.
- Grace: for 30 days after expiry the coverage answer is
lapsed-in-gracerather thanno. This registry status does not add 30 days to the licence’s cure period. The licence counts that separate period from the trigger days in its section 6; already vested versions remain covered. - Continuity: each version becomes Apache-2.0 no later than four years after it was first public (section 7). The licence also includes a steward-lapse backstop; its exact conditions are in section 8 of the licence.
6. The role of an Entitlement
Section titled “6. The role of an Entitlement”An Entitlement records that the organisation meets the licence’s coverage condition for the stated scope and period. The Association handles that record and the fee administration; the project’s licensors and stewards remain responsible for their code under the applicable terms.
The purchase does not transfer code ownership or provide IP indemnity. The covenants about past use come from the Association and the project’s steward of record only; they do not release claims belonging to other contributors. The purchase terms state these boundaries in full.
7. Waivers — the free path, when a project offers it
Section titled “7. Waivers — the free path, when a project offers it”A repository’s administrator may grant your organisation a gratis, public waiver for that repository. If you are asking whether to buy or to ask, ask first: it costs nothing to ask and the answer is public either way.
- Waivers are always public and always gratis. Selling or brokering one is a delisting offence (Art. 10).
- They are repository-scoped and revocable prospectively only, and they vest by the same formula with “term end” = revocation or expiry.
- A waived organisation gets a licence-status certificate (“waiver”), never a supporter or impact certificate. You funded nothing on that path, and a certificate that implied otherwise would be a misleading claim.
Full rules and how to ask: waivers.
8. The compliance export
Section titled “8. The compliance export”For an internal register or an auditor’s request, the registry exports the coverage facts as CSV. The shape is stable and additive-only.
The sample below is illustrative — sample rows, not a record of any organisation — and no amount in it describes a real transaction:
# purpose-licenses.csv — illustrative sample, not a record of any organisationentitlement_id,organisation,lane,band,period_start,period_end,status,fee_amount,fee_currency,repos_scope,certificate_id,verify_url,entitlement_recordent_01j0000000000000000000000,Example Industries AG,pass,10-50M,2027-01-01,2027-12-31,active,3500,USD,*,cert_01j0000000000000000000001,https://purposesource.org/verify/cert_01j0000000000000000000001,https://api.purposesource.org/v1/entitlements/co_01j0000000000000000000002.jwsent_01j0000000000000000000003,Example Industries AG,project,10-50M,2026-11-01,2027-10-31,active,700,USD,R_kgDOEXAMPLE01,cert_01j0000000000000000000004,https://purposesource.org/verify/cert_01j0000000000000000000004,https://api.purposesource.org/v1/entitlements/co_01j0000000000000000000002.jwsent_01j0000000000000000000005,Example Industries AG,waiver,,2026-09-15,,active,,,R_kgDOEXAMPLE02,cert_01j0000000000000000000006,https://purposesource.org/verify/cert_01j0000000000000000000006,Column notes, because a CSV that needs a phone call is not an export:
| Column | Meaning |
|---|---|
entitlement_id | Stable identifier of the credential |
lane | project · pass · waiver |
band | Empty for a waiver, which has no price |
period_end | Empty for a waiver, which ends on revocation rather than on a date |
status | active · lapsed-in-grace · expired · revoked |
fee_amount / fee_currency | Empty for a waiver; integer major units plus an ISO code |
repos_scope | * for the Pass, otherwise repository node ids, semicolon-separated |
verify_url | The one place a certificate is verified. verify only at purposesource.org/verify |
entitlement_record | The signed record a scanner can verify offline against the published key set |
9. SBOM and scanner note
Section titled “9. SBOM and scanner note”- In an SBOM, record the project’s licence exactly as its
LICENSEfile states it. Until an SPDX identifier is listed, that means aLicenseRef-style custom identifier in SPDX documents, or the licence name plus the canonical text URL in CycloneDX. Do not map it onto a similar-looking identifier: a wrong identifier is worse than an unknown one, because it will be trusted. - Your entitlement is not an SBOM field. SBOM formats describe components, not your organisation’s credentials. Keep the signed entitlement record and the export above in your compliance register, and reference them from the policy exception rather than from the bill of materials.
- Scanner policy. The signed entitlement record is designed to plug into a policy engine: it is a static, unauthenticated, ETagged document that answers “does this organisation hold a current credential?” without a key, an account, or a rate limit a normal review would notice. Guidance for configuring the exception, and the “unknown licence” flag you will see until listing, is in the OSPO and legal pack.
Related
Section titled “Related”- Fee schedule — bands, lanes and the fee stack
- OSPO and legal pack — classification, evidence, and publicity and brand use
- Entitlement terms — the contract’s substance
- Waivers · Public API reference · Verify a certificate offline
- Where the money goes — the fee stack, the cap, and the ledger methodology