February 25, 2021: We’ve updated this post to reflect final numbers for 2019 that were processed after the initial publication.
At GitHub, we believe that maintaining transparency is an essential part of our commitment to our users, as is our practice of promoting free expression by restricting content removal as narrowly as possible. For the past five years 2018, 2017, 2016, 2015, 2014, we’ve published transparency reports to better inform the public about GitHub’s disclosure of user information and removal of content.
As of October 2019, 70 companies worldwide have released a transparency report. At the same time, many companies are phasing out transparency reporting, particularly about government requests for user information.
Yet we are continuing to see increasing interest in content moderation, especially when and why companies remove information from their platforms. As we explained last year, content moderation can raise free expression concerns regardless of whether it starts with a government or with a user. Being transparent about content removal policies, and restricting content removal as narrowly as possible, are among the United Nations free speech expert’s recommendations to platforms for promoting free expression in content moderation online. At GitHub, we do both.
More specifically, we promote transparency by:
- Directly engaging our users in developing our policies
- Explaining our reasons for making policy decisions
- Notifying users when we need to restrict content, with our reasons
- Allowing users to appeal removal of their content
- Publicly posting takedown requests (requests to remove content) in real time in a public repository
To restrict content as narrowly as possible, we provide users an opportunity to remove specific content, when possible, rather than blocking entire repositories, and we remove content only in the jurisdiction where it’s shown to be illegal, rather than worldwide.
Check out our contribution to the UN expert’s report for more details.
Year in review
In this year’s Transparency Report, we’ll review 2019 stats for:
- Requests to disclose user information
- Subpoenas
- Court orders
- Search warrants
- National security letters and orders
- Cross-border data requests
- Government requests to remove or block user content
- Under a local law
- Under our Terms of Service
- Notices to take down allegedly copyright-infringing content
- Takedown notices under the U.S. Digital Millennium Copyright Act (DMCA)
- Court-ordered copyright takedowns
Not all companies report on the same kinds of information in their transparency reports. Why do we focus on these three categories? The first two cover the requests we receive from governments—whether that’s for information about our users or to take down content posted by our users. The third, which we often refer to as DMCA takedowns, is particularly relevant to GitHub because so much of our users’ content is software code, which can, in some cases, be subject to copyright. That said, only a tiny fraction of that content is the subject of a DMCA notice (roughly one in ten thousand).
Read on for the details. And before you dive in—if you’re unfamiliar with any of the GitHub terminology we use in this report, refer to the GitHub Glossary.
Requests
GitHub’s Guidelines for Legal Requests of User Data explain how we handle legally authorized requests, including law enforcement requests, subpoenas, court orders, and search warrants, as well as national security letters and orders.
Legally authorized requests of user data don’t always require review by a judge or a magistrate. Subpoenas—written orders to compel someone to testify on a particular subject—and national security letters don’t require judicial review, and they’re limited in what they can be used to obtain. This means that while a national security letter is similar to a subpoena, it can only be used for matters of national security.
By contrast, search warrants and court orders both require judicial review. A national security order is a type of court order that can be put in place, for example, to produce information or authorize surveillance. National security orders are issued by the Foreign Intelligence Surveillance Court, a specialized U.S. court for national security matters.
As we note in our guidelines:
- We only release information to third parties when the appropriate legal requirements have been satisfied, or where we believe it’s necessary to comply with our legal requirements or to prevent an emergency involving danger of death or serious physical injury to a person.
- We require a subpoena to disclose certain kinds of user information, like a name, an email address, or an IP address associated with an account, unless we determine that disclosure (as limited as possible) is necessary to prevent an emergency involving danger of death or serious physical injury to a person.
- We require a court order or search warrant for all other kinds of user information, like user access logs or the contents of a private repository.
- We notify affected users about any requests for their account information unless prohibited from doing so by law or court order.
In 2019, GitHub processed 261 requests to disclose user information—more than three times as many as we did in 2018. Of those 261 requests, we processed 114 subpoenas (106 criminal and 8 civil), 102 court orders, and 37 search warrants. The increases in both court orders and search warrants were disproportionately higher this year—each roughly four times the number we received last year. These requests also include eight cross-border data requests, which we’ll share more about later in this report. These numbers represent every request we processed for user information, regardless of whether we disclosed information or not. We’ll cover more information about disclosure and notification in the next sections.
The vast majority (96.9 percent) of these requests came from law enforcement. Only about 3.1 percent were civil requests, all of which came from civil litigants wanting information about another party (unlike 2018, when we also received civil requests from government agencies).
![Pie chart showing the different types of legal requests for user information processed: criminal subpoena (40.6 percent), criminal court order (39.1 percent), criminal search warrant (14.2 percent), civil litigation (3.1 percent), and cross-border requests (3.1 percent).](https://github.blog/wp-content/uploads/2020/02/2019-transparency-report-fig-1-update.png?w=512&resize=512%2C381)
Disclosure and notification
We didn’t disclose user information in response to every request we received. In some cases, the request was not specific enough and the requesting party withdrew the request after we asked for clarification. In other cases, we received very broad requests and we were able to limit the scope of the information we provided. We processed 261 requests in 2019 and disclosed information 189 times. Those disclosures affected 557 accounts. If all of the requests we received had met the criteria for processing, 1,252 accounts would be potentially affected. Of those requests, four related to over 100 accounts each.
Requests that affect a large number of users typically occur when a court order seeks information about access to a piece of content posted on GitHub, rather than targeting specific users. In these cases, GitHub shares log data, including usernames and IP addresses, in connection with access to the content during a specific timeframe. But GitHub does not typically share further private information, like email addresses, about every user that accessed the content without receiving a specific request.
![Table showing the number of total requests for disclosure of user information processed (261), accounts affected (557), total requests where information was disclosed (189), and percentage of requests for information was disclosed (72.4 percent).](https://github.blog/wp-content/uploads/2020/02/2019-transparency-report-fig-2-update.png?w=1024&resize=1024%2C440)
We notify users when we disclose their information in response to a legal request unless a law or court order prevents us from doing so. In many cases, legal requests are accompanied by a court order that prevents us from notifying users, commonly referred to as a gag order.
Of the 189 times we produced information in 2019, we were only able to notify users seven times because gag orders accompanied the other 182 requests.
![Combined bar graph of user notifications of legal request disclosures broken out by notification sent and no notification (gag order) and line graph showing percentage notified.](https://github.blog/wp-content/uploads/2020/02/2019-transparency-report-fig-3-update.png?w=1024&resize=1024%2C770)
While the number of requests with gag orders continues to be a rising trend as a percentage of overall requests, it correlates with the number of criminal requests we processed. Due to the nature of criminal investigations, legal requests in criminal matters often come with a gag order, since notification would often interfere with the investigation. On the other hand, civil matters are typically public record, and the target of the legal process is often a party to the litigation, obviating the need for any secrecy. None of the civil requests we processed this year came with a gag order, which means we notified each of the affected users.
When you consider that only 3.1 percent of the requests we processed in 2019 were civil (as opposed to criminal), the fact that we were only able to notify users 3.7 percent of the time this year is not surprising. Our data from the past years also reflects this trend of notification percentages correlating with the percentage of civil requests:
- 9.1 percent notified and 11.6 percent civil requests in 2018
- 18.6 percent notified and 23.5 percent civil requests in 2017
- 20.6 percent notified and 8.8 percent civil requests in 2016
- 41.7 percent notified and 41.7 percent civil requests in 2015
- 40 percent notified and 43 percent civil requests in 2014
National security letters and orders
We’re limited in what we can say about national security letters and Foreign Intelligence Surveillance Act (FISA) orders. The U.S. Department of Justice (DOJ) has issued guidelines that only allow us to report information about these types of requests in ranges of 250, starting with zero. As shown below, we received 0–249 notices in 2019, affecting 0–249 accounts.
![Table of national security letters and orders received (0–249) and affected accounts (0–249).](https://i0.wp.com/user-images.githubusercontent.com/17750691/74859127-4704fe80-52fb-11ea-87ab-a33adc5085c4.png?resize=1686%2C795&ssl=1)
Cross-border data requests
Governments outside the U.S. can make cross-border data requests for user information through the DOJ via a mutual legal assistance treaty (MLAT) or similar form of international legal process. Under the MLAT process, when a foreign government seeks user information from GitHub, we direct the government to the DOJ so that the DOJ can determine whether the request complies with U.S. legal protections.
If it does, the DOJ would send us a subpoena, court order, or search warrant, which we would then process like any other requests we receive from the U.S. government. When we receive these requests from the DOJ, they don’t necessarily come with enough context for us to know whether they’re originating from another country. However, when they do indicate it, we capture that information in our statistics for subpoenas, court orders, and search warrants ☝️. This year, we know that one of those court orders and one of those search warrants we processed had originated as cross-border requests.
In 2019, we received eight requests directly from foreign governments. Those requests came from two countries, Germany and India. This is an increase from 2018, when we received two requests, also from two countries. Consistent with our practice, we referred those governments to the DOJ to use the MLAT process.
Our Guidelines for Legal Requests of User Data explain how we handle user information requests from foreign law enforcement.
Takedowns: requests to remove or block user content
In this section, we describe two main categories of requests we receive to remove or block user content: government takedown requests and DMCA takedown notices. We also describe a new category in our report this year: court-ordered takedowns.
Government takedown
From time to time, GitHub receives requests from governments to remove content that they judge to be unlawful in their local jurisdiction (government takedown requests). When we block content at the request of a government, we post the official request that led to the block in a public government takedowns repository. When we receive a request, we confirm whether:
- 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 we believe the answer is “yes” to all three, we block the content in the narrowest way we see possible. For instance, we would block content only in the jurisdiction(s) where the content is illegal—not everywhere. We then post the notice in our government takedowns repository, creating a public record where people can see that a government asked GitHub to take down content.
In 2019, GitHub processed 16 requests—eight from Russia, six from China, and two from Spain. These takedowns resulted in 54 projects—all or part of 48 repositories, one gist, and five GitHub Pages sites—being blocked in the respective country. While the number of notices remains relatively small, they show an increase from last year, when we received nine requests, all from Russia. In 2019, government takedown notices affected six times the number of projects than they did in 2018.
In addition to requests based on violations of local law, GitHub processed one request from a government (France) to take down content as a Terms of Service violation related to phishing, disabling five projects, in 2019.
DMCA takedowns
Most content removal requests we receive are submitted under the DMCA, which allows copyright holders to ask GitHub to take down content they believe infringes on their copyright. The user who posted the “infringing” content can then send a counter notice asking GitHub to reinstate the content if they believe the takedown was a mistake or misidentification. Each time we receive a complete DMCA takedown notice, we redact any personal information and post that notice to a public DMCA repository.
Our DMCA Takedown Policy explains more about the DMCA process, as well as the differences between takedown notices and counter notices. It also sets out the requirements for making a complete request, which include that the person submitting the notice take into account fair use.
Takedown notices received and processed
In 2019, GitHub received and processed 1,762 complete DMCA takedown notices and 37 complete counter notices or retractions, for a total of 1,799 notices. In the case of takedown notices, this is the number of separate notices where we took down content or asked our users to remove content. This year, we did not receive any notices of legal action filed related to a DMCA takedown request.
![Table of DMCA notice totals by number of takedown notices (1,762), counter notices or retractions (37), and notices of legal actions filed (0).](https://i0.wp.com/user-images.githubusercontent.com/17750691/74859126-466c6800-52fb-11ea-9df6-b25eb43e7867.png?resize=1686%2C795&ssl=1)
While content can be taken down, it can also be restored. In some cases, we reinstate content that was taken down if we receive either of the following:
- Counter notice: the person whose content was removed sends us sufficient information to allege that the takedown was the result of a mistake or misidentification
- Retraction: the person who filed the takedown changes their mind and requests to withdraw it
For most months, the totals ranged from 120 to 185 takedown notices. The exception was December when we received only 104. The monthly totals for counter notices and retractions combined ranged from zero to nine, correlating more or less with the volume of takedown notices those months.
![Bar graph of DMCA notice totals by month comparing takedown notices processed to counter notices and retractions processed.](https://i0.wp.com/user-images.githubusercontent.com/17750691/74859124-466c6800-52fb-11ea-8b08-12d74ed9c3cf.png?resize=1686%2C1268&ssl=1)
Incomplete DMCA takedown notices received
All of those numbers were about complete notices we received. We also received a lot of incomplete or insufficient notices regarding copyright infringement. Because these notices don’t result in us taking down content, we don’t currently keep track of how many incomplete notices we receive, or how often our users are able to work out their issues without sending a takedown notice.
Projects affected by DMCA takedown requests
Often, a single takedown notice can encompass more than one project. For these instances, we looked at the total number of projects, including repositories, gists, and GitHub Pages sites, that we had taken down due to DMCA takedown requests in 2019.
The monthly totals for projects reinstated (based on a counter notice or retraction) ranged from zero to nine. The number of counter notices and retractions we receive amounts to only two to four percent of the DMCA-related notices we get each month. This means that most of the time when we receive a complete takedown notice, the content comes down and stays down. In total in 2019, we took down 14,366 projects and reinstated 46, which means that 14,320 projects stayed down.
14,320 may sound like a lot of projects, but it’s only about one one-hundredth of a percent of the repositories on GitHub at the end of 2019.
![Bar graph of DMCA projects taken down and remaining down (by month) comparing projects taken down and projects remaining down.](https://i0.wp.com/user-images.githubusercontent.com/17750691/74859129-479d9500-52fb-11ea-89f0-6b78e8b8e170.png?resize=1687%2C1268&ssl=1)
Trends
Based on DMCA data we’ve compiled over the last few years, we’ve seen an increase in DMCA notices received and processed, trending with growth in registered users over the same period of time, until this year. However, if we compare the number of repositories affected by DMCA notices to the approximate number of registered users over the same period of time, then we see an increase this year that correlates with that of GitHub’s community.
![Combined bar and line graph showing an increase when comparing number of repos affected by DMCA takedowns to number of users and an increase in DMCA takedown notices until this year when comparing number of takedown notices to number of users.](https://i0.wp.com/user-images.githubusercontent.com/17750691/74859128-4704fe80-52fb-11ea-802a-70f1b67fbbed.png?resize=1686%2C1268&ssl=1)
Court-ordered takedowns
A new category this year is court-ordered takedowns. We received one this year and interestingly, it was about copyright but not under the DMCA. Since it was a gagged court order, we weren’t able to provide our usual transparency to the user of sharing and posting the notice, but we are able to report on the fact that we processed a takedown on this basis.
Conclusion
While some companies are phasing out transparency reporting, GitHub remains committed to maintaining transparency and promoting free expression as an essential part of our commitment to our users. A key example of this is ensuring we minimize the amount of data we disclose or the amount of content we take down as much as legally possible. Through our transparency reports, we’re continuing to shed light on our own practices, while also hoping to contribute to broader discourse on platform governance.
We hope you found this year’s report to be helpful and encourage you to let us know if you have suggestions for additions to future reports. For more on how we develop GitHub’s policies and procedures, check out our site policy repository.
Written by
I'm GitHub's Director of Platform Policy and Counsel, building and guiding implementation of GitHub’s approach to content moderation. My work focuses on developing GitHub’s policy positions, providing legal support on content policy development and enforcement, and engaging with policymakers to support policy outcomes that empower developers and shape the future of software.