Contribution Checker privacy notice

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, egelhaus@ennogelhaus.de.

What is stored

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

Your account. Name, email address, an optional image, your GitHub numeric id and login, and a country code collected once after sign-in. 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.

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.

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.

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.

On the instance we host, this is switched on for the projects Gelhaus Solutions runs itself. 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 other people's projects.

Sentry, on its EU data region, for error and performance reporting: exceptions, stack traces, the failing request, and the identifier of a signed-in user where there is one.

Hosting is IONOS SE (Germany), Contabo GmbH (Germany, being wound down), 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.

A signature is kept for as long as the project relies on it, which for a contribution licence is normally as long as the contribution is distributed. 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.

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 may complain to a supervisory authority. Ours is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover.