Half-year reporting for tighter transparency

GitHub has published transparency reports since 2014, but this edition marks a shift to a six-month cadence instead of annual reporting. Moving to twice-yearly reporting gives the developer community more timely insight into content moderation and disclosure of user information. To preserve year-over-year comparisons, the 2020 statistics in this report have been split into January-to-June and July-to-December halves.

The report covers four areas: requests to disclose user information, government requests to remove or block content, DMCA takedown notices, and appeals of account or content restrictions. The DMCA category is especially relevant to GitHub, whose users host large amounts of software code that may qualify for copyright protection; still, fewer than four in 100,000 repositories are the subject of a DMCA notice.

Disclosure requests: process and volume

GitHub handles legally authorized requests for user data under its Guidelines for Legal Requests of User Data. The type of legal authorization determines both what information GitHub will release and what process is required:

  • A subpoena is sufficient to disclose basic account information such as a name, email address, or IP address. Subpoenas don't require judicial review, and neither do national security letters.
  • A court order or search warrant, both of which require judicial review, is necessary for all other user information, including access logs and private repository contents. National security orders are court orders issued by the Foreign Intelligence Surveillance Court.

GitHub notifies affected users of any request for their information unless prohibited by law or court order. In exigent circumstances involving danger of death or serious physical injury, GitHub may disclose limited information without a subpoena.

During January to June 2021, GitHub received 172 requests to disclose user information, matching the 172 requests in the first half of 2020 and exceeding the 131 requests in the second half of 2020. The breakdown:

  • 102 subpoenas (96 criminal, six civil)
  • 47 court orders
  • 13 search warrants
  • 3 requests based on exigent circumstances (kidnapping, child exploitation, and a bomb threat)

These numbers include seven cross-border data requests. The large majority of requests (96.4%) came from law enforcement; the remaining 3.49% came from civil litigants. The totals count every request received, regardless of whether information was disclosed, with one exception: GitHub is prohibited from stating whether it received any national security letters or orders.

Pie chart showing the different types of legal requests for user information processed: criminal subpoena (55.8%), criminal court order (27.3%), criminal search warrant (7.56%), cross-border request (4.07%), civil subpoena (3.49%), and exigent circumstances (1.74%).

How we handle disclosure requests

Every request to disclose user data is vetted against our policies and applicable legal requirements. We don't comply with every request we receive: some are too broad or lack specificity, and we push back or negotiate narrower scopes where appropriate. When we do comply, we never share private content data—such as content in private repositories—except in response to a search warrant. All other requests yield only non-content data: basic account information like usernames and email addresses, metadata about account usage or permissions, and log data regarding activity or access history.

Of the 172 requests we processed from January to June 2021, we disclosed information in 140 cases: 94 subpoenas (89 criminal and 5 civil), 30 court orders, 13 search warrants, and three under exigent circumstances.

Pie chart showing the user information disclosed by different types of legal requests: criminal subpoena (63.6%), criminal court order (21.4%), criminal search warrant (9.29%), and civil subpoena (3.57%), and exigent circumstances (2.14%)

Those 140 disclosures affected 871 accounts.

Table showing the number of total requests for disclosure of user information processed (173), accounts affected (871), total requests where information was disclosed (140), and percentage of requests where information was disclosed (81.40%).

Notification and gag orders

We notify affected users whenever we disclose information in response to a legal request, unless a law or court order prohibits it. In practice, gag orders accompany many legal requests—particularly in criminal matters—and we may delay notification under exigent circumstances to prevent death or serious harm or due to an ongoing investigation.

Only five of the 140 disclosures in the first half of 2021 allowed us to notify users; the remaining 135 were either under gag order or received under exigent circumstances. That's a slight improvement from the same period in 2020, when we notified users six times out of 103 disclosures (January to June) and seven times out of 91 (July to December).

Combined bar chart of user notifications of legal request disclosures broken out by exigent circumstances, notification sent and gag order (no notification sent) over time. For H1 (January to June) 2021, the chart shows 3 exigent circumstances, six notifications, and 132 gag orders.

