Privacy notice

This notice covers purposesource.org, the account dashboard at app.purposesource.org, and the API at api.purposesource.org, which serves the public read endpoints and the account service behind the dashboard. It is written to satisfy the Swiss Federal Act on Data Protection (FADP), the EU and UK General Data Protection Regulations (GDPR), and the principle behind all three: say what you collect, why, for how long, and who else sees it — and collect as little as possible. A visitor who only reads the site gives us almost nothing; a person who signs in, buys or makes a contributor page gives us more, and sections 3, 5 and 8 say exactly what.

1. Controller

Purpose Source Association, an association under Art. 60 ff. ZGB with its seat in Aarau, canton of Aargau, Switzerland (the imprint carries the register status). Postal address: Purpose Source Association, Altstadtbüro, Zollrain 2, 5000 Aarau, Switzerland. Contact for anything in this notice: legal@purposesource.org, or the data-request route.

If the Association is dissolved. The registry, the ledger, the key set and the transparency log are archived and handed to the archive custodian named on the wind-down page, which is the controller of that archive from that day. Before the signing keys are retired the archive is minimised — a listed organisation’s name becomes a status-only record unless the organisation asked to stay listed — and the data-request route becomes the custodian’s published contact.

Representatives. The Association is established in Switzerland and has a Swiss-domiciled representative under Art. 69 Abs. 2 ZGB. It has not yet appointed a representative in the European Union under Art. 27 GDPR or in the United Kingdom under Art. 27 UK GDPR. When it does, this notice names them.

2. What this site collects from a visitor: nothing

• No cookies are set on anonymous browsing. No local storage, no fingerprinting. Signing in sets cookies on the API’s address, which section 3 lists. Paddle’s checkout, once you continue to payment or open a Paddle payment link, may set Paddle’s own cookies under Paddle’s privacy notice.
• No analytics script exists on any page, first- or third-party. Aggregate traffic figures (requests per path, per country, per day) come from the hosting provider’s server-side zone metrics, which your browser contributes to only by making the request.
• No consent banner. Reading the site needs nothing to consent to, and the cookies that signing in sets are needed for the sign-in you asked for. Introducing any technology that would need consent is a change to the site’s requirements, never a banner bolted on.
• Two third-party scripts:
  • the bot-protection challenge widget on the contact forms, loaded on that page only. It sees its own challenge and your browser’s request to it; it sets no cookie usable elsewhere on this site.
  • Paddle.js, loaded only to open Paddle’s checkout: on the pricing page when you continue to payment, and on the payment page that Paddle’s payment links open, when its address carries a Paddle transaction reference. Paddle runs its checkout under its own privacy notice.

Edge request logs. Like every website, this one is served by a provider whose edge records the request: IP address, path, user agent, timestamp, response code. These logs are retained briefly under the provider’s terms and are not exported or retained by the Association. Requests to the account service pass through the same edge on their way to it; they are never cached there.

3. If you sign in: your account

Signing in on the dashboard creates an account on the account service. You can sign in with GitHub and, where sign-in by e-mail is switched on, with an e-mail address and a one-time code or link that we send to it. An account holds: a record of the account itself (what kind of account it is, and which version of the terms it accepted, if any, when, and from which shortened IP address); your GitHub identity, if you signed in with GitHub; the e-mail addresses you add; your sessions; and, when you claim a repository or act for an organisation, the record of what you did and when.

Signing in with GitHub. When you sign in with GitHub, GitHub sends us your public profile, and we keep from it only your public login, account ID and profile-picture link; we get no permission to change your GitHub data. We keep GitHub’s access token encrypted and use it to check that you administer repositories you claim, to refresh your repository list, and to read repositories’ public files (such as PURPOSE.yml and the licence) and their open pull requests, and, when you ask on your contributor page, the history of the licence file in registered repositories (section 8); the repository list is deleted after about two days. We keep the token while you have an active GitHub sign-in session or a pending or active repository claim, and delete it when neither remains, when we confirm GitHub no longer accepts it, or when you delete your account. You can revoke our access at any time in GitHub’s settings; deleting your account also asks GitHub to revoke it.

We neither ask for nor keep the e-mail address of your GitHub account. Each token is encrypted under a key of its own, which is itself encrypted by a key that never leaves our key vault in Switzerland, and no log records a token. An active claim is checked again at least every 30 days. If you use the dashboard to open a pull request that adds the licence to your repositories, GitHub asks you for a separate, wider permission (public_repo, which GitHub grants for all your public repositories). We use it only for the pull requests you start and their clean-up, hold that token only in memory while that work runs, never store it, and delete the grant when the work ends; if GitHub does not confirm the deletion, the dashboard says so, and you can remove the access in GitHub’s settings.

E-mail addresses. An account can hold up to three e-mail addresses, one of them the main address. An address is added only after you prove it is yours, by typing the code we send to it or by opening the link we send to it, and we never take one from GitHub or from a repository’s history. For each address you choose whether it receives notices and whether it may be used to sign in. We use the addresses to sign you in, to send notices about your own account, and to match an organisation’s invitation sent to one of them to your account. Whatever you chose for notices, we tell the account’s other addresses when you add an address or make one main, and every address, the removed or changed one included, when you remove an address or change whether it may be used to sign in; when you link a GitHub login to the account, we tell every address too. A removed address is deleted at once. Codes and links reach you through our transactional-email provider; the records we keep of them hold no address in clear.

Sessions and cookies. A sign-in starts a session. Your browser keeps two cookies for it on api.purposesource.org, sent to that address only: the session cookie, and a security cookie that protects your requests from being forged on another site; and, for the few minutes a sign-in takes, short-lived cookies that tie it to your browser. We keep a record of each session: a hash of the session cookie (never the cookie itself), when it started and was last used, your IP address shortened to its network (the last of its four parts removed, or for IPv6 everything after the first three of its eight), and your browser’s family. A session ends when you sign out, after 14 days without use, or 90 days after sign-in at the latest. Its record is deleted at the first daily clean-up after you signed out or after the 90 days, so the record of a session you simply stop using stays until about 90 days after the sign-in.

