Policy - page 4


The fight progresses as the net neutrality deadline approaches

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:

Meanwhile, the quest to find one more vote to move the process forward in the Senate continues. Write Congress to aid in the search.

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.

Updates to our Privacy Statement and Terms of Service

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.

What’s changed

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.

Updates to our Privacy Statement

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.

GDPR Compliance

  • The GDPR requires us to inform our users about the legal basis on which we process their data. In this update, we explain what data we collect and why
  • We describe our security practices in more detail
  • We now provide a separate page describing our tracking, our use of cookies, and listing our subprocessors (the vendors and third parties we have engaged to process personal data on our behalf)
  • Throughout the Privacy Statement, we provide greater transparency and insight into our data collection, data handling, data retention, and data deletion processes
  • If you are a Corporate Terms of Service customer and you need a Data Protection Agreement with us, please contact support. We will be happy to provide one. Please understand that with the GDPR compliance deadline coming up, our volume of requests is high, but we will respond to you as promptly as possible

Updates to our Terms of Service and other policies

Standard Terms of Service and Corporate Terms of Service

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:

  • Third Party Applications: We combined the Marketplace section with general requirements for those creating integrations for other users to provide better protections for GitHub users and their data. The Marketplace section is now called “Third Party Applications,” since it now applies to more than just GitHub’s Marketplace. We’ve also added a “Third Party Applications” section to the Privacy Statement to discuss our users’ privacy expectations in regards to those applications
  • Access to Private Repositories: In Section E, we clarified the purposes for which we may be required to access private repository contents, in line with the security obligations of our GDPR compliance program
  • More definitions: We included definitions of “User Accounts” and “Organizations” and described who has control of those types of accounts

Other policies

  • Community Forum Code of Conduct: Last year we launched the Community Forum. The Community Forum is a growing part of our platform and we thought it’d be great to include the Code of Conduct in our Site Policy repository, since we hadn’t yet included it
  • Marketplace Developer Agreement: We’ve made some updates to this agreement that reflect some of the changes to the Marketplace over the past year
  • Takedown policies: We’ve updated our takedown policies to add clarification around what’s covered by our DMCA policy
  • Statement Against Modern Slavery and Child Labor: We’ve added our 2018 statement describing the steps we’ve taken to prevent modern slavery and child labor from occurring in our business and supply chain

Taking action

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!

Our Cybersecurity Tech Accord pledge

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:

  1. Protect our users and customers everywhere;
  2. Oppose efforts to attack innocent citizens and enterprises;
  3. Empower users, customers, and developers to strengthen cybersecurity protection; and
  4. Partner with each other and with other like-minded groups to enhance cybersecurity.

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.

Learn more about the Cybersecurity Tech Accord

2016 Transparency Report

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:

  1. Disclosures, requests to disclose user information, which include:
    • Subpoenas, court orders, and search warrants
    • National security orders
  2. Takedowns, requests to remove or block user content, which include:
    • Government takedown requests
    • DMCA takedown notices

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.

Disclosure requests for user data

In general: subpoenas, court orders, and search warrants

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.

Requests received: subpoenas, court orders, and search warrants

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.

Chart - Types of Requests for User Data

In 2016, we noticed a significant increase in requests for user data from 2015, when we received 12 requests.

Gag orders

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.

User Notifications of Legal Requests

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.

Requests Where Information Was Disclosed

National security orders

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.

National Security Orders

Takedown requests

Government takedown requests

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.

DMCA takedown requests

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.

DMCA takedown notices received

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.

DMCA Takedown Totals

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:

DMCA Takedown Totals by Month

Incomplete DMCA takedown notices received

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.

Projects affected by DMCA takedown requests

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:

DMCA Projects Taken Down and Remaining Down by Month

In contrast with 2015, there were no large spikes of projects taken down in 2016.

Increasing volume

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.

Increase in DMCA Takedown Notices

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.

Conclusion

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.

EU wants to require platforms to filter uploaded content (including code)

$ 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.

Why you should care about upload filters

Upload filters (“censorship machines”) are one of the most controversial elements of the copyright proposal, raising a number of concerns, including:

  • Privacy: Upload filters are a form of surveillance, effectively a “general monitoring obligation” prohibited by EU law
  • Free speech: Requiring platforms to monitor content contradicts intermediary liability protections in EU law and creates incentives to remove content
  • Ineffectiveness: Content detection tools are flawed (generate false positives, don’t fit all kinds of content) and overly burdensome, especially for small and medium-sized businesses that might not be able to afford them or the resulting litigation

Upload filters are especially concerning for software developers given that:

  • Software developers create copyrightable works—their code—and those who choose an open source license want to allow that code to be shared
  • False positives (and negatives) are especially likely for software code because code often has many contributors and layers, often with different licensing for different components
  • Requiring code-hosting platforms to scan and automatically remove content could drastically impact software developers when their dependencies are removed due to false positives

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.

EU policymakers want and need to hear from developers

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.

How to reach EU policymakers

  1. 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

  2. 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!

Changelog

Subscribe

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more