Combined bar chart of user notifications of legal request disclosures broken out by exigent circumstances, notification sent and gag order (no notification sent) in six-month periods: H1 2020 (six notifications, and 97 gag orders), H2 2020 (seven notifications, and 84 gag orders), and H1 2021(3 exigent circumstances, six notifications, and 132 gag orders).

The rising share of requests with gag orders tracks closely with the volume of criminal requests we process. Criminal matters routinely come with secrecy requirements—law enforcement often asserts that notification would interfere with an investigation—and exigent circumstances carry the same constraint. Civil matters are different: they're typically public record, and the affected user is often a party to the litigation, so secrecy isn't necessary. None of the civil requests we processed this period came with a gag order; we notified every affected user.

From January to June 2021, civil requests made up 3.6% of all requests we processed, matching the 3.6% of disclosures where we could notify users. We've seen this correlation in prior years as well:

  • 6.8% notified and 6.9% civil requests in 2020
  • 3.7% notified and 3.1% civil requests in 2019
  • 9.1% notified and 11.6% civil requests in 2018
  • 18.6% notified and 23.5% civil requests in 2017
  • 20.6% notified and 8.8% civil requests in 2016
  • 41.7% notified and 41.7% civil requests in 2015
  • 40% notified and 43% civil requests in 2014

National security requests

Legal restrictions tightly limit what we can say about national security letters and Foreign Intelligence Surveillance Act (FISA) orders. Under Department of Justice guidelines, we may only report these in ranges of 250, beginning at zero. For January to June 2021, we received 0–249 such notices, affecting 0–249 accounts.

Table of national security and orders received (0-249) and affected accounts (0-249).

Cross-border requests

Foreign governments seeking user data must route their requests through the DOJ via a mutual legal assistance treaty (MLAT) or similar international process. When a foreign government approaches us directly, we direct it to the DOJ, which determines whether the request meets US legal protections. If it does, the DOJ sends us a subpoena, court order, or search warrant, which we process like any other US government request. These forwarded requests don't always indicate their country of origin, but when they do, we record it.

Between January and June 2021, we received seven requests directly from foreign governments—from Brazil, Germany, India, and Japan—and referred each to the DOJ for the MLAT process.

Government takedown requests

Governments occasionally ask GitHub to remove content they consider unlawful in their jurisdiction. When we act on such requests, we confine the block to the jurisdictions where the content is illegal whenever possible, and we post the official request in our public government takedowns repository to maintain a transparent record.

Before honoring a government takedown request, we verify three things:

  • The request came from an official government agency
  • An official sent an actual notice identifying the content
  • An official specified the source of illegality in that country

If all three hold, we block the content as narrowly as possible—typically by geoblocking only in the relevant jurisdiction.

From January to June 2021, we processed four government takedown requests based on local laws: two from Russia and two from China. These resulted in 39 projects (two gists and 37 repositories) being blocked in those countries. By comparison, we processed 21 such requests in the first half of 2020 and 23 in the second half, all from Russia—so the first half of 2021 saw significantly fewer local-law takedowns.

We also processed four government requests citing Terms of Service violations, affecting four accounts and 13 projects. These concerned phishing (US), malware (US), and copyright under our DMCA takedown policy (China).

DMCA takedowns and counter notices

Most content removal requests arrive under the DMCA, which lets copyright holders ask us to take down content they believe infringes. Our DMCA Takedown Policy is designed with developers in mind, and we have safeguards to minimize unnecessary disruption. If a takedown notice identifies only part of a repository as infringing, or claims circumvention of a technical protection measure, we give the user a chance to address the specific claims before disabling anything. If the user removes or remediates the flagged content, we avoid taking down the project entirely.

For each valid DMCA notice we receive, we redact personal information and any URLs where we couldn't confirm a violation, then post the notice to our public DMCA repository. Our policy explains the requirements for a valid request, including that filers account for fair use.

Counter notices let users contest a takedown when it was a mistake or misidentification. A retraction occurs when the original filer withdraws the request; a reversal occurs when we later learn information invalidates a takedown and we reverse our decision.