The dashboard itself loads no analytics. It keeps the display settings you choose in your browser’s local storage: whether it looks light or dark, whether its menu is collapsed, and which part of the dashboard opens, the one for your projects or the one for your organisation. You choose those with the appearance control, with the button at the top of the menu, with the sign-in button you press, with the switch in the account menu, or by accepting an invitation to an organisation or registering one. Each setting is one word, says nothing about who you are, and is never sent to us. The dashboard shows your GitHub profile picture from GitHub’s image server, so your browser asks GitHub for it; and its sign-in and purchase pages, where it offers sign-in by e-mail, load the same bot-protection challenge as the contact forms before they send a code.

Deleting your account. You can delete your account from your account page. At once, every session ends; your GitHub login, profile-picture link, account ID and token are removed from the account; your e-mail addresses are removed; your organisation roles and repository claims end; your contributor page is hidden (section 8); every contributor certificate you show (Public link or On my page) returns to Private and leaves your page, and its public share picture is deleted, while the certificates themselves are not revoked (section 7); and we ask GitHub to revoke our access. Within 30 days, a keyed pseudonym replaces your GitHub account ID or login where the records of your category choices, of the pull requests you asked us to open and of contributors’ shares name you by them; until then we hold the two only to find those records. Within the same 30 days the records of your contributor page and of your certificate choices (section 7) and your messages from the Voting tab (section 9) are deleted, except the keyed fingerprints of the page’s former login addresses, which then name nobody. Records that are append-only histories, public records or the evidence of a past act keep what they were written with:

• each repository claim you made, with your GitHub account ID and GitHub’s answer that proved it;
• what you did as a repository’s administrator (changes to its registry entry, its waivers and its weight class), which names your GitHub account ID, and in a waiver’s history your login;
• an older copy of the history of your category choices, which names your GitHub account ID, until that store is retired;
• the account’s own audit trail and its record of terms accepted, which name the account by our own identifier and an address only by a hint (its first character and its domain), and keep the shortened IP address an acceptance came from and, for each certificate you withdrew (section 7), your GitHub account ID;
• a steward’s record of an act on your contributor page (a hide, a block or an unblock, with its ground and the steward’s statement of reasons), or of a mark on a message you sent from the Voting tab (the status set and whether the note changed, never your words or the note), in that steward’s own audit trail, which names the account by our own identifier and the page or the message by its identifier;
• what an organisation keeps: an invitation it sent you, which names your login or a digest and a hint of your address, and a proof of its domain that you made, which names the account by our own identifier and the address the code went to by a keyed fingerprint;
• contributor certificates issued to you, whose public records then show only their status (section 7);
• for a repository under your personal GitHub account, its registry entry (section 6) and, in the record of a pull request you asked us to open, its name, which begins with your login.

We also keep the record of the deletion itself, permanently. It names the account by our own identifier, holds the dates of the request and of the work that follows it, how far that work has got and a note of any step that failed (never an address or a token), and, if the account had a GitHub login, a salted hash of its GitHub account ID (the same hash the exclusion list keeps, section 12; not the ID itself), so that attribution never counts that GitHub account again. Your GitHub login and account ID stay in it only until the 30 days’ work is done.

To keep our notices from reaching a deleted account’s addresses again, we keep a keyed fingerprint of each address, not the address itself; a sign-in code or link that somebody asks for at one of them is still sent. Records that accounting law makes us keep stay for their period (section 11).

4. What you can send us

Forms. The contact, abuse-report, and data-request forms send what you type — your reply address, a subject, a message — through the challenge widget to the edge Worker, which verifies the challenge server-side, forwards the submission as one email to the steward inbox through the transactional-email provider, and stores nothing. There is no database on the forms’ request path. Your message then lives in the steward mailbox for the retention period in section 11. The form in the dashboard’s Voting tab is different: what you send there is stored with your account (section 9).

Email. Mail to the published addresses is routed at the edge to the steward inbox. It is handled like a form submission.

What a URL carries. Organisation names in a coverage lookup are sent by POST, never as a query string, so a third party’s name never lands in a shareable link, a proxy log, or a cached URL. No URL on this site carries card details. The one kind that carries an e-mail address is the sign-in link we e-mail you (section 3): it carries the address it was sent to, encoded but not encrypted, after its # sign, which a browser does not send to the server it opens; the page it opens takes it out of the address bar at once. Four kinds of address carry an identifier that can relate to a person:

• Payment links. Paddle sends a buyer to our payment page at an address that carries Paddle’s transaction number (/pay?_ptxn=…). The number identifies one checkout transaction, and Paddle or we can link it to the purchaser’s details. Because it is part of the address, it can appear in your browser’s history and in the hosting provider’s request logs. Once the payment is complete, the page removes it from the address shown in your browser, so a link copied from the page no longer carries it; the page keeps showing it as your payment reference.
• Certificate addresses. The verification page sends a certificate identifier to the edge API and nowhere else. A certificate’s own address carries that identifier, and for a certificate issued to a person it points to that person’s certificate.
• Registry addresses. A repository’s address in the registry can carry its GitHub owner and name; for a repository under a personal GitHub account, the owner is that person’s public GitHub login.
• Dashboard addresses. A dashboard page about an organisation or a repository, and the request it sends to the account service, carries the organisation’s company identifier or GitHub’s identifier for the repository; for a sole trader, or a repository under a personal GitHub account, that relates to a person (section 6).

5. Entitlement purchasers

Entitlements are sold through Paddle (Paddle.com Market Ltd; Paddle.com Inc. for buyers in the United States; Paddle.com (Canada) Ltd. for buyers in Canada), our merchant of record, which is the seller to you and an independent controller of your checkout and payment data under its own privacy notice. Card and bank details never reach the Association.

The Association receives and processes, as controller: the purchasing organisation’s name and verified domain; the purchaser contact’s name and email; the revenue-band self-certification (one binding, timestamped tick); whether the organisation asked to be listed by name; for the Pass, any registered repositories the organisation chose to name; and the settlement record, which carries Paddle’s transaction number. From this it produces the signed entitlement record and the certificate, and it screens the organisation against sanctions lists.

Named only if you ask. An organisation that buys an Entitlement is named in the public registry only if it ticks List our organisation’s name publicly at checkout; otherwise it appears as Unlisted organisation under an opaque company identifier. Unlisted is not anonymous: the identifier, the lane, what the Entitlement covers, its term dates, its status and the fee amount of each purchase are published in the registry and the ledger, and a domain the organisation verifies resolves publicly to that identifier. The contact person’s name and email are never published. If an organisation’s registered name is a person’s name — a sole trader’s, for instance — ticking the box publishes that name. The name is shown on the list of covered organisations, in the signed entitlement record and on the certificate’s public record, and is never written into the ledger rows themselves, so asking to be unlisted removes it from every page the Association publishes; copies others have already made are outside its reach.

