The Lawful-Use Standard for Repository-Sourced Contact Data

This standard resolves one question, record by record: is a name, email, or handle I pulled from a public repository lawful to store and use for outreach? It is written for recruiting and revenue operations and anyone answerable for how the data was gathered. It turns scattered platform terms and data-protection rules into a pass/fail grade, so two reviewers looking at the same record reach the same verdict with the same cited rule.

The generic lawful-sourcing standard covers candidate data broadly. Repository data has its own traps: platform terms that name recruiter outreach outright, commit-metadata quirks like noreply placeholders, and the wide gap between "publicly visible" and "lawful to contact." This document names each trap and tells you exactly which rule decides the grade.

What the standard grades and where it applies

This standard grades a single repository-derived contact record: one person, one identifier (name, email, or handle), captured from a public repository or its metadata. It applies the moment you hold a real identifier and intend to store or contact.

The grade is one of three values, and every record lands in exactly one.

Two rules sit above everything else and decide most cases before you look at anything subtle. First, GitHub's Acceptable Use Policy (AUP) bans using Service information for selling personal information to recruiters, headhunters, and job boards, and applies that ban whether the data was scraped, collected through the API, or obtained otherwise. Second, public visibility alone does not create a lawful basis under GDPR; you need a documented Legitimate Interests Assessment (LIA) on file before you process. A record fails the standard if it trips either rule, no matter how clean it looks otherwise.

Why platform terms decide this before GDPR does

Start with the platform terms, because they can rule out a use that GDPR might otherwise permit. GitHub's Acceptable Use Policy names recruiter, headhunter, and job-board use as a prohibited purpose in plain text, and the legacy Corporate Terms of Service repeats the same ban.

The exact AUP language matters, so hold it precisely. You may not use information from the Service, whether scraped, collected through the API, or obtained otherwise, for spamming purposes, including for the purposes of sending unsolicited emails to users or selling personal information, such as to recruiters, headhunters, and job boards. The policy adds a positive obligation: if you collect any personal information from the Service, you will only use it for the purpose the user authorized, will reasonably secure it, and will respond promptly to complaints, removal requests, and "do not contact" requests.

Two consequences fall out. The banned act that the terms name outright is selling or sharing the list to recruiters, headhunters, or job boards. If the data leaves your controller boundary to any of those, that is the one use the terms prohibit by name, and the record cannot be usable. Sending your own unsolicited outreach off scraped commit emails also runs into the spamming clause. This is why "github terms of service recruiting outreach" is not a settled green light; the terms were written with this exact activity in mind.

The terms were written with recruiter outreach in mind, so intended use is the load-bearing variable, not access path.

The API is not a safe harbour

A common misread: an official token or the REST API somehow launders the record. It does not. The AUP applies the recruiter, headhunter, and job-board ban to data obtained by any method, and it lists the API explicitly alongside scraping. So "github commit email scraping legal" and "collected it through the API instead" land in the same place for personal-information use.

The paths differ only in rate limits, which is an operational constraint, not a permission.

Column source: GitHub REST API rate-limit documentation. Read this table as capacity, not as a compliance signal. Authenticating raises your ceiling from 60 to 5,000 requests per hour; it does nothing to the AUP restriction on what you may then do with a person's data.

Reading commit-email metadata correctly

Every Git commit identifies its author by an email address, but not every address is a mailbox. The single most common false positive in this work is treating a GitHub noreply placeholder as a contactable email, so classify the email form before anything else.

There are three forms you will meet in git log:

• A real address, a genuine mailbox the author committed with.
• The classic noreply placeholder, of the form username@users.noreply.github.com, which a user picks when worried about spam for browser-based operations.
• The ID-prefixed noreply variant, which accounts created after July 18, 2017 receive, reported to look like 123456+username@users.noreply.github.com.

The rule is mechanical: inspect the author and committer email in git log, and reject any address ending in users.noreply.github.com. It is a non-contactable placeholder, not a mailbox. This is a check two reviewers will always agree on, which is exactly why it belongs at the front of the pipeline.

One quirk defeats a naive privacy assumption. GitHub's private email setting only affects new commits. If a user later goes private, any real address already in the historical log stays exposed. That does not make the old address safe to use; it makes the capture date load-bearing. Check the capture date against the user's current settings before relying on a historical address, and treat a real email on a now-private account as restricted, not automatically usable. A privacy signal makes the balancing test in your LIA harder, not easier.

Why "publicly visible" is not "lawful to contact"

Public visibility does not create a lawful basis. To rely on legitimate interests under Article 6(1)(f), a controller must first document a Legitimate Interests Assessment, and without a completed LIA on record before processing begins, the legal basis does not exist. This is the rule most repository-sourcing runs get wrong, and it is the answer to "gdpr git commit personal data" and "email github contributors legal basis."

The LIA is a three-part test:

1. Purpose test. Are you pursuing a legitimate interest?
2. Necessity test. Is your specific use necessary for that purpose?
3. Balancing test. Do the person's interests override your legitimate interest?

Their interests are likely to override yours if they would not reasonably expect you to use the information in that way, or if your use would cause unjustified harm. A developer publishing code so others can build on it did not publish so a recruiter could email them; that expectation gap is what the balancing test exists to catch.

