A Better DMCA Process
To bring more transparency and clarity to the processes surrounding the DMCA, we are rolling out three improvements to the way we process copyright takedowns: First, whenever possible, users will…
To bring more transparency and clarity to the processes surrounding the DMCA, we are rolling out three improvements to the way we process copyright takedowns:
- First, whenever possible, users will have a chance to fix problems before we take content down.
- Second, we will not automatically disable forks in a network based on the takedown of a parent repository unless the takedown notice explicitly includes them.
- Last but not least, we’ve published a completely revamped DMCA policy as well as a pair of how-to guides for takedown and counter notices to make our process more transparent and easier to understand.
Some Background
The Digital Millennium Copyright Act (DMCA) is a United States law that establishes how copyright holders must file complaints with internet service providers (ISPs) like GitHub, and what the ISPs must do in response.
The DMCA takedown process usually takes place behind closed doors, with little visibility for impacted users, let alone the opportunity for those users to modify the allegedly infringing content.
The average DMCA policy is also usually written in dense legalese that can be difficult to understand.
Our users deserve better.
GitHub already promotes transparency by posting DMCA takedown notices in a public repository.
And our Support Team works hard to help our users navigate the process.
Like most other ISPs, we have been disabling content whenever we receive a complete and seemingly legally adequate DMCA notice.
We have learned, however, that the conventional process is not a perfect fit for Git-versioned software projects.
So we decided to make some changes.
GitHub’s New Policy
The first change is that from now on we will give you an opportunity, whenever possible, to modify your code before we take it down.
Previously, when we blocked access to a Git repository, we had to disable the entire repository.
This doesn’t make sense when the complaint is only directed at one file (or a few lines of code) in the repository, and the repository owner is perfectly happy to fix the problem.
In practice, our support team would often shuttle messages between the parties to work out a way for them to fix it.
That usually worked out well and everyone ended up happier at the end of the day.
So we are making it a formal part of our policy, and we are going to do it before we disable the rest of the repository.
The second change is that if we receive a takedown notice for a parent repository, we will not disable forks in the network unless they are specifically identified in the notice.
In our system, parent and fork repositories are linked so that if one is disabled, they are all automatically disabled.
In many cases, however, forked repositories may be different in significant ways from the parent.
Accordingly, from now on we will require copyright owners to investigate and report each fork explicitly in a DMCA takedown notice.
If some forks are not identified, we will split up the network to avoid needlessly disabling unnamed fork repositories.
Finally, we’ve also taken this opportunity to completely revamp our DMCA policy itself so that it is easier to understand, provides more background information, additional resources and outlines the process in detail.
We want you to understand clearly what a takedown means, how to submit a takedown notice to GitHub, and how to respond to one if you believe there has been a mistake and want your content restored.
We hope you find our revised policy easier to use.
Please feel free to email us with questions or comments at copyright@github.com.
Written by
Related posts
Apply now for GitHub Universe 2023 micro-mentoring
As part of our ongoing commitment to accelerate human progress through Social Impact initiatives, we’re offering students 30-minute, 1:1 micro-mentoring sessions with GitHub employees ahead of Universe.
The 2023 Open Source Program Office (OSPO) Survey is live!
Help quantify the state of enterprise open source by taking the 2023 OSPO survey.
Godot 4.0 Release Party 🎉
We are delighted to host the Godot 4.0 Release Party at GitHub HQ on Wednesday, March 22 from 6:30 pm to 9:30 pm. And you’re invited!