6. Registry, contributors, and public artifacts

The registry, the waiver list, the list of covered organisations, the allocation ledger, the certificate status records, and the transparency log are public. They contain repository identifiers and names, company identifiers, the names of organisations that asked to be listed and of organisations covered by a waiver, and — from the phase in which contributors can claim their attribution — a contributor’s public platform login and opaque account identifier, shown only where the contributor chose to show them (sections 7 and 8). Each contributor certificate also has a status record there, which names nobody unless its holder chooses to show the certificate in full (section 7).

Repository owners. The registry finds repositories that carry a Purpose Source licence by searching public GitHub data. For each repository it lists, it publishes the repository’s name as GitHub shows it — for a repository under a personal GitHub account, that name includes the owner’s public login — and, where GitHub gives one, the identifier GitHub assigns to the owner’s account. A repository that is not a fork, and whose licence file is identical to a published licence text with no altered licence file beside it, is listed without a person’s review; any other is reviewed by a person first.

README cards. If a repository’s maintainers choose a README card that shows the repository’s own picture, our edge fetches its owner’s GitHub picture from GitHub’s image server by the owner’s public account identifier and draws it inside the card, so a reader’s browser never asks GitHub for it, and keeps it only in its cache, for at most 12 hours, never in our records; an owner who objects can write to legal@purposesource.org, and their repositories’ cards are then drawn without it.

The public records never contain email addresses, and the e-mail addresses an account holds (section 3) are never published. The transparency log contains hashes, type codes, and timestamps only. The ledger contains aggregates, repositories and company identifiers, and no names or contact details; a company identifier that belongs to a sole trader, or a repository under a personal account, still relates to a person. A listed organisation’s name is shown beside its ledger rows on the transparency pages, never inside them.

Anyone may exclude their identity from attribution processing through the exclusion list, which keeps only a salted hash and the time of each objection and each undo; only the person can undo an objection — see section 12.

7. Certificates

A certificate names its subject: an organisation by the name it gave, a contributor by their GitHub login; never an email address. Its status record at the verification URL is public; it carries that name only for an organisation that asked to be listed and for a contributor who chose to show it, and for every other organisation it carries the status alone, while the signed certificate goes only to the organisation. Revocation is prospective and leaves the record’s historical window readable. After revocation a minimal issuance record is retained for ten years for the Association’s accounting and legal defence.

Yearly certificates. If you signed in with GitHub, we issue you a contributor certificate for each year in which projects credited you, once all twelve months of that year are closed, and one for every earlier closed year that credited you, including years before you made your account. We do this automatically, without asking you, and we send no e-mail about it. Each names the projects that credited you that year; a year that does not fit on one certificate (credited by more than 50 projects, or by more than one method of computing credit) is not issued automatically. This is on unless you turn it off with Issue my yearly certificates in the dashboard; turned off, it issues nothing more and withdraws nothing, and you can still ask for a certificate. We issue you none while you object to attribution (section 12). A certificate for a month or another period is issued only when you ask for one. Each yearly certificate starts Private, whatever you chose for your other certificates, and so does one you ask for, unless you choose Public link when you ask. Private means that only you see it, in the dashboard, where you can download it and give it to anyone you choose, who can check it on the verification page. It stays private for as long as you want.

What is public about a private certificate. Two things, and neither names you. Every certificate, private or public, puts one fingerprint in our public transparency log: a hash of the signed certificate, with a type code and a time, never your name, your login or the certificate’s number. That fingerprint is what lets anyone you give the certificate to check that it is real, so it is not a choice. And every certificate has a public status record at its verification address, which only the certificate’s own number reaches; the number cannot be guessed and is printed on the certificate. The record shows the kind of certificate, its period, when it was issued and its status, with a fingerprint of the signed certificate that lets you show the record is yours, and no name, no project and no signed certificate. We write each yearly run’s certificates in a random order, so their order in the log does not follow the order in which people signed up. For us, the fingerprint and the record still relate to you, because our own records say whose certificate each one is.

What the certificate carries. The signed certificate carries your login, GitHub’s identifier for your account, its period and the projects that credited you in it, and, where the certificate records them: the share of the amount attributed to your credit that your own designations left to the Association; the categories your designations named, with their shares; and an impact amount with its currency, which a certificate carries only once the ledger holds one and only above the published floor (below it, the certificate says only that the amount is below the floor). It never carries your points or a percentile band. A certificate we issue automatically carries the same as one you ask for.

Who can see it: one choice for each certificate. In the dashboard you choose, for each certificate:

• Private: only you; anyone you give it to can check it.
• Public link: anyone with its link or QR code sees it in full. Its public record also shows your GitHub login, the projects it covers and the signed certificate, and we publish its share picture, which shows your login, those projects and, when the certificate carries one, the impact amount.
• On my page: public as with Public link, and listed on your contributor page once the page is published; offered once you have started a contributor page (section 8). If your page does not show your login when you choose it, the certificate is published and listed without your name or projects. Hiding the page, or changing later whether it shows your login, does not make the certificate private: choose Private for that. A change to whether the page shows your login takes the certificate off the page until you choose On my page again.

Before a public step takes effect, the dashboard tells you what it will show and asks you to confirm, and also that you are 16 or older, unless you already confirmed that when you published your contributor page (section 14). Until showing certificates publicly opens, the dashboard offers Private alone. You can go back to Private at any time: the record is published again without your login and projects, the published share picture is deleted, the certificate leaves your page, and it is not revoked. Deleting your account or objecting to attribution does the same for every certificate you show (sections 3 and 12), and undoing an objection does not bring Public link or On my page back. Nothing shows a certificate in full except your own choice.

