OSPO and legal pack

This guide brings the licence, coverage records and procurement references together for your review. It describes Purpose Source License 1.0, published by the Association on 2026-10-01. Counsel has not issued the text. Clause pointers below refer to Purpose Source License 1.0.

1. Classification

Purpose Source is source-available, not open source or OSI-approved. It combines public code and familiar collaboration with a coverage condition for larger organisations and conversion of each release to Apache-2.0 after four years.

A short entry for an internal policy table:

Source-available; size-based coverage condition; four-year conversion to Apache-2.0; no copyleft on other software, no source-disclosure duty and no audit right.

An organisation requiring OSI-approved terms for new dependencies should assess its approval process for this model. A converted release is reviewed under Apache-2.0.

2. Identifiers, scanners, and the “unknown licence” flag

The licence page publishes the current identifier and review status. Until an identifier is listed and supported by your tools, use a custom identifier and the exact text. Scanner recognition supports classification; it does not replace a policy decision.

What to do in the meantime:

In SPDX documents, use the custom identifier LicenseRef-PurposeSource-1.0 until PurposeSource-1.0 is listed (the request was filed on 2026-10-01), with the canonical text URL, https://purposesource.org/license/PurposeSource-1.0.txt, in licenseText or seeAlso. Do not map it onto a similar-looking listed identifier: a wrong identifier is worse than an unknown one, because it will be trusted downstream.
In CycloneDX, use the licence name plus a url pointing at the canonical text endpoint; leave id unset until a listing exists.
In a composition-analysis tool, add a policy rule keyed on the canonical text hash rather than on a name string. The hash is published on the version page and served in the metadata endpoint, and it cannot drift: the build fails if the served bytes and the pin disagree.
Policy exception, not policy violation. The clean configuration is an explicit exception keyed to (a) the licence’s canonical text hash and (b) your organisation’s signed entitlement record. Both are static documents; neither needs a key or an account.
Detection. The LICENSE file is byte-identical across every adopting repository, so a content hash is a reliable detector. The optional PURPOSE.yml manifest is non-authoritative and must not be used for licence detection — the LICENSE file governs.

3. Does my organisation need coverage?

The licence applies a dual size test across the consolidated group: the organisation and those that control it, it controls or that are under common control. Both conditions must hold for free use:

fewer than 100 people, employees and contractors counted together; and
revenue below one million US dollars in the latest completed tax year; the figure is not indexed, and other currencies convert at a published central-bank or IMF average rate, chosen consistently (section 5).

The threshold answer explains the figure. An individual acting for a larger organisation uses that organisation’s position, rather than an individual exemption.

Above either threshold, the Purpose Source software needs an Entitlement, waiver or another permission under the licence. The licence itself does not create a payment contract. The licence includes a 60-day cure period (section 6) and preserves already vested versions (section 9).

The group states its own revenue band when purchasing. The licence gives no audit or inspection right and no ongoing reporting duty (sections 5 and 10).

4. What exactly is conditioned?

The licence makes its copyright and patent grants subject to the Purpose Condition for the software (section 4). A larger organisation satisfies that condition through recorded coverage. Already vested versions remain covered (section 9), and each part becomes available under Apache-2.0 four years after it was first public, every part of a version no later than four years after that version (section 7).

The condition does not spread to your other code. Section 10 places no licensing condition on software you write or combine, link, host or ship with the component. It requires no publication of your source, internal architecture, deployments or customer information, and adds no network-copyleft or share-alike requirement.

That distinction matters for libraries: using a dependency does not require relicensing the surrounding application. Coverage of the Purpose Source dependency itself is a separate question. The licence contains no blanket transitive-use exemption; under section 4, incidental benefit and merely passing the software on do not count as use for an organisation.

Section 4 permits, without a credential, non-production evaluation, security review and preparing and submitting contributions; production use and offering the software’s functionality to others still need coverage, so this guide does not present copying or redistribution by larger organisations as unconditionally exempt. The licence text shows the scope.

Package registries and distributions have different rules. Check your actual channel; there is no blanket exclusion of libraries or package-registry publication. For example, NuGet supports a custom licence file in .txt or .md format. That is metadata support, not approval of this licence or every downstream use.

5. Term certainty

The licence sets out three continuity rules:

Permanent vesting. A version within the credential’s scope stays covered when its publication date is on or before the term end. Non-renewal, project exit or delisting does not remove that coverage.
Four-year conversion. Each release independently becomes Apache-2.0 after four years (section 7).
Steward lapse. The Purpose Condition lapses if the Association ceases to exist with no publicly designated successor, or goes twelve consecutive months without recording an Entitlement or publishing a dated statement in its transparency log that Entitlements could be obtained. It also lapses on the day named in a signed, published declaration of lapse (section 8).

The wind-down protocol covers public records and remaining funds. These are the licence’s specific continuity mechanisms, not a general guarantee about every legal or operational outcome.

6. Contribution policy

No copyright assignment, ever. Contributors keep their copyright.
The designed default instrument is a one-line sign-off, the same ceremony as a developer-certificate-of-origin sign-off. The final form of the instrument is confirmed by counsel; we do not pre-guarantee the ceremony, only the copyright position.
Inbound equals outbound: contributions are licensed under the project’s own licence, with no separate grant to the Association.
The sign-off carries a bounded forward delegation to materially consistent successor versions, with an enumerated immutable core it can never reach — the free-tier threshold may only widen, the conversion delay may only shorten, and the fund destination, the no-private-profit rule, the registrar character (never a rights-holder in code it registers for others), and the administrator’s gratis waiver power cannot be touched (Art. 13 of the statutes).

