That's how the DMCA process works. The last thing we want our users to think is we're deleting repos for no reason, that's why we're publishing the takedowns from here on out.
We receive the notice, lock the repo, and inform its owner why it's been locked. At that point, they can either remove the infringing code or make a counter claim and we'll unlock it provided the original party doesn't file a court order.
Isn't there an allowable delay in DMCA Takedowns? Some reasonable amount of time for the target to file a counterclaim before the content is locked? The way you've described it here sounds like you lock the content before notifying the user (or simultaneously).
The user can file a counterclaim immediately and indemnify github.
After that it would take a court order to get it taken down again, but that would mean the repository owner will be liable for the damages, not github.
This is the one part of the DMCA that actually seems to work reasonably well. If you're confident that your stuff does not infringe then it's back up within a very short time and you know you're on the hook for any further fall out.
48 hours is the time require for action I believe, however the claimee can respond in however long they like, but the content must be unavailable until they file a counter claim.
72 hours to take down the infringing content upon receiving a valid DMCA notice. The content owner gets notified and they can then file a valid counter-notice. Then the counter-notice gets filed with the copyright claimer and a 10-day waiting period starts. If the claimer does not file a counter-counter-notice within the 10-day waiting period the content gets reposted. If they do file a counter-counter-notice, the ball gets passed back to the content owner to file a counter-counter-counter-notice and the 10-day period and claim process starts over.
As someone who runs a site that hosts content, this is great for us. We aren't allowed any sort of leeway in interpreting the claims and in return we are exposed to no liability. We are simply the middle man and have to do what's asked of us.
So the hoster doesn't actually need to take the content down right away, but within 72 hours? That is, if the customer files the DMCA challenge within 72h, then the content will have always remained up? My questions here are with regard to continuity of availability.
It seems to me more about letting people know why they have taken down the content rather than challenging the law like the take down lists on things like the pirate bay.
What if the infringing content was committed after the fork was created? It'd be pretty bad locking repos that did not merge in the offending line(s) of code.
That's a sensible implementation if you want to be sure you're covered (or aren't ballsy enough, I'd probably take out the forks), but I wonder how long they could go by not taking action on the forks unless the specific forks are identified.
Just consider Youtube a moment. Couldn't they minimally run a hash on any uploaded/embedded sound and see if it matches the hash of some taken-down material before? It'd probably catch at least a significant number of users even if it's trivial to bypass and susceptible to compression losses and quiet-extensions and so forth. (An AI could always "listen" to it though and probably perform pretty well.) Anyway, Youtube doesn't make an automated effort to take down infringing material (that I know of) so I don't see why Github has to.
Assuming a modicum of technical sophistication on behalf of the legal people (which may be an invalid assumption), I think the fact that git/github is centered on the forking/sharing of code with an explicit graph to walk would just incur too much liability for them because it is obvious (in a technical sense) where the code has gone.
You don't have to do any forensics in the sense of your youtube example, you just have to follow the graph.
Whether that it is a legally compelling point, I have no idea.