Withdraw my certificates. Under that switch, Withdraw my certificates withdraws, in one go, every contributor certificate of yours that is not revoked already. You confirm it by typing WITHDRAW, and we may first ask you to sign in again. Each certificate that is valid or still being issued is revoked, with a reason that says its holder asked for it, so anyone you gave a copy to sees it as revoked when they check it; one already out of service (expired, or replaced by a newer certificate) keeps that status, and the withdrawal is recorded for it too. Every certificate withdrawn is also set to Private and taken off your contributor page, and any public share picture of it is deleted. The withdrawal turns your yearly certificates off as well: you can turn them on again, but a year you withdrew is never issued again by them. A withdrawal cannot be undone. As with every revocation (above), it is prospective: a revoked certificate’s public record, where it has one, stays and shows that it was revoked, at its holder’s request, and when; the record of one already out of service keeps showing that status; and neither names anybody. A revocation deletes nothing from the log: the fingerprint of a certificate that was in it stays, and a revocation entry is added beside it. Each certificate’s minimal issuance record, with the record of its withdrawal, is kept for ten years after it was revoked or expired (section 11). Under Activity on your account on your account page, each certificate withdrawn shows as Withdrew a certificate: that entry in your account’s audit trail names the certificate, your GitHub account ID and the kind of revocation, and it is kept with the audit trail (section 3).

Why we may, and what we keep. We issue and keep your contributor certificates on our legitimate interests, and a certificate is shown publicly only on your consent (section 10). We keep each certificate issued to you, a withdrawn one too, while your account exists (section 11). We keep a record of each choice you make about your certificates (yearly certificates on or off, and each certificate’s Private, Public link or On my page, with the version of the terms in force) until your account is deleted (within 30 days of the deletion, section 3), so that we honour each choice and can show each consent and its withdrawal.

8. If you make a contributor page

If you sign in with GitHub, you can build a contributor page: a public page about your contribution under Purpose Source, which you build and preview in private and publish only when you choose. Nothing about it is public before you publish it.

While you build it. When you first open the page editor, we create the page’s record: our identifier for your account, your GitHub account ID, and the page’s own identifier, 16 random characters, which becomes its permanent link once you publish. Your draft holds what you choose: a display name, pronouns and a short bio; links to your profiles on other platforms and to sponsorship services, kept as the platform and your name there (we build every link ourselves from a fixed list of addresses, and never fetch it); one personal website address; the picture and the cover; the layout and colours; which sections appear; whether the page explains Purpose Source to its visitors, in one of our texts or, if you choose, in a few words of your own; and which of your certificates and repositories are shown. Your draft and its preview are private: the site shows them to you alone, signed in, and a draft never reaches our public storage. To draw the preview, our edge passes your request, with your session cookie, IP address and browser details, to the account service, and keeps nothing.

What the page can show about your contribution. The years in which projects credited you (the page’s facts), from our locked monthly credit records and from your own participation certificates: years only, never months, shares, points, ranks or amounts. The certificates you put On my page, with their live status (section 7). And, if you ask us to check, the registered repositories where you adopted the licence, each with the year you did so where we know it (“Since 2026”); a repository that has since left the licence stays listed only with both years (“2026–2027”), the year it left as the registry records it. For that check we use your kept GitHub token (section 3) to read the history of the licence file in registered repositories you can push to or adopted through the dashboard, including who committed each change, who merged its pull request, and when; we keep only the changes you merged or committed yourself (your adopter facts), each with the date and time of the merge or commit it rests on where GitHub gives one from 2026 on, and nothing about anyone else. That date is already public on GitHub, where the page’s “evidence on GitHub” link points; the page shows only its year, and the date is kept and deleted with its fact.

Publishing. You can publish only what you previewed, after accepting the current terms of use, and only if the page shows something we can vouch for: a repository that credits you, a certificate, or a registered repository where you adopted the licence. At your first publish you confirm that you are 16 or older. Each publish keeps your choices as a published version. We keep a record of every act on the page (each publish, with the version of the terms in force and your age confirmation; each hide and deletion; each change of address; a dismissed invitation to make a page) as the record of your consent.

What is public, and to whom. A published page is public to anyone who has its address: the page, the data file it is drawn from, and the files it shows (your picture, your cover and the page’s card), which anyone who has their address can also read directly from our public storage. It shows your GitHub login only if you switch on “Show my login”; without it, the page lists no repository under your own GitHub account, because that repository’s name contains your login. Even without your login, a picture, a short list of repositories or your own words may identify you, and the editor says so where it can. Each page says that Purpose Source checks the certificates and the repository facts on it, not the owner’s words or links.

Its address. You choose one of three: the permanent link, purposesource.org/p/ and the page’s identifier, which shows no login (the default); purposesource.org/u/ and your login; or your login and the identifier together. The last two need “Show my login”, as the search switch and the licence-adopter section do. With either of the last two, opening the permanent link takes the reader to that address, so the permanent link then shows your login. The page’s record keeps a copy of your current GitHub login and of your GitHub picture’s address, as your account does (section 3), but we keep no login address as text: we keep a keyed fingerprint of your login, made with a secret key, and a small public file named by that fingerprint points the address to your page. When we see that you renamed your GitHub account (at the latest when you next sign in with GitHub), the page moves to your new login, or, where that address cannot be yours, to another of the three addresses, and the editor tells you; the old address stops working and is never given to anyone else. To keep it so, we keep its fingerprint with no account attached, beside a keyed fingerprint of your GitHub account ID so that only you can take it back. “Start over with a new permanent link” gives the page a new identifier, and the old link, its card and its badge stop working for good; the page is public again only once you preview and publish it under the new link.

Search engines. Every page asks search engines not to list it, unless you switch on “Let search engines list this page”, which works only for the login address (/u/ and your login alone) and never for the permanent link. We publish no list of pages. Switch it off and the page asks them again not to list it.

Pictures and the card. The picture can be your GitHub picture, a monogram of your name, a pattern drawn from the page’s identifier, or a picture you upload; the cover can be a colour or a picture you upload. Your GitHub picture is copied by our render service from GitHub’s image server and re-encoded, so readers’ browsers never contact GitHub; its GitHub address, which contains GitHub’s number for your account, stays in our private systems (our database, and the render service’s requests and records) and is never published. A picture or cover you upload must be a JPEG, PNG, WebP or GIF file of at most 5 MB (of a GIF, the first frame is used). We never show the file you sent: our render service re-encodes it to fixed sizes, which removes its location and every other metadata, and the original is then deleted. It is published only with your page, and nobody reviews it before. Your page also has a card, an image that follows your choices for the page, and a small badge, which shows no name, for you to show in a README or on a website; readers there fetch them from api.purposesource.org, or through that site’s own image service (GitHub’s, for instance). When someone shares the page’s address, a site or app that shows link previews reads the page’s title, a short description and a version of its card.

