Skip to content
Purpose Source docs

Contributors

Same pull request. The workflow does not change, the review does not change, and your copyright does not move.

What is added is a record: a merged contribution earns an attributed Impact Share under a published, versioned algorithm, an advisory choice among the seven public-benefit categories, and a signed certificate you can verify yourself. What is not added is money, in any form, to you — and that is a structural bar, not a policy.

Section titled “The copyright position”

No copyright assignment, ever — contributors keep their copyright. That is the permanent public promise, and it is the one this movement will be held to.

  • Contributions are licensed inbound = outbound: under the project’s own licence, to the project’s users, with no separate grant to the Association.
  • The licence is drafted per contributor — “Each contributor grants you…” (§3) — so you license your own part and nobody licenses on your behalf. A side effect worth knowing: a large organisation using the project outside the licence’s condition is outside your grant too, and the claim is yours, not the Association’s.
  • The Association can never be a licensor, sublicensor, or rightsholder in the code of any project it registers for others, and can never ask you to assign copyright. Both bars are in the statutes (Art. 4, and what we can never do).

The contribution instrument

Section titled “The contribution instrument”

The designed default is a one-line sign-off in the commit trailer — the same ceremony as a developer-certificate-of-origin sign-off:

Signed-off-by: Your Name <you@example.invalid>

The final form of the instrument remains subject to legal review, so this page describes it as the designed default rather than promising the ceremony. What the sign-off is designed to assert:

  1. that you have the right to submit the contribution;
  2. that you accept the steward roles the licence defines — that a recorded Entitlement or Waiver satisfies the licence’s condition for every contributor’s grant, including yours; and
  3. a bounded forward delegation: that later versions of the licence, if they are materially consistent with this one, may apply to your existing contributions.

That third point is the one that deserves scrutiny, so its limits are published rather than buried. The delegation can never reach the immutable core (Art. 13): the free-tier threshold may only widen; the four-year conversion may only shorten; the destination of funds and the no-private-profit rule cannot be touched; the Association cannot become a rights-holder in code it registers for others; the administrator’s gratis waiver power cannot be removed. A change touching any of those needs your fresh consent or applies to future contributions only. Non-material corrections and legally required cures apply automatically.

Without a delegation of that kind, a new licence version could not be applied to existing contributions at all without per-contributor consent — which is a real constraint, honestly described, rather than “the licence is frozen”.

Impact Shares

Section titled “Impact Shares”

An Impact Share is an attributed share of a project’s routed funds that you direct — never receive.

  • What it is computed from. The public contribution record of the canonical repository, by the published algorithm version in force. PP-v0, the founding-cohort algorithm, is deliberately coarse: half from your share of the lines added and deleted, half from your share of the commits, over the trailing 12 months, as GitHub’s contributor statistics report them. Bots are left out, and so is anyone who has used their right to object to attribution; vendored and generated files count as code does. PP-v1 — clone-based attribution over the actual code, with the full anti-gaming guard set — replaces PP-v0 from its first complete month, under the published sunset commitment.
  • What it shows. Your points, to you alone; everyone a snapshot credits is shown as credited, with no rank and no band. A currency figure only above a published materiality floor; below it, points only.
  • What it never shows. A leaderboard. A cross-contributor money ranking. Anything that turns a shared codebase into a scoreboard. The materiality gate exists because a figure of “a few cents” attached to a person’s name is both meaningless and slightly insulting.
  • Every displayed figure carries the algorithm version that produced it, and each version publishes with the date range it applied to. Versions are never mutated; a change is a new version alongside the old one.
  • Nothing is displayed yet. The claim flow that lets a contributor appear is a later phase, so at this stage there is no attributed figure anywhere on this site — that is the honest state, not an outage.

Details and the source pointer: algorithms and schedule versions.

The vote, in shadow mode first

Section titled “The vote, in shadow mode first”

Project administrators and contributors can choose among the seven categories or leave their share to the Association, which directs it each month to where it is most needed. The seven categories are health, education, poverty relief, humanitarian aid, environment, animal welfare and research. A share left to the Association, and any unassigned portion, follows the board’s published allocation key. Choices are advisory; the board makes the final decision.

Contributor choices begin in shadow mode: recorded and displayed, but with no effect on real transfers. Activation requires at least a quarter of data and a published, passed fairness and abuse review. An attributed Impact Share does not give ownership of funds or a right to direct a payment independently of these rules.

Older registry artifacts may carry versioned routing-mode fields. Those fields retain their documented schema meaning; a marketing description does not activate a mode or change a published artifact.

See the causes, the statutes and algorithm versions.

Certificates

Section titled “Certificates”

A contributor certificate is a participation certificate: it names you as you elected to be named — a platform login or a supplied name, never an email address — and states the project, the period, and the categories your share directed.

  • ES256-signed, logged in the append-only transparency log before delivery. A certificate absent from the log renders as unverified even with a perfect signature.
  • Verified in one place. The fixed wording is: verify only at purposesource.org/verify. Any artifact offering another verification address is not ours.
  • Verifiable without us. Fetch the key set, check the signature, check log inclusion — the procedure is verify a certificate offline.
  • It has no monetary value, deliberately. See below.

What you never receive

Section titled “What you never receive”

This list is the point of the design, not a limitation of it:

  • No money. No cash, no bank transfer, no invoice you can raise.
  • No voucher, gift card, credit, bounty, or convertible perk. Anything with resale or exchange value is excluded.
  • No equity, token, unit, or claim on the Association or on any project.
  • No entitlement to be paid later. Nothing accrues, vests, or accumulates in your favour.

Why it is built this way, stated plainly:

  1. Structural. Paying contributors is barred by the statutes (Art. 5). It is not a budgeting decision a future board could revisit: only an amendment of the statutes, by two thirds of all members and published with a visible comparison, could change it (Art. 22).
  2. No financial benefit. The design gives contributors recognition and an advisory voice, without anything they can sell, exchange or claim as payment. This is not a promise about every jurisdiction’s tax or employment treatment.
  3. A different purpose from maintenance funding. Purpose Fees support public-benefit recipients. Projects seeking income for maintenance should assess a suitable funding model separately.

Check your project’s fit

Section titled “Check your project’s fit”

For work on an employer’s behalf, follow its contribution policy. A policy requiring OSI-approved terms may need separate approval for current Purpose Source releases. The four-year conversion applies to older releases; it does not change the policy for current contributions.

Your project can use the review pack for licence classification, scanner configuration and dependency questions. Distribution channels set their own requirements.

Section titled “Related”