In the EU, contacting someone about a role using data they published themselves is normally done under legitimate interest, GDPR Article 6(1)(f), not consent. Three things come with it: a privacy notice the person can reach when you contact them, since you did not collect the data from them (Article 14), an honest first message that says who you are and where the address came from, and a way to object that actually works (Article 21). In the United States there is no federal barrier to a recruiting email; CAN-SPAM asks for a real sender, a postal address and a working unsubscribe. GitHub's terms let you read public data and use the API, and forbid using it to send bulk unsolicited email. The search is not the risky part; the sequence you send afterwards is.
Public data is still personal data
The most common mistake is to treat a public profile as a free-for-all. Under the GDPR, an email address published on a public page remains personal data, and processing it needs a lawful basis like any other. Publication changes one thing only: it makes legitimate interest easier to argue, because the person chose to make that address reachable.
What it does not change is the rest of the obligations. You still owe transparency, you still owe a route to object, and you still have to keep only what you need. A recruiter who copies an address into a sequencer and forgets where it came from has skipped all three.
The legitimate interest test, in practice
Regulators expect three questions to have been answered before you rely on legitimate interest, and they are not hard to answer for recruiting:
- Is the interest real? Filling an open role is a recognised business interest. A speculative list built with no role attached is much weaker.
- Is the processing necessary? One message to a person whose public work matches the role is necessary. Enriching them with a home address, a phone number bought from a data broker, or a personal social graph is not.
- Does it override their interests? A developer who publishes an email on a professional profile expects professional contact. The same person does not expect five follow-ups, or to appear in a database they cannot see or leave.
The balancing test is where most sourcing programmes actually fail, and it fails on volume, not on the initial search.
What GitHub's terms allow
GitHub's Acceptable Use Policies are explicit on two points that matter here. Information served publicly may be read, including through the API, which is the supported route and the one that respects rate limits. And that information may not be used to send unsolicited bulk email, spam, or to compile it for sale.
The distinction the policy draws is between reading public data, which is allowed, and turning public addresses into a mailing list, which is not. A tool that gives you a handful of matching people for a real role sits on one side of that line. A tool that hands you fifty thousand addresses to import into a sequencer sits on the other, whatever it calls itself.
What you owe the person in the first message
Four elements, none of which cost you anything in response rate, and which together answer almost every complaint a sourcer receives:
- Your name, your company, and the role. Not a persona, not a no-reply address.
- Where the address came from, in plain words: their public GitHub profile.
- A reason specific to them, which also happens to be the only thing that makes the message worth sending.
- A way out that works on the first click, and a privacy notice they can open.
The Article 14 notice is the part teams forget. It does not need to be in the body of the email; a link is enough, as long as it leads to something that says what you hold, why, and how to have it removed.
How StarHunt handles it
Everything in the index comes from GitHub's public API: profile, public repositories, languages, and the email or blog a developer chose to publish on their own profile. Nothing is bought from a broker, nothing is guessed from a name-and-company pattern, and no private address is inferred.
Every profile page carries the origin of each field, so a recruiter can say where a datum came from without guessing. And any developer can have their profile removed from the index from a public page, without an account and without writing to support: the removal page. That route exists because a right to object that requires a support ticket is not a right to object.
Where this answer does not hold
Some jurisdictions are stricter than the general picture above. Germany applies specific employee-data rules, France's CNIL has published its own guidance on recruitment data retention, and several countries outside the EU have their own regimes. Sector matters too: a public body or a regulated employer may have internal rules tighter than the law. This page describes how recruiting teams generally handle these rules. It is not legal advice, it is not written by a lawyer, and it does not account for your country, your sector or your contracts. Have your own counsel confirm anything you intend to rely on.
Frequently asked questions
Do I need consent before emailing a developer about a job?
Generally no, in the EU. Recruitment outreach to a professional address the person published is normally done under legitimate interest rather than consent. Consent would be a poor basis anyway: it must be freely given and withdrawable, which is a difficult standard for a cold first contact.
Do I have to tell them where I got their address?
Yes, and it is also the cheapest way to defuse the reaction. Because the data was not collected from the person, GDPR Article 14 requires you to inform them, including the source. One sentence saying the address came from their public GitHub profile, plus a link to your privacy notice, covers it.
Can a developer ask to be removed from a sourcing database?
Yes. The right to object under Article 21 applies directly to processing based on legitimate interest, and for direct marketing purposes it is absolute. In practice you need a route that works without an account and without a support ticket.
Is scraping GitHub profiles allowed?
Reading public information is allowed, including through the API, which is the supported route. What GitHub's Acceptable Use Policies prohibit is using that information to send unsolicited bulk email or compiling it for sale. The API also gives you rate limits that keep you on the right side of the abuse rules.
Source from public GitHub data, without the grey area
Public API only, the origin of every field visible, and a removal page any developer can use without an account.
Try StarHunt for freeThis page describes how recruiting teams generally handle these rules. It is not legal advice, it is not written by a lawyer, and it does not account for your country, your sector or your contracts. Have your own counsel confirm anything you intend to rely on.