Visitors. A page runs no script, sets no cookie and asks nothing of any other site: its styles, fonts and pictures come from purposesource.org. A visit leaves only the edge request record of section 2, whose path is the page’s address. Our edge keeps a drawn page for up to 60 seconds, and a reader’s browser for up to 60 more.

Where it is kept. The page’s records are in the account service’s database and its files in our storage, both in Switzerland (section 13); the edge serves the page from wherever the reader is.

Hiding and deleting. You can hide the page at any time, with no condition. Hiding deletes its public files (the page, its login-address file, the picture, the cover and the card) and every picture and cover you uploaded, so the page soon answers exactly like one that never existed; our storage’s copies of those files are deleted within about a day (section 11). Hiding keeps your draft and your published versions, so you can publish again, after uploading again any picture or cover the hide deleted. Delete my page hides it, empties your draft and the page’s facts at once, and deletes your published versions and adopter facts at the next scheduled clean-up. The page’s record (its identifier and your GitHub account ID), the fingerprint of its login address, the names of the files it put in our public storage and the record of your acts stay until your account is deleted; the record of your acts is the record of your consent. Copies others have already made (screenshots, their caches, an embedded card, a link preview) are outside our reach.

Reports. Every page has a “Report this page” link to the abuse and moderation form on the contact page; you can also write to legal@purposesource.org. A report reaches us like any form (section 4). We aim to answer within five business days; we hide a page first when in doubt, and escalate a threat to someone’s life or safety at once. A steward’s hide works like your own, uploads included, and the dashboard tells you why. After a second hide by a steward, or when a steward pauses publishing for your account, you can publish again only once a steward allows it.

When you object or delete your account. An objection to attribution (section 12) hides the page at once and empties its draft and facts; as after “Delete my page”, its published versions and adopter facts are deleted at the next scheduled clean-up. While the objection stands you cannot make a page; if you undo it, nothing of the page comes back by itself (section 12). Deleting your account hides the page at once too (section 3), and within 30 days every record of it is deleted except two: the fingerprints of its former login addresses, which then name nobody, and the audit records of a steward’s act on it (section 3). Either way, every certificate you show (Public link or On my page) returns to Private and leaves the page (section 7).

9. Advisory votes (the Voting tab)

The Association’s board can ask for advice through votes in the dashboard’s Voting tab. A result is advice only: the board decides.

Who is asked. Each vote asks people who contribute to a registered project, people who administer one, or both. When a vote opens, we work out once who is asked, from data we already hold, and keep that list. We use:

• for people who contribute: whether a registered project credited your GitHub account recently (the attribution in section 6); only whether you were credited, never how much;
• for project admins: your claims on registered projects, and each claimed project’s public GitHub facts, which we read once a day: its owner, star count and creation date, and whether it is archived or private.

The exact rules, with the numbers in force, are in the Voting tab. A change applies only to votes opened after it. We don’t ask anyone who chose “Don’t ask me”, objected to attribution, or is deleting their account.

What we keep.

• The list of who is asked (our account identifier): until 90 days after the vote closes.
• Your answers: stored under a code, not under your account. You can change or withdraw them until the vote closes; then they are counted and wiped, and only the totals stay.
• Written answers: a question may ask for a written answer, which is always optional. It is stored under a code made from a secret key, the vote, the question and your account, never under your account. Only after the vote closes, and only if at the close at least 5 people had answered a question in writing, are those answers read, by our stewards in the staff console and by our board: without your name, your account or when you wrote, in a new random order each time. A steward may also download a question’s written answers from the console as one file, in the same form; the file is deleted at the latest 90 days after the close, and until then it keeps any of them withdrawn or wiped after the download. A steward who is still among those the vote asks cannot read or download them. Our stewards read what you wrote as you wrote it, so anything in it that names you or someone else is read too. We never share written answers with anyone outside Purpose Source, beyond the providers that host and carry everything you send us (section 13). If fewer than 5 people answered a question in writing, its written answers are wiped at the close, unread; the others are deleted 90 days after the close (section 11). If later wipes leave a question with fewer than 5 written answers, the rest of them are wiped then too.
• The vote’s record: the vote, its questions, the rules and projects it used, the totals, and the board’s resolution and answer, kept permanently. It holds no list of who was asked and no one’s answer.

What is published. The questions, roughly how many were asked, how many answered, the totals per answer, and the board’s answer. Any number under 5 shows as “fewer than 5”, and counts that could reveal how someone answered are left out. No name, login or written answer is published, and no written answer is quoted. The board’s answer may say what the written answers to a question said, in its own words or in figures, only if at least 10 people answered that question in writing.

Limits. Staff never see how a named person answered, unless a written answer itself says who wrote it. Until answers are wiped or deleted, and for up to 14 days after that in our database backups (section 11), someone with direct access to our database and its keys could, with effort, link them to an account.

What you can do. Answering is up to you, and you can change or withdraw a written answer in the Voting tab until the vote closes; after that, you can still withdraw one there while it is kept, though not from a file a steward has already downloaded (above). “Don’t ask me” in the Voting tab takes you out of every vote, including one still open (any answer or written answer you gave to an open vote is wiped); you can undo it there for votes that open later. Deleting your account, or objecting to attribution, removes you from votes and wipes your answers, and your written answers in closed votes too. A copy of your data (section 12) includes your answers and written answers while they are kept; if the job that prepares it lacks the key to find them, the copy says so and why.

Writing to us from the Voting tab. The Voting tab also has a form to write to the Association’s stewards: to propose a charity for the list (its name and country, its website if it has one, and why), suggest an improvement, report a problem, ask about your credit or a certificate, or anything else. Any signed-in account can use it, up to five messages in any 24 hours. What you write may name other people: please write only what we need to act on it.