Volume statistics

From January to June 2021, we received and processed 980 valid DMCA takedown notices—that's separate notices where we disabled content or asked users to remove it. In addition, we handled 20 valid counter notices, four retractions, one reversal, and one counter notice reversal, for 1,006 total notices in the half. No notices of legal action were filed in connection with any DMCA takedown during this period.

Table of DMCA notice totals by number of takedown notices or counter notice reversal (981), counter notices, retractions, and reversals (25), and notices of legal actions filed (0).

Monthly takedown notices ranged from 118 to 218 during the half. Combined monthly totals for counter notices, retractions, and reversals were between one and eight.

Combined bar chart of DMCA takedown notices processed as compared to retractions, reversals, and counter notices processed by month.

Projects affected and reinstated

A single takedown notice often covers multiple projects—repositories, gists, and GitHub Pages sites. Counting every project, monthly reinstatements—based on counter notice, retraction, or reversal—ranged from negative one to 34. ("Negative one" reflects a counter notice we reversed when it turned out to be invalid.) These reinstatement mechanisms amounted to less than one to nearly two percent of monthly DMCA-related notices, meaning content generally stays down once a valid takedown is processed.

In total for January to June 2021, we took down 7,675 projects and reinstated 53, leaving 7,622 projects down. That number overstates the impact in one respect: it includes projects where a user removed the specifically reported content in response to a notice but the rest of the project remains live. Even counting those, 7,622 accounts for less than four one-thousandths of a percent of repositories on GitHub.

Combined bar chart of projects taken down due to DMCA takedown notices or counter notice reversals processed as compared to projects reinstated due to DMCA counter notices, retractions, or reversals processed by month.

DMCA circumvention claims

Within our DMCA processing, we separately identify takedown notices that allege circumvention of a technical protection measure under Section 1201 of the DMCA. For these notices, GitHub requires additional information before a notice is considered complete and actionable. By searching processed takedown notices for relevant keywords, we estimate that 12 of the 980 notices we handled from January to June 2021, or 1.2%, included a circumvention claim. The proportion has varied in recent years:

  • 63 or 3.0% of all notices in 2020
  • 49 or 2.78% of all notices in 2019
  • 33 or 1.83% of notices in 2018
  • 25 or 1.81% of notices in 2017
  • 36 or 4.74% of notices in 2016
  • 18 or 3.56% of notices in 2015

While circumvention-related notices have increased in absolute terms, they remain a small share of all takedowns, fluctuating between roughly two and five percent over the years. Our current figures come from keyword searches of notices; we have since implemented categorization that will allow for more precise tracking in future reports.

Pie chart breaking out takedown notices received by copyright infringement only (968) and circumvention (12).

The numbers above cover valid notices that resulted in action. GitHub also receives many incomplete or insufficient copyright takedown notices that do not lead to content removal, and we do not currently track how many such notices we receive or how often users resolve disputes without submitting a formal notice.

Looking at DMCA data compiled over several years, notices received and processed increased from 2014 through the end of 2019, closely tracking repository growth over the same period. As a result, the proportion of repositories affected by takedowns stayed relatively consistent. Since January 2020, takedowns have trended downward on average, with the exception of one notable takedown in October 2020 involving youtube-dl, which was later reinstated.

Examining monthly takedown counts shows an average increase of roughly two takedown notices per month, affecting approximately 24 projects per month on average, excluding youtube-dl and one other outlier.

Chart of projects taken down due to DMCA takedown processed by month over time, with regression line showing increase of over 24 takedowns per month.

Chart of DMCA takedown notices processed by month over time, with regression line showing increase of roughly two takedowns per month.

Chart of DMCA takedown notices processed as compared to projects affected over time. H1-2021 saw 7675 projects affected by 981 notices, which clusters closely with previous periods from 2018 through 2019.

Reinstatements and appeals

