[kodablah]

"Accordingly, from now on we will require copyright owners to investigate and report each fork explicitly in a DMCA takedown notice."

I don't see how there are no legal fears or at least administrative ones here. If one submits a legitimate DMCA takedown and your site allows copies, it might be unreasonable (to a judge) that they must name all copies considering forks can happen between when the DMCA was submitted and the takedown occurs. Of course I don't know of a better way without GitHub annoying forked repository owners and favoring DMCA submitters.

[cbhl]

1. Does the DMCA require GitHub to take down forks? AFAICT, it is up to the copyright holder to find and submit takedown notices for each copy. Plus, it's literally one click for a copyright holder to get a list of all direct forks for a repository. And if it becomes a problem, GitHub can just change the policy -- retroactively, even, if a particular incident makes it necessary.

2. This could be an abuse vector. Fork a popular repository, add some DMCAed content to it, and watch the parent get taken down. Or compromise the parent because it's old/unmaintained/abandoned and watch all the child forks get taken down.

3. Everything on the internet has legal fears. The question is, how much, and are you willing to tolerate that risk?

[dangrossman]

Thanks to 17 USC § 512 (c), service providers are not liable for hosting copies of copyright infringing material so long as they don't have actual knowledge of that infringement. Since a fork can differ from its parent, notice that the parent may be infringing is not actual knowledge that the forks are as well. That means Github has, in theory, no legal liability for those copies. It can just point to federal law.

http://www.law.cornell.edu/uscode/text/17/512

[DannyBee]

"is not actual knowledge that the forks are as well"

You assert this as if this is how a judge would see it (or as if it is well tested). That seems highly unlikely to me.

It seems to be very easy to make the legal argument that because github knows which forks are copies and which aren't, they have actual knowledge of the ones that are still copies.

[wtallis]

In order for GitHub to be presumed to know that the forks are also infringing, the takedown notice would have to specify what in the repo is infringing so that GitHub could compare the contents of the forks against the instance that the takedown notice is filed against. If the notice doesn't specify any particular files in the repo, then GitHub can't be expected to remove any fork that has any deletions in its history since the branch. The ease with which the accuser can check the forks for infringement also shifts the burden away from GitHub.

[rhino369]

But once they get a takedown notice they have actual knowledge that the material is infringing. If there is a fork that they know about, they do have actual knowledge. They have been doing it in the past, and if they now try to make sure they don't know about forks, that is willful blindness and they will still be found to be infringing.

512(c)(1)(a)(ii) has the so called "red flag" requirement. "n the absence of such actual knowledge, is not aware of facts or circumstances from which infringing activity is apparent"

Essentially, if they know about a fork and a reasonable person would know it is infringing, they lose their safe harbor.

Does GitHub have in house counsel? This policy is risky and doing it response to an outcry about actual pirate programs this will look horrendous if they end up in court.

[fernandotakai]

from what i understood they have knowledge of the fork, but they don't have knowledge if the fork also contains copyrighted material -- so, if i fork x and i remove all the supposedly copyright stuff, my fork should be ok.

[rhino369]

Under the red flag requirement, they got to at least check or think about how identical the fork is.

Yea, if you fork Linux and your fork just happens to use a stolen logo. Obviously there is no reason to think Linux is infringing.

But if you are forking popcorn time, that is unreasonable to assume that the fork is going to be non-infringing.

A general assumption that forks are okay is not a reasonable assumption. They'll have to look at this on a case by case basis.

This is even easier when the infringing content is a file or code. There is no excuse for not removing the infringing file from all github projects. And it is easy to check the forks for containing the alleged infringing code.

The safe harbor is not there to protect people acting in bad faith.

[jrochkind1]

Any site that allows users to upload content allows 'copies'. In the sense that a user can easily download and then reupload a copy to any such site.

I'm sure there are _some_ legal fears, which is why they started with the original policy. But they have decided it is likely that the law does not require them to take down copies not specifically identified in the complaint -- just as it does not require other ISP's to identify on their own copies not mentioned in the complaint.

I think the main important point is that a fork isn't _neccesarily_ a copy, it may or may not be, the infringing material may have been added to the 'original' after the fork, or deleted from the copy after the fork.

[jpetersonmn]

But what if the forks didn't have the same code, and therefore didn't infringe? Lets say for example I just loved popcorn time's app so I forked it, but then I made my app only get video from free, non pirated sources or something. It would be a fork of popcorn time still, but not infringing.

(PS) I don't think popcorn time should have been taken down as it wasn't stealing some copyrighted code.