• What we keep: what you send, its topic and when you sent it, with your account; and our side of it: whether we have read it, answered it or finished with it, which steward marked that and when, and a short note our stewards may write about it. Each time we change where we are with a message, your account’s activity (section 3) also records it as a staff action, with the message’s identifier, the new status and the steward’s account identifier, and the steward’s own audit trail records the mark; neither holds your words or our note, and both stay after the message is deleted (section 3).
• Who reads it: the Association’s stewards, in the staff console. Beside your message the console shows them your GitHub login, your main email address, when your account was created and the facts below. We answer by email, outside the dashboard, to your account’s main email address (section 3). If your account has no email address, we can’t answer by email. Our answer, and anything you write back, is kept in the steward mailbox like other email (section 11).
• Whose messages are read first: messages from people who contribute to or administer registered projects. The console works this out each time it is opened, from data we already hold: since when, in how many months and by how many registered projects your GitHub account was credited (section 6), never how much; the registered projects you administer through your claims and whether each is a major one; and how old your account is. That order is never stored and never shown to you or to anyone outside the console. Our stewards read the messages; the order only decides which come first.
• How long: until your account is deleted (within 30 days of the deletion), or two years after we mark the message done, whichever comes first. You can see your newest 100 messages and where we are with each in the Voting tab, and a copy of your data (section 12) includes all of them with our notes.

10. Why we may process this: lawful bases

Processing	Basis (GDPR Art. 6(1))
Serving the site and the dashboard; edge logs; abuse prevention	(f) legitimate interests — running a public website securely
Accounts, sign-in, sessions, the e-mail addresses you add, notices about your account	(b) performance of the contract for the account you asked for
Keeping and using the GitHub token; the list of repositories you administer	(b) the account and the claims you make; (f) legitimate interests — making sure that only a repository’s administrators act for it
Answering a request about your data under section 12 (access, rectification, erasure, restriction, objection, data portability) by the data-request form, an email, Download your data on your account page or deleting your account from your account page, including verifying who you are, preparing the copy and keeping the record of the request	(c) legal obligation — answering your request as the law requires (GDPR Arts. 12 to 22)
Answering any other form or email	(f) legitimate interests — responding to you; (b) where you are a purchaser
Purchaser records, entitlement records, an organisation’s certificates; the transaction number on a payment link	(b) performance of the Entitlement contract; for the purchaser contact’s name and email, (f) legitimate interests — dealing with the purchasing organisation through the person it names
Accounting records, sanctions screening, VAT	(f) legitimate interests — meeting the Swiss legal duties the Association is subject to (Swiss Code of Obligations Art. 958f for the accounts; Swiss sanctions law for the screening)
Public registry entries of purchasing organisations (identifier, lane, scope, term, status, fee amounts; the name only on request)	(b) contract; (f) legitimate interests — the credential’s public function; a sole trader’s name only on (a) the consent the listing tick gives, withdrawable at any time
Public registry entries of repositories, including a personal owner’s public GitHub login and account identifier	(f) legitimate interests — a public, checkable record of the repositories that carry the licence
Issuing your contributor certificates, each year and when you ask for one; keeping them; the fingerprint of each in the transparency log and its status record that names nobody (section 7)	(f) legitimate interests: giving each person whose work a project credited a signed record of it, which anyone they give it to can check, and keeping every certificate we signed checkable. We weighed this against your interests in a written balancing test, which weighs contributors aged 13 to 15 on their own; you can ask us for it. You can object at any time, with no reason needed (section 12)
Contributor attribution display; showing a certificate publicly (Public link or On my page, section 7)	(a) consent: you choose it for each certificate, and withdraw it at any time by choosing Private; the underlying computation over public repository data rests on (f), and runs on real people’s data only once its balancing test is on file
Your contributor page: the draft and its preview, publishing, the facts and adopter facts it shows, its pictures, uploads and card	(a) consent: you build, preview and publish it yourself, and withdraw by hiding or deleting it at any time
Keeping the record of your consents after you withdraw one, and of your other choices: the record of your acts on your contributor page, and of your certificate choices (yearly certificates on or off; each certificate’s Private, Public link or On my page)	(f) legitimate interests — honouring each choice, and being able to show each consent and its withdrawal (GDPR Art. 7(1))
Keeping the fingerprint of a former page address	(f) legitimate interests — never giving a person’s former page address to someone else
Keeping keyed fingerprints of addresses our notices must not reach (after an account deletion, a bounce or a complaint)	(c) legal obligation — honouring your erasure means our notices do not reach a deleted account’s addresses again (a sign-in code or link asked for at one is still sent, as section 3 says); (f) legitimate interests — respecting a complaint, and not mailing an address that bounced
Keeping the exclusion list: your objections to attribution and your undoing of them (section 12)	(c) legal obligation — honouring your objection (GDPR Art. 21) means remembering it, and remembering whether you have undone it
Reports about a contributor page; a steward’s hide	(f) legitimate interests — keeping the pages lawful and safe for the people they show and the people who read them
Working out who is asked in a vote, from the attribution and the claims we already hold; reading claimed projects’ public GitHub facts	(f) legitimate interests: letting the board ask the people who build and run the software for advice. You can object to being asked at any time with “Don’t ask me” in the Voting tab, and to the rest as section 12 says
Your answers and written answers in a vote; reading the written answers for the board after the close	(a) consent: you choose to answer; you can change or withdraw your answers in the Voting tab until the vote closes, and withdraw a written answer there after the close while it is still kept
Your messages from the Voting tab, our notes on them, and reading the messages of people who contribute to or administer registered projects first	(f) legitimate interests — hearing and answering the people who build, run and use the projects on the platform
Opt-in email	(a) consent, double opt-in, withdrawable at any time

Under the FADP, the same processing is justified by contract, legal obligation, or overriding interest, and by consent where a consent is asked for; the Swiss accounting and sanctions duties are legal obligations there.

11. Retention

Data	Retained
Edge request logs	Briefly, by the provider under its terms; not retained by the Association
Operational logs of the account service	90 days in the hosting provider’s log workspace, then deleted
Database backups	Anything deleted or replaced in our database stays in its backups for up to 14 days
Account records (the account; your GitHub login, account ID and profile-picture link)	Life of the account. When you delete it, your GitHub login, account ID and picture link leave the account at once; within 30 days a keyed pseudonym replaces your login and account ID in the records of your category choices, of the pull requests you asked us to open and of contributors’ shares, and the records that §3 lists keep what they were written with
The record of an account deletion (our identifier for the account, the dates of the request and of the work that follows it, how far that work has got and a note of any failed step, and, if the account had a GitHub login, a salted hash of its GitHub account ID; your GitHub login and account ID only until the 30 days’ work is done)	Permanent — it is the evidence that the deletion was done, and its hash is what keeps attribution from counting that GitHub account again (section 12); no job deletes it
Sessions	Until you sign out, and 90 days after sign-in at most (a session unused for 14 days no longer signs you in); the record is deleted at the first daily clean-up after that
The GitHub access token	While a GitHub sign-in session or a pending or active claim needs it; deleted at sign-out when nothing else needs it, within about an hour after your last GitHub session ends, when GitHub stops accepting it, or when you delete your account
The list of repositories you administer	Replaced at every GitHub sign-in; deleted at the first daily clean-up once 24 hours old, so kept about two days at most
E-mail addresses on an account	Until you remove them or delete the account. A removed address is deleted at once; the dated record that it existed, without the address, at the next daily clean-up
One-time sign-in codes and links	A code is valid for 10 minutes and a link for 15 at most; their records, which hold no address in clear, are deleted at the first daily clean-up a day (a code) or an hour (a link) later
Keyed fingerprints of addresses our notices must not reach (after an account deletion, a bounce or a complaint)	Permanent — it is what keeps our notices from the address; the fingerprint is not the address, and the address cannot be read back from it
Your contributor page’s draft, published versions, facts and adopter facts, and the date and time of an adopter fact’s merge or commit	Until you delete the page, object to attribution or delete your account; hiding keeps them, so you can publish again. Delete my page and an objection empty the draft and the facts at once and delete the versions and adopter facts at the next scheduled clean-up; an account deletion deletes them within 30 days. An adopter fact’s date is kept and deleted with its fact
The page’s record (its identifier, your GitHub account ID, the fingerprint of its login address, the names of the files it put in our public storage) and the record of acts on your contributor page	Until your account is deleted (within 30 days of the deletion); deleting only the page keeps them, the record of acts as the record of your consent
The record of your certificate choices (yearly certificates on or off; each certificate’s Private, Public link or On my page, with the terms version)	Until your account is deleted (within 30 days of the deletion, §3), so that each choice is honoured and each consent can be shown
The keyed fingerprint of a former login address of your page	Permanent, so the address is never given to anyone else; it has no account attached, and after your account’s deletion nothing in it names you
Your page’s public files: the page, its login-address file, your picture, cover and card	While the page is published; deleted when you or a steward hide it, when you delete it, when you object to attribution, or when your account is deleted
Pictures and covers you upload for your page	The original until it is re-encoded; the re-encoded files while your draft or your published page uses them, and one day after they stop being used; all of them at once when the page is hidden
The files our render service draws for your page (your GitHub picture, re-encoded, and the page’s card), kept privately in our storage	While the page exists, hidden or not. Deleted at the first daily clean-up after you delete the page, object to attribution or delete your account, and again at each daily clean-up for 30 days after. When you renew your page’s link, the files drawn for the old link are deleted the same way, from the renewal. Our storage then removes them within about a day and holds them 7 more days in its recovery
Our storage’s copies of a replaced or deleted public file about a person (a contributor page’s files; a person’s certificate record and its share picture)	Deleted within about a day of being replaced or deleted, then held 7 more days in our storage’s recovery
Copies in caches	A contributor page: 60 seconds at our edge and up to 60 more in a reader’s browser. A page’s card or badge, and a certificate’s share picture: up to about 15 minutes from a browser’s cache and about 70 minutes from a shared cache. A certificate’s public record: about 5 minutes in shared caches. Caches we do not run are outside our reach
The list of who is asked in a vote	Until 90 days after the vote closes
Your answers in a vote	Until the vote closes, when they are counted and wiped
Written answers in a vote	Wiped at the close, unread, if fewer than 5 people answered the question in writing; otherwise deleted at the first daily clean-up 90 days after the close, unless later wipes leave the question with fewer than 5, when the rest of them are wiped then too. One you withdraw is wiped at once; so are yours in every vote when you delete your account or object to attribution, and in a vote still open when you choose “Don’t ask me”; a vote the board withdraws wipes all of them. A wiped written answer is deleted at the next daily clean-up. A file of a question’s written answers that a steward downloads is deleted at the latest 90 days after the close; until then it keeps any answer in it that was withdrawn or wiped after the download
A claimed project’s public GitHub facts (owner, stars, creation date, archived or private)	Read again daily while the project is in good standing in the registry and claimed; after that its last facts stay, and nothing uses them once they are 48 hours old; a vote’s record keeps the values it used
“Don’t ask me”	Until you undo it (deleted at the next daily clean-up), or within 30 days of your account’s deletion
A vote’s record: the vote, its questions, the rules and projects it used, the totals, the board’s resolution and answer (no list of who was asked, no answer)	Permanent
Messages you send from the Voting tab, with our status and notes on them	Until your account is deleted (within 30 days of the deletion), or two years after we mark the message done, whichever comes first. Each change of status is also recorded, without the message or the note, in your account’s activity and in the steward’s own audit trail, which are kept as section 3 says
Paddle transaction numbers	With the purchase records they belong to (10 years, below); in a payment link’s address, as §4 says
Form submissions and email	24 months in the steward mailbox, then deleted; data-subject-request correspondence for the request plus one year
A copy of your data that you ask for on your account page (section 12), and the record of your request	The copy, one file in our storage in Switzerland: 7 days from when it is ready, then deleted at the first daily clean-up after that. Each download link works for 24 hours at most, and never past those 7 days. Our storage keeps a deleted copy some days more, the last 7 of them in its recovery, so nothing of it is left about 15 to 17 days after it was prepared. The record of your request (your account, when you asked, and the copy’s state and dates): one year after the copy expires or could not be prepared; the line Asked for a copy of your data in your account’s activity stays with the account’s audit trail (section 3)
Purchaser and entitlement records, invoices, band self-certifications	10 years (Swiss Code of Obligations Art. 958f; the Association’s Finanzreglement § 12 Abs. 1)
Usage declarations	Life of the account, or 10 years where money-relevant
Your contributor certificates (the signed certificate, which names you)	While your account exists, with no end date, because a certificate stays checkable for as long as anyone holds a copy; withdrawn ones too (§7, §12). After your account’s deletion, as “Certificate issuance records” says
Certificate issuance records	Life of the certificate plus 10 years after revocation or expiry, as a minimal record
Registry entries of repositories	Permanent — a repository that leaves the registry keeps its record
Transparency-log entries and ledger rows	Permanent: they are append-only public records. Transparency-log entries hold hashes, type codes and timestamps only; ledger rows hold no names or contact details, though a company identifier or a repository in them can relate to a person (§6)
The exclusion list: for each objection to attribution and each undo of one, a salted hash of the GitHub account ID and the time	Permanent — honouring an objection requires remembering it, and the newest entry says whether it still stands; no entry is changed or deleted, and an account deletion removes none
The archive after a dissolution	Permanent, held by the archive custodian as its controller; minimised before the keys are retired (§1)
Sanctions-screening records	At least 10 years, kept with the business records (the Association’s Finanzreglement § 9 Abs. 7)

