When the U.S. Federal Communications Commission (FCC) published its repeal of net neutrality regulations in the Federal Register on February 22, the U.S. Congress had 60 legislative days to disapprove of the FCC order. Approximately half of that time is up. To learn more about how this timeline works—and why the pressure is on—check out the following resources:
On May 2, small businesses will deliver a letter to Congress, urging disapproval of the FCC order. The first week of May is Small Business Week, and Congresspeople take business owners from their districts very seriously. If you represent a small business in the U.S., sign the letter.
Meanwhile, at least 33 U.S. states and many cities have enacted or have pending actions to protect net neutrality. California is considering passing S.B. 822, the strongest and most comprehensive set of net neutrality protections in the country. GitHub joined almost 60 startups in a letter of support for this bill, which has its second committee hearing tomorrow. If you’re in California, tell state legislators to protect net neutrality by supporting S.B. 822.
Not in the U.S.? Help spread the word about the fight for net neutrality, or learn more about and get involved in the most pressing open internet issues in your country.
We’re in the process of updating our policies, and we’d like to get your input! We want to hear what you think of them and whether any of our changes or clarifications can be improved. Head on over to our Site Policy repository to see the open pull requests.
About every six months, we review our terms and policies to make sure they’re as clear as they can be and decide whether we should make any updates. This time around, we’re very focused on bringing our policies into alignment with a new law in Europe known as the General Data Protection Regulation, so we’ve made some changes to our Privacy Statement and Terms of Service to cover our compliance with that law. We’ve made other changes to our terms to clarify account control and developer obligations when integrations are created for others.
Over the last few months, we’ve gotten a few questions asking about our General Data Protection Regulation (GDPR) compliance. We are proud to announce that we are compliant with the GDPR. Additionally, we have always provided the same level of privacy protection to our users regardless of their residency, location, or citizenship—and that will not change. We provide strong privacy and security protection to all of our users.
For the most part, our changes to the Privacy Statement are only points of clarification. GitHub doesn’t ask for more personal data from our users than we need to provide our services to you. Where we offer you the option of giving us more data, we provide you the ability to access and delete the data you have given us. For example, you can always remove your profile information, your comments in issues, and your repository contents. We have gone through our Privacy Statement to provide more context and transparency, though, so our users understand exactly why we ask for information and what we’ll do with it.
Much like the changes to the Privacy Statement, most of the changes to our terms are clarifications of pre-existing sections. Here are a few sections we’d like to highlight:
We’ll leave the pull requests open until 5 pm Friday, May 18. Then, we’ll take a week to go through your comments and make changes to improve the policies. We’ll enact the new policies on Friday, May 25.
We look forward to hearing from you!
Today we’re joining a collective of companies across the technology supply chain in committing to a common set of cybersecurity principles. We are pledging to:
We’re committed to working collaboratively with engineers, researchers, policy makers, and others who play a role in cybersecurity to make the internet a more secure and resilient global resource. Protecting the internet is becoming more urgent every day as more fundamental vulnerabilities in infrastructure are discovered—and in some cases used by government organizations for cyberattacks that threaten to make the internet a theater of war. Reaching industry-wide agreement on security principles and collaborating with global technology companies is a crucial step toward securing our future.
We believe security needs to be embedded into software development, and we’re building features to make that a reality. For years, we’ve participated in bug bounties to find and fix problems with existing infrastructure. And this is just the beginning. We’ll continue advocating against policies that will make software more fragile and for policies that promote stronger internet security.
We’re all in this together. We welcome other companies who share our commitment to the Cybersecurity Tech Accord principles to join this effort, and we encourage governments to protect civilians from the harm of cyberattacks.
Since 2014, we’ve posted transparency reports so everyone can see what keeps us busy on GitHub’s Legal and Support Teams. We hope you enjoy this year’s!
Similar to years past, we have continued to receive two main types of legal requests:
Due to the nature of many of the disclosure requests, such as national security orders, we are prevented from sharing a lot of data about them. However, we can tell you quite a bit about takedowns. For instance, you can see exactly what we’re asked to take down because we publish all DMCA notices and government takedown requests that we process at the time we process them. That allows our users and the public to see why content is being removed.
For DMCA takedown notices, you can also see how many counter notices we process. The number of DMCA notices we’ve received and processed has risen dramatically in the past few years. We went from 258 takedown notices processed in 2014 to 505 in 2015 and 757 in 2016. Though the number of counter notices processed increased from 17 to 62 in the first two years, that number actually decreased to 20 in 2016. We thought that was interesting and wanted to highlight it for everyone. Below, we’ll get into a little more detail about DMCA notices and other requests we receive.
As you may have noticed in our guidelines for legal requests of user data, we require a subpoena for certain kinds of user information, like a name, an email address, or an IP address associated with an account, and a court order or warrant for all other kinds of user information, like user access logs or the contents of a private repository. A subpoena is a legal process that does not require review by a judge or magistrate. By contrast, a warrant or court order does require judicial review. These requests may be part of a criminal investigation or a civil dispute and may come from law enforcement, a government agency, or litigants in a civil trial.
Because some legal processes are part of ongoing criminal investigations, we may receive, along with them, a court order that forbids us from giving notice to the targeted account holder. Even when we do not receive that kind of order, there are often significant privacy concerns involved with these disputes. Therefore, we do not publish subpoenas or other legal requests for user information.
In 2016, we received 34 requests for user data. Unlike in years past, we received both warrants and court orders in 2016. These 34 requests include every request we received for user data, regardless of whether we disclosed information or not. Not all of these came from law enforcement; some of these may have come from other government agencies, from civil litigants wanting information about another party, or from foreign government agencies through the Department of Justice via a mutual legal assistance treaty or similar form of cooperation. Twenty-six of these requests for user data came from federal grand jury subpoenas that can be seen below. The chart below shows the breakdown by percentage of the different types and sources of requests we received.
In 2016, we noticed a significant increase in requests for user data from 2015, when we received 12 requests.
In addition, we have seen an increase in the number of non-disclosure orders (also known as gag orders) attached to these requests that prevent us from notifying our users about them, almost quadrupling from seven to 27 in 2016. The chart below shows the total number of gag orders received in 2014, 2015, and 2016.
We did not disclose user information in response to every request we received. In some cases, this is because the request was not specific enough, and when we asked for clarification, the requesting party withdrew the request. In some cases, we received very broad requests, and we were able to limit the scope of the information we provided.
We are very limited in what we can say about national security letters and Foreign Intelligence Surveillance Act (FISA) orders. The US Department of Justice has issued guidelines that only allow us to report information about these types of requests in ranges of 250, starting with zero. The chart below shows the relevant ranges for national security orders received and affected accounts.
Although fairly limited, GitHub continued to see requests from foreign governments to block content. When we receive requests like this, we provide transparency in at least two ways: we notify the affected account holder before removing the content, and we post the notice publicly, to our government takedowns repository. In 2016, we received five takedown requests from Russia and one takedown request from China.
The most significant number of requests we receive for content removal are notices submitted under the Digital Millennium Copyright Act, or the DMCA. The DMCA provides a method by which copyright holders may request GitHub to take down content they believe is infringing. The user who posted the content can then send a counter notice to dispute the claim. Each time we receive a complete DMCA takedown notice, we redact any personal information and post it to a public DMCA repository. To learn more about our DMCA process, please take a look at our DMCA Takedown Policy.
In 2016, we received a significant increase in takedown notices, but took down less content than we did in 2015. This is likely because of an anomalous singular notice which resulted in 5,564 projects being removed in 2015.
Below are the total number of complete notices that we received and processed in 2016. 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. To learn more about the differences between takedown notices, counter notices, and notices of legal action filed, please check out our DMCA Takedown Policy.
In 2016, we processed something new called a “reversal.” A “reversal” occurs when we become aware of new information, following a DMCA notice, that shows the original DMCA was invalid at the time of submission. The result of a reversal is the restoration of any content that was disabled as a result of the faulty DMCA notice.
By month, the notices, counter notices, retractions, and reversals we processed look like this:
From time to time, we do receive 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.
Often, a single takedown notice can encompass more than one project. So, we looked at the total number of projects, such as repositories, Gists, and Pages sites, that we had taken down due to DMCA takedown requests in 2016. By month, the projects we took down, and the projects that remained down after we processed retractions and counter notices, looked like this:
In contrast with 2015, there were no large spikes of projects taken down in 2016.
With the benefit of having tabulated DMCA data for the past few years, we can now look at the trend. As might be expected, the volume of notices received by GitHub has been increasing. Of course, the GitHub community has also been growing. When we overlay the number of DMCA notices with the approximate number of registered users over the same period of time, we can see that the growth in DMCA notices is commensurate with the growth of the community.
Please note, the number of registered users noted above has been approximated to the nearest million registered users at the end of each calendar year.
We want to be as transparent as possible to help you understand how legal requests may affect your projects. We hope that each year we put out a transparency report, we’ll be able to improve it with more thorough analysis and more insight into our processes, so if there’s anything you’d like to see us include in the next year’s report, please let us know.
$ git push ... remote: Resolving deltas: 100% (2/2), completed with 2 local objects. remote: error: GH013: Your push could infringe someone's copyright. remote: If you believe this is a false positive (e.g., it's yours, open remote: source, not copyrightable, subject to exceptions) contact us: remote: https://github.com/contact remote: We're sorry for interrupting your work, but automated copyright remote: filters are mandated by the EU's Article 13. To github.com/vollmera/atom.git ! [remote rejected] patch-1 -> patch-1 (push declined due to article 13 filters)
The EU is considering a copyright proposal that would require code-sharing platforms to monitor all content that users upload for potential copyright infringement (see the EU Commission’s proposed Article 13 of the Copyright Directive). The proposal is aimed at music and videos on streaming platforms, based on a theory of a “value gap” between the profits those platforms make from uploaded works and what copyright holders of some uploaded works receive. However, the way it’s written captures many other types of content, including code.
We’d like to make sure developers in the EU who understand that automated filtering of code would make software less reliable and more expensive—and can explain this to EU policymakers—participate in the conversation.
Upload filters (“censorship machines”) are one of the most controversial elements of the copyright proposal, raising a number of concerns, including:
Upload filters are especially concerning for software developers given that:
The EU Parliament continues to introduce new proposals for Article 13 but these issues remain. MEP Julia Reda explains further in a recent proposal from Parliament.
As part of our ongoing collaboration with others affected, GitHub will help represent developers at an upcoming breakfast in Parliament on Tuesday, March 20, intended to show the human impact of this copyright proposal.
EU policymakers have told us it would be very useful to hear directly from more developers. In particular, developers at European companies can make a significant impact.
Write to EU policymakers (MEPs, Council Members, or Commissioners) and ask them to exclude “software repositories” from Article 13. Please explain how important the ability to freely share code is for software developers and how important open source software is to the software industry and the EU economy
Explain this :point_up: in person to EU policymakers
GitHub can help connect you with policymakers, provide additional background, or chat if you might be interested in representing software developers in defending your ability to share code and not have your builds break. Get in touch!