Contribution Checker data processing annex

What this annex is

The Art. 28(3) specifics for Contribution Checker where we host it. It is part of the data processing agreement, which carries the obligations.

Contribution Checker is not a GHub product and does not run on GPlatform. That changes its licence, not our obligations to you.

Nature and purpose of the processing

Administering outside contributions to your project: applications to contribute, individual and corporate contributor licence agreements, automated checks against pull requests, and the ledger that records the lot.

Categories of data subjects

• People who apply to contribute to your project, and people who sign a contributor licence agreement, whether or not they go on to contribute.
• Authorised representatives and points of contact at companies signing a corporate agreement, and the contributors on its roster.
• Your maintainers and reviewers, who appear as the actors of decisions.

Categories of personal data

Account and identity: name, email address, image, GitHub numeric id and login, country code, and the link to the identity held in our self-hosted Hexclave.

Applications: free-text answers to your questions, decisions, reasons, notes, reviews and appeals.

Signatures — the material category here: printed legal name, the exact affirmation shown at signing, IP address, user agent, email snapshot, GitHub id and login, the signed document's version and content hash, custom field answers, and the signature itself as typed text or as image bytes where it was drawn or uploaded. Retained immutably.

Corporate agreements: company legal name, registered address, country, point of contact name and email, authorised representative's title and typed signature, approval or rejection and by whom, and the roster of covered contributors with their dispute status.

The event ledger: a hash-chained record of every signing, approval, rejection, revocation, roster change and waiver, with the acting user.

AI runs, where you enable them: task, input hash, validated output, token counts, model served, and raw model text only where validation failed.

Special categories

Not sought and not intended. A signature image is a person's handwriting, which is not an Art. 9 category but is biometric-adjacent and is treated here as material to be minimised: nothing requires a drawn signature, and a typed one satisfies the same flow.

Sub-processors

Those named in the general agreement — IONOS SE and Contabo GmbH, both in Germany, plus our own hardware in Germany — and, for this service:

• Sentry (Functional Software, Inc.), EU data region — error and performance reporting.
• OpenRouter, Inc. (United States), routing to Groq (gpt-oss-120b) — only where you enable an AI task, which is off by default for every task. It receives the content being judged and routes it on. Where you leave AI off, it receives nothing.

It is switched on for the projects Gelhaus Solutions runs itself. That is our decision for our own projects and has no effect on yours.

Because OpenRouter is in the United States, enabling a task is a transfer to a third country and rests on the safeguards in its data processing terms.

Mail runs on our own servers and secrets resolve through our own Vault, so neither is a third party.

GitHub, Inc. (United States) is the integration this product exists to work with rather than a sub-processor of ours: you install a GitHub App against your own repositories, and identities come from GitHub because that is what a contribution is attached to.

Security measures particular to this service

• The event ledger is hash-chained, so a rewritten history is detectable.
• Signature records are immutable; the ordinary lifecycle is revocation, which is recorded, rather than editing.
• Secrets resolve through Vault rather than living in configuration.
• AI is off per task by default and an unparseable configuration degrades to off, so a corrupt value cannot switch a feature on.

Retention, and a real limit on erasure

Account data lasts as long as the account.

Signature records last as long as you rely on them, which for a contribution licence is ordinarily as long as the contribution is distributed. A CLA that could be erased on request would not do its job, and this is the honest statement of that rather than a refusal of Art. 17.

Revocation is the ordinary path and is fully supported. It records who revoked, when and why, and stops the signature conferring coverage. It does not remove the ledger entry, because the chain is what makes the ledger evidence.

Where a data subject asks you for erasure of a signature record, we will tell you plainly what is achievable — ordinarily redaction of a field rather than removal of a chained row — and carry out your decision.

On termination

As set out in the general agreement: return or deletion at your choice, 30 days of export availability by default, backups expiring on their own cycle.