12. Your rights, and how to use them

You have the rights of access, rectification, erasure, restriction, objection, and data portability, the right to withdraw a consent at any time without affecting earlier processing, and the right to complain to a supervisory authority — in Switzerland the Federal Data Protection and Information Commissioner (FDPIC); in the EU or UK, your local authority.

The route: the data-request form or legal@purposesource.org. If you have an account, you can also get a copy of your data yourself, under Download your data on your account page: a job that runs once a day prepares one file of what our database holds about your account, with a list of what it leaves out and why, and you download it there through a link you ask for. You may be asked to sign in again before you ask for the copy and before you get the link, and you can have one copy at a time; section 11 says how long the copy and its link last. You can also delete your account yourself from your account page (section 3). We verify your identity proportionately (for a request about attribution data, by having you sign in with the same platform account), answer within the period the law sets — 30 days under the FADP, one month under the GDPR — usually much sooner, and charge nothing. Erasure does not reach the ledger or the transparency log, which are append-only public records (sections 6 and 11), the records that section 3 lists as kept after an account is deleted, or accounting records within their statutory retention; it does reach display identity, your contributor page, your messages from the Voting tab, your answers and written answers in votes, contact data and e-mail addresses, the GitHub token, and opt-in emails, and it revokes certificates issued to you on request; you can also withdraw them all yourself with Withdraw my certificates (section 7).

The right to object to attribution. If you never want your contributions attributed, displayed, or used to direct funds, you may be placed on the exclusion list. The list stores a salted hash of your GitHub account ID and the time you objected — no login, no reason text — and only you can undo the objection (below), so that no future operator can quietly undo it. It also hides your contributor page at once and empties its draft and facts, and its published versions and adopter facts are deleted at the next scheduled clean-up (section 8). No new certificate is issued to you, and every certificate you show returns to Private, leaves your page and loses its public share picture, while the certificate itself is not revoked: to have your certificates revoked as well, press Withdraw my certificates before you object (section 7). Once you have objected, the certificates page is closed to you until you undo the objection (below), so undo it, withdraw them and object again.

Undoing your objection. You can undo it yourself in the dashboard, after signing in with GitHub again as the same account. Nobody else can: we built no way for a steward, an administrator or an automated job to undo an objection. Attribution counts you again from the next monthly count, unless you once deleted an account that signed in with the same GitHub account: attribution never counts a GitHub account again after an account deletion. The months counted while your objection stood stay uncredited, and what it made anonymous stays anonymous: the monthly credit records made before the undo keep their figures with a pseudonym in place of your identity, even those our daily clean-up had not yet reached when you undid it. What the objection deleted or turned off does not come back by itself: a contributor page and a certificate’s Public link or On my page are yours to choose again, and so are yearly contributor certificates, which the undo switches off (sections 7 and 8). We keep a record of each undo: the same salted hash and the time you undid it, and nothing else. Like the list, it is permanent, because the newest entry says whether your objection stands, and an account deletion removes neither (section 11). Our systems read them to decide whether attribution counts you, what to make anonymous and which parts of the dashboard you can use, and to show you your objection there; they are not published. You can object again at any time.

Objecting to your certificates. We issue and keep contributor certificates on our legitimate interests (section 10), so you can object to them at any time, with no reason needed, without objecting to attribution as a whole. On the certificates page of the dashboard, turn off Issue my yearly certificates to stop new ones, and press Withdraw my certificates to withdraw every certificate issued to you (section 7). After a withdrawal, the log keeps the fingerprint of each certificate that was in it, with a revocation entry beside each one revoked, and each revoked certificate’s status record says so; none of these names you. We also keep, privately, each withdrawn certificate, which names you, so that you can still see and download it in the dashboard; section 11 says for how long.

Steps that run without a person. A purchase that matches a sanctions list, or whose registered name reads as a person’s, is held automatically: nothing is issued or published while it is held, and a person decides whether to release or refund it. A repository claim is suspended automatically when GitHub no longer confirms that the claimant administers the repository, or when the claimant’s GitHub token no longer works. A repository that meets the conditions in section 6 is listed in the registry without a person’s review. Each year’s contributor certificates are issued from the locked credit records without a person (section 7). A contributor page can be published only while it shows a credited repository, a certificate or a registered repository where its owner adopted the licence, and it leaves out a name, a link or a certificate that our published rules do not accept. The coverage function computes an answer from published records. A person reviews any of these on request, through the route above.

13. Recipients and transfers

The recipients of personal data are the subprocessors listed, with purposes, data categories, and residency, on the Trust Center’s operations page. That list is part of this notice: until the notice’s first public use, a change to it updates this version in place; after that, it publishes as a new version of this notice at a new URL.

The Association’s own stores — the account service’s database, its storage and logs, and the key vault — are in Switzerland, in Microsoft Azure’s Switzerland North region. Where a subprocessor or another recipient processes data in the United States (edge logs, email delivery, error telemetry, source hosting, sign-in with GitHub), the transfer rests on standard contractual clauses and, where the provider is certified, the Swiss–US Data Privacy Framework. Switzerland is recognised as adequate by the European Union. The full residency statement lists every exception.

14. Children

This site is not directed at children. GitHub accepts people from the age of 13, so someone whose contributions a project credits, and who signs in with GitHub, may be 13 to 15 years old. We weighed what we do for that age group on its own (section 10). For them as for everyone, a contributor certificate is issued private and stays private, and nothing shows a person publicly as a contributor unless they choose it themselves, from an account they control. We ask nobody’s age except before something about them is made public: publishing a contributor page asks you to confirm that you are 16 or older, and the page’s record keeps that confirmation (section 8); and showing a certificate publicly (Public link or On my page) asks the same, unless your page’s record already holds it (section 7).

15. Changes

Until its first public use, this first version is corrected in place. After that, when this notice changes, the new version is published on this site and announced on the Trust Center, and every version, this one included, stays permanently readable at its own numbered address; this one’s is /legal/privacy/v1.