For work on an employer’s behalf, follow its contribution policy. The comparison is a short starting point for that conversation.

7. Evidence a review can attach

Artifact	What it proves	Where
Canonical licence text	The exact terms, byte-exact, hash-published	`/license/{versionId}.txt`
Licence metadata	Version, dates, conversion rule, SPDX status, text hash	`/license/{versionId}.json`
Signed entitlement record	That a named organisation holds a current entitlement	`/v1/entitlements/{companyId}.jws`
Certificate record	Status, period, scope of an issued certificate	`/v1/verify/{certId}`
Public key set	The keys the above verify against	`/jwks.json`
Waiver list	That a repository granted a named organisation a gratis waiver	`/v1/waivers/{nodeId}.json`
Registry record	A repository’s adoption state and licence version	`/v1/registry/repo/{nodeId}.json`
Bulk registry export	Every registered repository, one document	`/v1/registry/export.json`
Compliance export	Your own credentials as CSV, for the internal register	companies guide

Every one of those is a static, cacheable, unauthenticated document. There is no key to request, no contract to sign to read them, and no rate limit a normal review would notice.

The entitlement record, in shape

GET /v1/entitlements/{companyId}.jws returns a compact JWS with Content-Type: application/jose — three base64url segments, ES256. Decoded, the payload is the machine-readable coverage fact a policy engine needs:

{
  "schemaVersion": 1,
  "iss": "https://purposesource.org",
  "sub": "co_01j0000000000000000000002",
  "org": { "name": "Example Industries AG", "domains": ["example.invalid"] },
  "lane": "pass",
  "scope": { "kind": "pass", "repos": ["*"] },
  "period": { "validFrom": "2027-01-01", "validUntil": "2027-12-31" },
  "graceUntil": "2028-01-30",
  "vesting": { "rule": "version.publishedAt <= period.validUntil" },
  "iat": 1767225600,
  "cid": "cert_01j0000000000000000000001"
}

Header: { "alg": "ES256", "kid": "psn-prod-2026-1" }. Verify it against /jwks.json — the procedure, with WebCrypto and OpenSSL, is verify a certificate offline. The record is the proof; a screenshot of a page is not.

The registry API a review can script

All GET, all keyless, all ETag-honouring, all served from published artifacts with no database behind them:

# Is this repository registered, and under which licence version?
curl -s https://api.purposesource.org/v1/registry/repo/R_kgDOEXAMPLE01.json | jq '{state, licence: .license.id, version: .license.version}'

# Does this repository have waivers, and for whom?
curl -s https://api.purposesource.org/v1/waivers/R_kgDOEXAMPLE01.json | jq '.waivers[].organisation'

# What does the deployment say about itself, including the coverage algorithm version?
curl -s https://api.purposesource.org/v1/meta | jq '{coverage, contracts}'

Current interface: there is no computed coverage endpoint at this phase. The proof of coverage is the signed entitlement record plus the verification page; the computed endpoint is planned against the same eight versioned coverage answers. Full route set, cache behaviour, error envelope, and rate limits: public API reference.

8. The procurement pack

What to attach to a vendor-risk file, in the order a reviewer will want it:

The licence text and its hash — /license/{versionId}.txt and the SHA-256 from /license/{versionId}.json.
The classification line from section 1, verbatim.
The term-certainty summary from section 5 — the four clauses, with the conversion rule.
The steward’s own documents: statutes (with the protected provisions marked), Trust Center, documents register, security and subprocessors and residency.
The money mechanics, if your file asks where fees go: where the money goes — the fee stack, the cap, the ledger methodology.
The exit plan: if the activity stops — a stop only by two thirds of all members, for a serious published reason, with at least three months’ notice, and the wind-down protocol.
Your own credential, once purchased: the signed entitlement record, the certificate id, and the compliance CSV.
Review status and open questions — sections 10 and 11 below and the comparison page.

9. Publicity and official marks

Purchasers may describe their participation in their own words, in any language, without prior approval. They may name Purpose Source, link to its website and official social profiles, and use its official logos and coverage badges. Publicity is optional, and the Association does not undertake to monitor it.

The publicity and brand-use policy gives this permission and sets the rules for official artwork: preserve its appearance, link a coverage badge to its current verification record, and avoid false affiliation or deceptive and abusive uses of the marks. It does not require a script for other publicity. Purchasers remain responsible for their statements and permissions for others’ material.

The certificate policy explains what each class records and how to verify it.

10. Tax and accounting note

The Purpose Fee is structured as a software-licensing fee under a separate Entitlement purchase, not a charitable donation by the buyer. Paddle, our merchant of record, sells the Entitlement and handles applicable indirect taxes. Accounting and deduction treatment depend on the buyer’s jurisdiction and circumstances.

Purpose Source License 1.0 has no Donation Entitlement.

11. Review status and open questions

Purpose Source License 1.0 was published by the Association on 2026-10-01; counsel has not issued it. Counsel has not yet confirmed the text, in particular its section 4 scope, its silence on governing law and forum, and section 5’s revenue rules. The SPDX listing is requested, not yet granted. Those points are separate from the adopted running-cost and reserve caps of 15% and 5%, measured after payment-processor fees.

For project fit, review existing licences, contributor permissions, employer policies and the distribution channels involved. The shared text and signed records give reviewers a consistent basis across projects; they do not automatically approve the model for every organisation.

The documents register, licence page and published algorithms provide the source texts and current versions.

Companies: buying and complying — the mechanics of the purchase
Entitlement terms — what the credential is, and is not
Verify a certificate offline · Public API reference
Comparison page — shared features and practical choices