Reinstatements — including those that follow an appeal — are central to fairness for users and their right to a remedy when content is removed or accounts are restricted. A reinstatement occurs when we reverse an action taken in response to a Terms of Service violation, such as disabling a repository, hiding an account, or suspending a user's access. Sometimes users dispute a decision directly; in other cases, an account or repository is restored after a user removes violating content and commits to future compliance. In this report, reinstatements cover:

  • Abuse: violations of our Acceptable Use Policies, excluding spam and malware
  • Trade controls: violations of trade sanctions restrictions

Our Terms of Service, detailed in the Acceptable Use Policies and Community Guidelines, prohibit content and conduct such as discriminatory material, doxxing, harassment, sexually obscene content, incitement to violence, disinformation, and impersonation. For this report, we exclude spam and malware-related appeals, though those are restricted as well.

When a Terms of Service violation is confirmed, enforcement actions range from disabling a single repository to acting on an entire account. Whenever possible, we take the narrowest action needed to address the violation — for example, disabling one project rather than the whole account. Account-level actions may involve hiding a user's public content while preserving account access, or restricting an account owner's access while keeping shared content available to other users. This latter option is important for a collaborative platform, ensuring that other developers can continue using content they may rely on.

From January to June 2021, we hid 1,785 accounts and reinstated 120 of those. We restricted account owner access for 33 accounts and restored access for 12. In 1,479 cases, we both hid the account and restricted the owner's access; we fully reinstated 18 of these and partially reinstated five (lifting one restriction but not the other). At the project level, we disabled 877 projects for abuse-related violations and reinstated 49. These figures exclude DMCA-related actions and reinstatements, which are covered separately above.

Table showing the number of total restrictions and reinstatements for account hidden (1,785 restricted; 120 reinstated), account access restricted (33; 12), account hidden and access restricted (1,479; 18 and 5 partial), projects taken down (877; 49).

Trade controls compliance

GitHub aims to support as many developers globally as possible, but US sanctions on regions including Crimea, Cuba, Iran, North Korea, and Syria require us to restrict access in those places. We continue to advocate for wider access. For example, we secured a license from the US government to provide full GitHub services to developers in Iran, and we are pursuing similar outcomes for Crimea, Syria, and other sanctioned regions. Services are also generally available to developers in Cuba, with the exception of specially designated nationals, including some government officials.

While trade control laws mandate certain account restrictions, users can appeal, and we work to restore accounts wherever we legally can. Successful appeals often occur after a user returns from temporary travel to a restricted region or when an account was flagged in error. Unlike abuse-related cases, trade control restrictions must always operate at the account level because the law requires us to limit a user's access to GitHub.

Since we began tracking sanctions appeals in July 2019, the volume has shifted. From January to June 2021, we received 591 appeals of trade-control-related restrictions, compared with 1,099 in the same period of 2020 and 1,437 in the second half of 2020. Of those 591 appeals, we approved 531, denied 56, and requested additional information in four cases. We also excluded 29 appeals from users who were not actually subject to trade controls.

Pie chart breaking out trade control appeal outcomes by approved (89.8%), denied (9.48%), and more information requested (0.677%).

Appeals by region varied considerably: 455 from Crimea, 75 from Iran, 57 from Syria, and one from North Korea. Most were approved. Some Iranian appeals arrived before our full-access license was granted, but we ultimately approved all of them. In ten cases, region data was unavailable, and these are marked as “Unknown” in the table and excluded from regional totals in the chart below.

Table showing the outcome of trade control appeals by region. Crimea: 409 approved, 43 denied, 3 other action taken. Iran: 73, 2* (*These users were later unrestricted after GitHub secured a license to provide service to users in Iran.), 0. North Korea: 1, 0, 0. Syria: 47, 10, 0. Unknown: 31, 0, 1.

Looking ahead

GitHub remains committed to transparency and developer freedom in all aspects of content moderation. This report covers a six-month period — January to June 2021 — rather than a full year, and we have shipped tooling improvements that should let us expand coverage to additional areas in the future. Our goal is to minimize both the data we disclose and the content we remove, while continuing to shed light on our practices and contribute to the broader conversation around platform governance.

We welcome your feedback on future reports via [email protected], and you can find more about our policy development process in the site policy repository.