Repo-Derived Contact Clearance: Cleared, Restricted, or Off-Limits

This standard decides what a contact route found on a code host or package registry may be used for before it reaches a CRM or an outreach sequence. It is written for recruiting-ops and rev-ops owners who answer for how data was gathered. It gives three grades, the ordered tests that assign them, the provenance record to attach to each address, and a checklist to verify the work before anything is sent.

The existing repo guides tell you whether a mined address belongs to the right person. This one assumes the match is correct and asks a different question: is that address cleared for storage, for a sequence, for sharing, or for nothing at all?

What Cleared, Restricted, and Off-Limits mean

Each grade is a set of permissions. Cleared allows CRM storage and sequenced outreach with notice. Restricted allows one-to-one contact only, with no sequence and no sharing. Off-Limits allows no outreach and no storage as a contact route.

A contact route is one address or channel plus the place it was found. The same address found in two places is two routes and can carry two grades. Always record the best-graded route you can document, not the first one you found.

Three rules hold across all grades:

• Notice is owed under every grade. Grading decides what you may do. It does not remove the duty to tell a GDPR-covered person where you got their data.
• Off-Limits records are kept, not deleted, as suppression entries. You need to know the address exists so you don't re-import it from another source. Store the reason and nothing you would use to make contact.
• Restricted cannot be upgraded by usage. A Restricted route that gets a reply does not become Cleared. The person replying gives you a new route (their reply address, in a conversation they chose to have), and that new route gets graded on its own.

A correctly matched address is not a cleared address. Matching answers who; clearance answers what for.

Which rules a repo-derived address has to clear

A repo-derived address has to pass four layers of rules: privacy law on notice, the platform's terms, the purpose the field states for itself, and any signal the person has given. Passing an outer layer never overrides a refusal at an inner one.

The platform layer: GitHub AUP Section 7

GitHub's Acceptable Use Policies have 11 numbered sections. Section 7 is "Information Usage Restrictions" and Section 8 is "Privacy". The Section 7 text reads:

"You may not use information from the Service (whether scraped, collected through our API, or obtained otherwise) for spamming purposes, including for the purposes of sending unsolicited emails to users or selling User Personal Information (as defined in the GitHub Privacy Statement), such as to recruiters, headhunters, and job boards."

Section 1 also makes users responsible for using the service in compliance with all applicable laws. Three points matter for grading:

• The method doesn't matter. "Scraped, collected through our API, or obtained otherwise" covers a bare git clone, which exposes every author's address without touching the API. The rule doesn't try to stop collection. It controls what you do with the address afterwards.
• Selling to recruiters is named explicitly. That is the CRM-sharing and resale path. It is why Restricted means no sharing, not just no sequence.
• "Spamming" is contested at the one-to-one level. On a public Hacker News thread, one commenter argued that the rule bans selling API-extracted data to recruiters but does not seem to ban recruiters acquiring it themselves. That reading doesn't deal with the "sending unsolicited emails to users" clause, which covers the send itself. This standard doesn't settle the dispute in your favour. It caps on-platform routes at Restricted.

Two parts of GitHub's terms I couldn't confirm against the live page: the Section 8 wording about using information only for the purpose the user authorised, and GitHub's separate API terms. Pull the live text before you quote either in your own policy. The section number of the clause banning "excessive automated bulk activity" is also unverified.

On enforcement, a GitHub staff member replying on a Hacker News thread called scraping commit data to send unsolicited email "a clear violation of GitHub's Terms of Service". He said GitHub "can and do take action, including banning the account", and he admitted the off-platform scrape-then-spam pattern "is the hardest to police". Other users on the same thread said their spam reports were never acted on, and no named, confirmed bans have been published. Developers have raised the same complaint publicly several times over the years. In one earlier case the recruiter "admitted to following a guide online that used the API".

The law layer: GDPR Article 14

When you collect personal data from somewhere other than the person, Article 14 says you must tell them. Two content requirements matter here:

• Article 14(2)(f): the notice must say "from which source the personal data originate, and if applicable, whether it came from publicly accessible sources".
• Article 14(2)(b): if your legal basis is legitimate interest under Article 6(1)(f), you must state that interest.

The deadline is the earliest of three triggers:

Sources differ on emphasis. Some audit guidance lets you inform "within one month or at first contact", while other commentary stresses that whichever comes first applies. This standard takes the stricter reading.

Each route's stated purpose and default verdict

Every route documents its own purpose, and that purpose sets the ceiling on what the route can be used for. The table below shows what each source says its field is for.

Two routes aren't in that table because their purpose isn't documented. I found no GitHub statement of what the profile public email is for. The npm maintainers field wasn't checked, so its purpose is unverified. Grade npm fields as Restricted at most until you've read the registry's own documentation.

Default verdicts

The grading tests

Apply these tests in order. The first one that fires sets the verdict. Two reviewers who follow this order will reach the same grade, which is the whole point of writing it down.