Transparency is a separate, mandatory obligation. Businesses must state how the recipient's data was obtained. So even a record with a clean LIA still needs outreach that names the source. The LIA makes the processing lawful; the transparency line makes the contact lawful.

Note two moving parts to re-check rather than memorise. The EDPB tightened legitimate-interest criteria in its Guidelines 1/2024, so re-read the current ICO legitimate interests guidance before you finalise a template LIA. And an erasure audit across 764 controllers in 32 states rated compliance only "average," with 9 data protection authorities opening investigations; the recurring failure was missing internal procedure, not deletion mechanics. That is precisely the source-URL and LIA-reference discipline this standard enforces.

Where thin talent pools raise the temptation to over-collect, Refolk lets you ask for the specific people you need in plain English rather than commit-mining every repository by hand, which keeps you away from the aggressive collection that draws complaints. Rust talent is scarce, and scarcity is exactly where a single ignored "do not contact" is most visible.

The record fields two reviewers both need

No authority publishes a canonical field list, so this is a synthesis driven by GDPR accountability: maintain records of your data sources, your legitimate interest assessments, and systems to honor opt-outs and deletion. The six fields below are the minimum for two reviewers to grade a record identically.

Pair these with a data subject request log that tracks the request date, identity verification steps, systems modified, and the final response. Provenance is where audits fail, not deletion mechanics, so the fields above are the spine of the whole standard. A record missing its LIA reference or a real-email flag cannot be graded usable, and that is a rule, not a judgement call.

source_url:            https://github.com/<org>/<repo>/commit/<sha>
capture_date:          2024-06-01
email:                 jane@example.com
email_type:            real            # real | noreply
repo_licence:          MIT
lia_reference:         LIA-2024-014     # dated assessment on file
lia_date:              2024-05-20       # must precede first_contact_date
intended_use:          own_outreach     # own_outreach | internal_pipeline | (never: sell/share)
first_contact_date:    (blank until sent)
dsar_status:           none             # none | open | closed
grade:                 usable           # usable | restricted | must-discard
rule_cited:            AUP-fit + LIA-2024-014 dated before contact

The grading procedure

Run every record through these seven steps in order. The procedure is designed so the mechanical checks (steps 1, 2, 6) catch most rejects cheaply before the expensive human judgement (step 4) is spent.

On the last step, the sources disagree on one detail worth deciding as policy. The one-month erasure window is extendable by two months for complex or numerous requests, provided you notify the person. Whether the clock pauses during identity verification is contested: one reading runs it from the date of receipt, while ICO-aligned guidance lets the time limit begin when you obtain any additional information you need, such as identity verification. Pick one interpretation, write it into your policy so both reviewers apply it the same way, and log a dated closed loop either way. Recruiting retention is commonly cited at 6 to 12 months absent documented grounds to keep longer.

How this goes wrong

Most bad grades come from a small set of repeatable mistakes. Each has a false positive, meaning the record looks fine, and a mechanical check that catches it. Treat this table as the reviewer's fault list.

Two of these deserve extra weight because they are the ones a rushed reviewer waves through.

A backdated LIA is legally worthless. Without a completed LIA on record before processing begins, the legal basis does not exist, so the assessment's date must predate the first-contact date in the record. This is a mechanical comparison two reviewers can perform in seconds, and it should be a hard stop.

An acknowledgement is not a deletion. When someone asks to be removed, replying "noted" does not close the loop. The AUP requires prompt response to removal and "do not contact" requests, and GDPR requires action without undue delay. The DSAR log has to show a dated, confirmed deletion, not a promise.

Why cross-border sourcing multiplies the exposure

EU-based teams reaching into larger overseas talent pools fall under GitHub's global terms and under GDPR at once, so the same record can trip both gates. The supply numbers show why the pull toward cross-border sourcing is strong.

Counts and employers are from Refolk's index; the ratio is derived. US Rust supply is 6.7 times Germany's, so an EU team short on local Rust talent will reach into the US pool. That does not shed either obligation. GitHub's AUP is global, so it applies to every record regardless of the subject's location. GDPR applies whenever the data subject is in the EU, and it can apply to EU controllers processing non-EU data. The record you pull from a US contributor and the record you pull from a Berlin contributor face the same AUP gate; only the second adds the full GDPR overlay, but your safest policy is to run both gates on every record so reviewers never have to decide jurisdiction mid-grade.

Verify before you call it done

Run this checklist against a batch before you sign it off. Every item is a checkable statement, not a topic, and a "no" on any required item forces a restricted or must-discard grade.

Keeping the standard current

Two inputs to this standard move over time, so re-check them on a fixed cadence rather than trusting a snapshot. The GitHub Acceptable Use Policy and Corporate Terms of Service can be revised; re-read the current AUP text before each new sourcing programme and confirm the recruiter, headhunter, and job-board clause still reads as quoted here. The legitimate-interest criteria also shift: the EDPB tightened them in Guidelines 1/2024, so re-read the current ICO legitimate interests guidance and refresh your LIA template when the guidance updates.

Set a recurring review, tie it to the LIA reference field so every record points at the version of the assessment it was graded under, and re-grade any record whose privacy setting or source terms have changed since capture. A standard that overclaims is worse than none; where the sources genuinely disagree, such as whether the erasure clock pauses for identity verification, write your chosen interpretation into policy so both reviewers apply it the same way, and revisit it if authoritative guidance settles the question.