Both the EU Council and EU Parliament heard developers who responded to our call to action on the EU’s proposal to require copyright filters for uploaded content. Upload filters raise a number of efficacy, speech, and privacy concerns for software developers and the public. Although upload filters remain an unsettled part of the debate, EU policymakers are making more concerted attempts to narrow the scope of who filters would apply to.
In their latest proposals, Council and Parliament each exclude “non-for-profit open source software developing platforms.” Despite their intentions, neither the Council nor Parliament has yet to effectively protect open source software development because most open source software development is built on platforms, like GitHub, that aren’t not-for-profit.
DIGITALEUROPE, an organization representing the digital technology industry in Europe, emphasized this point in its recent letter to the EU Council:
The scope of Article 13 remains far too broad and out of proportion with its stated goals. We are not aware of any calls to address a value gap in relation, for example, to open source software repositories, yet such services are only excluded if they operate on a non-profit basis (which is not the case for many such service providers).
On Friday, the Council considered adopting its current version of the copyright proposal, but was unable to reach agreement. Two of the main sticking points were Article 11 and Article 3, each of which could affect developers.
Article 11 would create a new right for press publishers, sometimes referred to as “ancillary copyright,” and would enable them to require a license to post the snippets of text that describe links. Requiring this kind of permission would add overhead to anyone developing software for the web. It also would run counter to exceptions to copyright that allow copying for certain limited purposes, such as to comment on a copyrighted work.
Article 3 proposes a copyright exception for text and data mining in the EU, but only by research organizations for scientific purposes on a not-for-profit basis. Text and data mining is critical to AI and machine learning, and in the US is considered fair use. Article 3’s narrow exception would undermine the future of software development in the EU, including the EU’s own efforts to promote AI.
These articles (upload filters, ancillary copyright, and text and data mining) remain the most controversial parts of the Copyright Directive and each potentially affects developers. Discussions continue in Council, which hopes to agree on a proposal soon, and in Parliament, which currently plans to vote on its version of the proposal in late June.
There is still time to help policymakers effectively protect software development in the EU and it’s still important for those policymakers to hear from developers directly. Write to us to find out ways to engage with EU policymakers to protect software development!
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.