1. The domain is users.noreply.github.com. Off-Limits.
2. The person is on your suppression list or has objected. Off-Limits.
3. The route is a commit author email. Off-Limits.
4. The route states a non-contact purpose (security.txt Contact, SECURITY.md). Off-Limits.
5. The address is a role or list address, not a person. Off-Limits.
6. You can't tie the address to the person through a second source (for registry fields, the project repository). Off-Limits.
7. The address is at the corporate domain of an employer the person no longer works for. Off-Limits.
8. The source page says it doesn't want recruiting or sales contact. Off-Limits.
9. The route was found on the code host (profile, README) or in a registry metadata field. Restricted.
10. The route is on the person's own off-host site and published for contact. Cleared.
11. Nothing above fired. Off-Limits until the route is classified and the policy is amended.

What each verdict proves, and when it lies

• Personal-site listing, Cleared. This proves the owner chose this channel for inbound contact. It lies when the "personal site" is a mirror of a README hosted on the code host, or a team page listing a shared inbox. Check who controls the domain and whether the page invites contact.
• Profile email or README listing, Restricted. This proves the person put the address in public on purpose. It lies when the README belongs to an organisation and the address is a role inbox. Test 5 catches that. If your counsel reads Section 7 as banning any unsolicited email built on service information, move this row to Off-Limits. Make that a deliberate, written switch in your policy, not a reviewer's judgement call.
• Package fields, Restricted. These prove someone put an address in the package metadata. They don't prove who. PEP 621 says the difference between Authors and Maintainers "is unspecified and ambiguous", and Author-email may hold several comma-separated addresses. Grade each address separately. This standard does not cover the package registry's own terms of use. Read those before you adopt this row.
• Commit email, Off-Limits. GitHub "uses your commit email address to associate commits with your account". The address leaks because someone used git, not because they offered it to you. No condition upgrades it.

How much of a maintainer pool falls under GDPR

About two in five maintainer profiles in a three-country slice sit under GDPR-family rules, so for a large share of any developer pool, every first message has to disclose its source. In Refolk's index of professional profiles, these are the counts of profiles with "open source maintainer" in the headline:

Two more observations from the same index affect how you handle routes:

• No single employer dominates. In a US sample of 25 of these profiles, the top employers each appear only once: Okta, Docker, Microsoft, AWS, CNCF, and Dynatrace. You can't build a short allow-list of "current employer" corporate domains. Test 7 has to be run person by person.
• German maintainers cluster outside the capital. In the German sample, Karlsruhe (4) and Berlin (3) are the top regions. A search limited to Berlin misses part of the pool you need to notice-check.

US state privacy law wasn't researched for this standard. For US-only pools, the platform and field-purpose layers still apply in full, and the law layer is an open item for your counsel.

The cheapest way to apply this standard is to start the search at the Cleared route rather than mining commits and grading down. Asking Refolk for maintainers who publish a contact page on their own site returns candidates whose best route is already the one test 10 accepts.

The provenance record an auditor or complaining developer will ask for

A provenance record has to let a second reviewer reopen the exact source and see the address where it was found, without asking the sourcer. If it can't do that, it fails both an audit and the first email from a developer asking "where did you get this?"

GDPR audit guidance asks for an "inventory of all indirect data sources with categories of data received". It also warns that "'Third parties' is not specific enough. Name the type of source or, ideally, the actual source." That sets the bar at the source level. No published guidance sets field-level items such as commit SHA or capture method, so the fields below are this standard's working minimum, not a regulator's list.

route_type: personal_site | profile_email | readme | registry_author | registry_maintainer | commit | noreply | security_contact
address:
verdict: cleared | restricted | off_limits
verdict_test_fired: (number of the first grading test that fired)
source_url: (exact page, file, or package release URL)
source_anchor: (commit SHA | package name and version | page capture reference)
captured_at: (ISO timestamp)
capture_method: api | scrape | manual
stated_purpose_citation: (documentation URL for this route type)
person_match_evidence: (second source tying address to person, e.g. repository link)
employment_check: (current employer and start date; commit date if commit-derived)
jurisdiction: gdpr | uk_gdpr | us | other
lia_reference: (ID of the legitimate-interest assessment for this route type)
notice_due_by: (earliest of capture + 1 month, first contact, first disclosure)
notice_sent_at:
objection: none | (date and channel)
reviewer_1:
reviewer_2:

Why each of the harder fields is there:

• source_anchor. Commit history keeps old addresses ("Any commits you made prior to changing your commit email address are still associated with your previous email address"). Without the SHA or version you can't show which address existed at which point.
• capture_method. Section 7 names scraping and API collection alike, so this field won't protect you. It tells the auditor how the data entered your systems, and it tells you which pipelines to fix if a route type is reclassified.
• notice_due_by. You can compute this the moment you capture the address. Store it so a report can list overdue notices before they become a complaint.

How to grade a contact route, step by step

Grading takes a sourcer a few minutes per route and an ops owner a one-time assessment per route type. The procedure runs from the cheapest exclusion to the most expensive judgement, so most bad routes are dropped in seconds.

On step 4, auditfront's Article 14 guidance says exemption reasoning should be documented "thoroughly". The same discipline applies to a legitimate-interest assessment. Write one per route type, not per person. It should cover why the outreach is in the person's reasonable expectation given where they published the address, and why a less intrusive route isn't available.

