Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Better DMCA Process

github.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: A Better DMCA Process

#11

Post by cbhl »

kodablah wrote: post #6

"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 an…

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?

Re: A Better DMCA Process

#12

Post by jrochkind1 »

kodablah wrote: post #6

"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 an…

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.

Re: A Better DMCA Process

#13

Post by jpetersonmn »

kodablah wrote: post #6

"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 an…

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.

Re: A Better DMCA Process

#14

Post by codezero »

whafro wrote: post #3

This is interesting because the DMCA process is, as I understood it (as a paralegal working on DMCA issues in a past life), a fairly rigid prescription that provides a safe harbor for providers like GitHub, ISPs, YouTube, etc. The simplified version of the process: 1. The party claiming to own the rights to copied content submits a well-formed DMCA takedown notice to the listed DMCA agent contact information of the p…

This caught me at first too. My guess is that they are blocking access to the infringing file for people other than the alleged offender.

Previously they disabled the whole repo, and this blocked everyone, including the alleged offender from accessing it.

Now it sounds like they will restrict access on a file level and give the alleged offender access to attempt to respond/modify the file to comply or appeal.

This effectively removes the offending content from public view, which should be interpreted as blocking access.

I'm not sure if this is exactly what happens but from how the process was described, it seems plausible and avoids some of the worries that Github isn't responding fast enough to claims.

Re: A Better DMCA Process

#15

Post by DannyBee »

dangrossman wrote: post #8
kodablah wrote: post #6

"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 an…

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. ht…

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

Re: A Better DMCA Process

#16

Post by DannyBee »

dangrossman wrote: post #5
whafro wrote: post #3

This is interesting because the DMCA process is, as I understood it (as a paralegal working on DMCA issues in a past life), a fairly rigid prescription that provides a safe harbor for providers like GitHub, ISPs, YouTube, etc. The simplified version of the process: 1. The party claiming to own the rights to copied content submits a well-formed DMCA takedown notice to the listed DMCA agent contact information of the p…

Here's the actual relevant text from the bill [1]: > upon notification of claimed infringement as described in subsection (c)(3), responds expeditiously to remove, or disable access to, the material that is claimed to be infringing or to be the subject of infringing activity Immediately contacting the repository owner, and asking them to remove the content themselves within a short window of time, sounds like an expe…

"Immediately contacting the repository owner, and asking them to remove the content themselves within a short window of time, sounds like an expeditious response to my non-lawyer ears.

Except, uh, you cut out the object of this sentence, which is the service provider, not the user.

That is, github, not the user, is supposed to be the person responding expeditiously to remove. Contacting someone is neither "removing" nor "disabling access".

The law is simply not ambiguous here, and github trying to play this game is not likely to go well in an actual court, as much as i'd like it to be the case (i know other companies have been threatened on exactly this point before).

Re: A Better DMCA Process

#17

Post by daxelrod »

codezero wrote: post #14
whafro wrote: post #3

This is interesting because the DMCA process is, as I understood it (as a paralegal working on DMCA issues in a past life), a fairly rigid prescription that provides a safe harbor for providers like GitHub, ISPs, YouTube, etc. The simplified version of the process: 1. The party claiming to own the rights to copied content submits a well-formed DMCA takedown notice to the listed DMCA agent contact information of the p…

This caught me at first too. My guess is that they are blocking access to the infringing file for people other than the alleged offender. Previously they disabled the whole repo, and this blocked everyone, including the alleged offender from accessing it. Now it sounds like they will restrict access on a file level and give the alleged offender access to attempt to respond/modify the file to comply or appeal. This ef…

Is there a mechanism they could use for blocking access to the file from within git without rewriting all of the commits (and therefore changing hashes)?

Re: A Better DMCA Process

#18

Post by rhino369 »

dangrossman wrote: post #8
kodablah wrote: post #6

"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 an…

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. ht…

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.

Re: A Better DMCA Process

#19

Post by codezero »

daxelrod wrote: post #17
codezero wrote: post #14

Earlier quoted context omitted.

This caught me at first too. My guess is that they are blocking access to the infringing file for people other than the alleged offender. Previously they disabled the whole repo, and this blocked everyone, including the alleged offender from accessing it. Now it sounds like they will restrict access on a file level and give the alleged offender access to attempt to respond/modify the file to comply or appeal. This ef…

Is there a mechanism they could use for blocking access to the file from within git without rewriting all of the commits (and therefore changing hashes)?

I'm not sure I completely understand your question, but my guess is they are blocking access to the file from github.com which is all they need to do to comply with the DMCA request. They can't do anything about people's local copies.

Re: A Better DMCA Process

#20

Post by fernandotakai »

rhino369 wrote: post #18
dangrossman wrote: post #8

Earlier quoted context omitted.

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. ht…

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 suc…

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.
Post reply on HN