Skip to content
Gelhaus Solutions
Archived version

Contribution Checker privacy notice

What signing a contributor licence agreement actually records about you, including the parts that cannot simply be erased afterwards.

Version 2026-10-20Published
This is the current version.

It is kept here under a fixed address so it can be cited and compared. The live document is the same text.

Who is responsible

For an instance you run, you are, and we process nothing.

Where we host it for a project, that project is the controller of its contributors' data and we are its processor. For our own account and infrastructure data the controller is Gelhaus Solutions, Eichenwald 3, 49624 Löningen, Germany, contact@gplatform.org.

What is stored

Taken from the database schema, because "certain information" tells you nothing.

Your account. Name, email address, an optional image, and your GitHub numeric id and login. A country code was collected after sign-in until 1 October 2026; it was never used, is no longer collected, and the stored values have been deleted. Identity is held in our own self-hosted Hexclave; the columns here are a link to it and a cache of two permissions.

Your application to contribute. The answers you gave to the project's questions, the decision, who made it, the reason, any notes or reviews recorded against it, and any appeal.

Your signature, and this is the part to read. Signing a contributor licence agreement records:

  • your printed legal name, as you typed it;
  • the exact affirmation text you were shown, so what you agreed to is preserved rather than reconstructed;
  • the IP address you signed from and your browser's user agent;
  • your GitHub id and login and a snapshot of your email address;
  • the version number and content hash of the document you signed;
  • your answers to any custom fields the project defined;
  • and the signature itself. Typed, drawn, or uploaded. Where you drew or uploaded one, the image bytes are stored, and they are retained immutably.

A corporate agreement records the company's full legal name, registered address, country, point of contact and contact email, the authorised representative's title and typed signature, and the roster of contributors it covers.

Where the ledger is kept. A project's signature ledger can be kept in GPlatform Legal, our own legal system, instead of in Contribution Checker. It is the same record with the same chain, held by us on the project's behalf in the same way; Contribution Checker reads it from there to check a pull request.

The ledger. Every signing, approval, rejection, revocation, roster change and waiver is written to a hash-chained log: each entry carries the hash of the one before it, so the sequence can be shown not to have been rewritten afterwards.

Audit events, notifications and rate-limit records for the operation of the service.

If you opened a pull request but never signed in here. When you open a pull request against a repository that uses Contribution Checker, we receive from GitHub, not from you: your GitHub login and numeric id; the pull request's number, title, body and the files it changes; its commits with their messages and the author and committer email addresses; and from your public GitHub profile, when the account was created, how many public repositories and followers it has, whether it shows a public email address and a picture, and how many pull requests you have opened and had merged. We keep your login and id with the pull request's check, and the result of each quality check. Commit email addresses and your profile details are read only to compute those checks and are not stored. For a project's repositories, that project is the controller and we act as its processor; for Postiz's repositories, that is Postiz. The basis is the project's legitimate interest in knowing who contributes (Art. 6(1)(f) GDPR). These records are kept for as long as the law allows us to keep them, as the record of which pull requests were let through and why. You have the rights described below, including the right to object.

AI runs, where a project enabled them. The task, a hash of the input, the validated answer, token counts and the model actually served. Raw model text is kept only when the answer failed to validate, because that is the only way to debug a drifting prompt and it is not worth storing otherwise.

Where data goes

GitHub. The service is driven by a GitHub App: it reads pull requests and repository metadata and writes check runs and comments back. Your GitHub identity is how you are known here in the first place. GitHub, Inc. is in the United States. GitHub is certified under the EU-U.S. Data Privacy Framework.

OpenRouter, where a project has enabled an AI task. What is being judged goes there (application answers, a pull request body) and OpenRouter routes it on; on the instance we host, to Groq running gpt-oss-120b. Every task is off by default and off is what an unreadable configuration falls back to. The prompt tells the model not to infer nationality, gender, age or employment from a name or writing style. OpenRouter, Inc. is in the United States; the transfer rests on the European Commission's standard contractual clauses in its data processing agreement.

On the instance we host, this is switched on for the projects Gelhaus Solutions runs itself and for Postiz, whose contributor gate Gelhaus Solutions operates. If you applied to one of those, or opened a pull request against one, your answers and your pull request body can be sent there. It is not switched on for any other project.

Sentry, on its EU data region, for error and performance reporting: exceptions, stack traces, the failing request, and the internal identifier of a signed-in user where there is one. IP addresses and request bodies are not sent. That rests on our legitimate interest in a service that works and is secure (Art. 6(1)(f) GDPR), and you may object at any time (Art. 21 GDPR). Functional Software, Inc. is in the United States and certified under the EU-U.S. Data Privacy Framework.