On step 5, calibrate before go-live. Have two reviewers independently grade the same sample of records, compare, and rewrite any test that produced a split. A test that two people read differently is a policy defect, not a reviewer error.

On step 6, the notice can be a short block in the first message, linked to your full privacy notice:

Where I found your details: I came across your name and this email address at {exact source URL}, which is publicly accessible. I captured them on {capture date}.

Why I am holding them: {company} has a legitimate interest in contacting you about {specific role or reason tied to your public work on X}. Your details sit in our {recruiting or sales} system and are not shared outside the team working on this.

If you would rather not hear from me, reply "no" and I will delete your contact details and add you to a do-not-contact list so you are not contacted again from any source. Full details of how {company} handles your data: {privacy notice URL}.

Step 7 is yours alone. I found no do-not-contact handling procedure in GitHub's terms, so the platform gives you nothing to lean on. The suppression list has to sit upstream of every import, because the same person can reappear through a registry field or a different repo.

How repo contact clearance goes wrong

Most clearance failures are false positives: a route that looks fine to a busy sourcer but fails a test they skipped. These are the eight that matter, each with the check that catches it.

• Treating "public" as consent. The false positive is "it's in git log, so it's fair game." Check: public availability is not an Article 14(5) exception. The notice is owed whatever the source, and commit emails fail test 3 regardless.
• The stale commit email. Old commits keep a previous address after the person changes it, so commit history can hold several addresses per person. A corporate address from a former employer reaches the wrong mailbox, and someone else at that company reads your pitch. Check: is the commit date after the person's current employment start date? If not, test 7 fires.
• Reading a noreply alias as reachable. Accounts created after 18 July 2017 get ID+USERNAME@users.noreply.github.com, and older aliases use a bare form on the same domain. A prefix match misses one form. Check: match on the domain, never the local part.
• Using security.txt for recruiting. RFC 9116 makes Contact and Expires mandatory and defines Contact as "a method that researchers should use for reporting security vulnerabilities". GitHub suggests SECURITY.md as the place for "a preferred contact method for any 3rd party abuse inquiries". An address like security@ is a role, not a person. Check: grade both Off-Limits for any outreach, with no exceptions.
• Taking Maintainer-email at face value. PyPI shows the Maintainer name linked to the first Maintainer-email, which may belong to someone else. Check: compare against the project's repository and fail test 6 if the two don't agree.
• Calling one-to-one email "not spam". A personalised template sent one at a time is still bulk if it goes to hundreds of people. Check: count sends per template. If a Restricted route has ever been enrolled in a template that goes out at volume, that is a breach of the grade, whatever the merge fields say.
• A vague source line. "Public sources" or "GitHub" fails an audit, and it fails the developer who asks. Check: the record holds the exact URL plus the SHA or package version.
• Assuming the platform enforces. GitHub's own staff say off-platform scraping is hard to police, and users report unanswered spam reports. Check: never read the absence of a ban as evidence of compliance. Your provenance record and grade are the evidence.

GitHub's doxxing policy lists "personal, private email addresses", and says GitHub "will take context into account as well as whether the reported content is publicly available elsewhere". That is a takedown policy, not a usage permission. A developer who finds a commit address republished in a shared list has a platform remedy as well as a privacy-law one.

GitHub's own older documentation said it "does not get many reports of spam being sent to the email addresses in Git commits". I found no published measurement of how commit addresses split between noreply, corporate, and personal domains, so nobody knows how often test 1 or test 7 will fire on your data. Measure it on your first batch and keep the numbers.

Keeping the standard current

This standard depends on documents that change: GitHub's live policy text, registry specifications, and your own legal reading. Re-check those documents on a fixed schedule, and re-run the two-reviewer calibration whenever a test changes.

What to re-check, and how:

• GitHub Acceptable Use Policies. Read the live page and confirm Section 7 still contains the "unsolicited emails" and "recruiters, headhunters, and job boards" wording. Pull the Section 8 text and the separate API terms, which this standard couldn't verify, and record the date you read them.
• Registry documentation. Re-read the PyPA core metadata spec for Author-email and Maintainer-email. Read the npm documentation for its maintainers field, which wasn't checked here, before grading any npm-sourced address above Off-Limits by test 11.
• Your Section 7 switch. Record in writing whether counsel keeps on-host routes at Restricted or moves them to Off-Limits, and who decided.
• US law. This standard leaves the law layer open for US subjects. Close it with counsel before you treat US routes as anything other than platform-bound.
• Calibration. After any test is added or reworded, have two reviewers re-grade a fresh sample. Ship the change only when they agree.
• Overdue notices. Run a weekly report on notice_due_by against notice_sent_at, and delete or notify anything past due.

When a new route type appears, such as a new registry or a new metadata field, it is Off-Limits under test 11 until someone has found its documented purpose, written a legitimate-interest assessment, and added a numbered test. Refolk queries can be pointed at whichever route your policy currently clears, so the policy change and the sourcing change can ship on the same day.