US Copyright Group Says BitTorrent's Architecture Explains Why It's Ok To Lump 5,000 Defendants Into One Lawsuit
from the they-could-all-be-sharing! dept
US Copyright Group (really DC-based law firm Dunlap, Grubb & Weaver) is the group that famously has sued thousands of people not to actually take anyone to court, but in an attempt to find out who they are so it can send them “pre-settlement” letters, demanding payment of thousands of dollars to get them to drop a potential lawsuit. Of course, for this “business model” to work, it can’t actually get involved in costly lawsuits or even go to the trouble of spending the fees involved in filing lots of separate lawsuits in the location where the defendants actually live. So it lumped them all together into a single lawsuit in DC. Lots of folks quickly pointed out that this seems to violate the law, and the judge in one of the cases has asked USCG to explain why she shouldn’t dump all but one of the defendants from the suit.
THREsq is reporting on USCG’s response, where it tries to defend lumping all of the defendants into one giant case through the somewhat amusing claim that, due to the way BitTorrent works, all the defendants are linked because (who knows!?!) all of the defendants may have actually shared bits of the file with each other! Seriously.
Under the BitTorrent protocol, the initial file-provider intentionally elects to share or upload a file via a BitTorrent network…. This is called “seeding.” … Other users (“peers”) on the network connect to the seeder to download…. As additional peers request the same file, each additional user becomes a part of the network (or “swarm”) from where the file can be downloaded, which means that such additional user’s computer is connected not only to the seeder/uploader but also to other peer/downloaders…. Unlike the older P2P protocols, each new file downloader is receiving a different piece of the data from each user who has already downloaded that piece of data, all of which pieces together comprise the whole…. This means that every “node” or peer user who has a copy of the infringing copyrighted material on such a network–or even a portion of a copy–can also be a source of download for that infringing file, potentially both copying and distributing the infringing work simultaneously….
This distributed nature leads to a rapid viral spreading of a file through peer users, all of whom are both uploading and downloading portions of the file simultaneously…. As more peers join the swarm, the likelihood of a successful download increases… Because of the nature of the BitTorrent protocols, any peer that has downloaded a file prior to the time a subsequent peer downloads the same file is automatically a possible, and even likely, source of the file for the subsequent peer…. Essentially, because of the nature of the swarm downloads as described above, every infringer is simultaneously stealing copyrighted material through collaboration from many other infringers, through a number of ISPs, in numerous jurisdictions around the country.
Of course, no one charged anyone with theft here, so it’s a bit odd to see USCG claim that “stealing” happened. If that were the case, why not go to the police? But, more importantly, USCG is trying to argue that because BitTorrent involves little bits shared via a swarm, that it makes sense to link all the lawsuits since they may have been together in a swarm.
I can’t see how that actually makes any sense. Each of the actions were done independently, and there’s no evidence presented that these all were actually a part of the same swarm.
On top of that, I do wonder if calling out some of the specifics of how BitTorrent works could actually do harm to any case that actually goes to court (as if that will ever happen). Some have pointed out that with the way BitTorrent is set up, that anyone doing the sharing is contributing such a minimal part to the whole (something USCG seems to be admitting here), that users have a stronger (though, certainly not concrete) fair use claim, in that the amount they share/receive is tiny and not a large portion of the file.
Either way, this response seems pretty weak, and hopefully the judge agrees.