A recording of your visit is made only if you say yes. The default is no recording. A question asks, with two equal buttons, and a "Session recording" link opens it again. If you say yes, Sentry receives a replay of the visit from the first page to the last: what was on screen, the clicks and what changed. It is not masked: it shows the page as it was on screen, including what was typed into a form, because a masked replay cannot show what went wrong. To join the pages of one visit, the Sentry script keeps a random identifier in your browser's session storage, which is gone when you close the tab, and your answer is kept in your browser's local storage under cc.replay-consent so that the question does not come back on every page. The recording rests on your consent (Section 25(1) TDDDG, Art. 6(1)(a) GDPR), which you can withdraw at any time with the same link, without affecting what was recorded before.

Hosting is IONOS SE (Germany) and our own hardware in Germany. Mail runs on our own servers. Secrets are resolved through our own Vault.

Why

Operating the service and your account is performance of a contract, Art. 6(1)(b).

A signature record is evidence, and the reason it is kept is that it must be capable of being proved. The IP address, the user agent, the affirmation text and the chained ledger exist for that and nothing else: Art. 6(1)(f), and where the agreement is with the project, Art. 6(1)(b) between you and them.

Automated checks, abuse controls and the security of the service are Art. 6(1)(f).

How long, and what erasure cannot reach

Account data is kept until the account is deleted. Audit events and AI results are deleted 24 months after they are recorded. A rate-limit record, which can contain an IP address, is deleted within a day of its time window ending. Notifications are kept until the account is deleted.

A signature is kept for as long as the project keeps the contribution it covers, and ten years after the last contribution under it, unless the project operating the instance sets a different period. That is the honest answer: a CLA that could be erased on request would not do the job it exists to do.

A signature can be revoked, which is recorded with who did it, when and why, and revocation is the ordinary route. Revoking marks the signature as no longer conferring coverage; it does not delete the record that it once existed, and the ledger entry stays because the chain is what makes the ledger evidence.

If you want a signature record erased rather than revoked, ask the project: they are the controller and it is their call, and both of us will tell you honestly what is and is not achievable.

The account menu and the list of our products

The pages carry a shared account menu and a list of our products, drawn by GPlatform Identity, our own service under the same controller. So that the list is right on your first day, this product tells GPlatform Identity that an address it has verified uses it: a keyed hash of the address, not the address, and the time of the last report. GPlatform Identity keeps it for 180 days after the last report and uses it for nothing else. The GPlatform Identity privacy notice describes it, including your rights over it.

Why. An account menu that shows the products you already use (Art. 6(1)(f) GDPR).

Precautions against an attack on our systems

If our systems may have been compromised, Gelhaus Solutions can put the instance we host into a lockdown through a security service of its own, GLockdown. A lockdown has stages. First, no new accounts. Then only super-administrators and the owners, administrators and reviewers of a project can sign in, and applicants are refused. Then only super-administrators. At the last stage nobody can sign in, sessions included. At a higher alert level the GitHub bot also stops, so pull requests wait until it is lifted. Public pages carry on at every stage.

We also keep decoys that no real person uses: an administrator sign-in and an API key. If somebody signs in as the decoy or sends the decoy key, the attempt is refused like any unknown account or key and reported to GLockdown with the time and the address and browser it came from, so that a lockdown can be raised.

Why. Defending the service and the people who use it against an attack (Art. 6(1)(f) GDPR).

What you accepted, and the notices we send

When you accept our terms, GPlatform Legal, another service of ours under the same controller, records it: the address of your account, the identifier the product knows you by, which versions you accepted, when, through which product, and your IP address and browser at that moment. It also keeps the mails with which we announce a change before it binds (to your address, with whether they arrived and any bounce) and anything you object to; they come from legal@gplatform.org. The entries are chained by hashes so that nobody can change them afterwards. Proof of acceptance is a record in its own right and is kept longer than your account data, because we have to be able to show what you agreed to: at the end of the third calendar year after the year your account closed (the sixth if you ever paid for something), your address is removed, the identifier becomes a keyed hash, your IP address and browser details are erased from each entry, and what stays is the version, time, source and hash. The GPlatform Legal privacy notice describes that service in full.

Why. Proving the consent you gave and the terms you agreed to, and informing you of changes as the general terms require (Art. 6(1)(b), (c) and (f) GDPR; Art. 7(1) GDPR; Art. 17(3)(e) GDPR).

Your rights

Access, rectification, erasure, restriction, portability and objection, subject to the section above. Where we host the instance, ask the project first; they can act, and we assist them. You can download everything held about you as a JSON file yourself, with "Download my data" in your account menu.

You may complain to a supervisory authority. Ours is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover.

Version identifier
contribution-checker-privacy-2026-10-20
Content hash, SHA-256
99c9a1ba7d22e99c18144a12fb8c40a0e5eaad9f48addee38424eca53442974b
Every version of this document
2026-10-20 · this one in force since 20 October 2026
2026-10-03.3 in force 3 October 2026 to 20 October 2026
2026-10-03.2 in force 3 October 2026 to 3 October 2026
2026-10-03 in force 3 October 2026 to 3 October 2026
2026-10-01 in force 1 October 2026 to 3 October 2026
2026-09-06 in force 6 September 2026 to 1 October 2026
All documents