MGM v. Grokster Date Set 163
An anonymous reader writes "The Supreme Court has set March 29th as the date for oral arguments to begin in the Grokster trial. As we all know the final ruling will have ramifications on the tech world well beyond P2P. A decision is expected by end of July."
yeah, yeah; whoring~ (Score:5, Informative)
By Jon Newton 1/20/05
March 29 is the date set for oral arguments in MGM v Grokster when the major movie studios and Big Music cartel will once again try to force a decision saying p2p companies can be held responsible if customers use their p2p software to infringe copyrights.
The entertainment industry has already lost once on this in District Court, and again at the Ninth Circuit Court of Appeals.
But Hollywood won't take an unequivocal court decision for an answer and is now trying to bludgeon the US the Supreme Court into reversing.
"The lower court rulings were based on the Supreme Court's landmark decision in the 1984 Sony Betamax case, which determined that Sony was not liable for copyright violations by users of the Betamax VCR," says the EFF (Electronic Frontier Foundation) which is representing Morpheus owner StreamCast Networks.
A final decision is expected by the end of July 2005.
Re:1984 Decision (Score:5, Informative)
Justice Kennedy was sitting on the 9th Circuit appeals court in 1983-84, when this case was originally heard at the federal level. The 9th Circuit voted against Sony, although I have been unable to find how individual Judges voted in the case.
/. loves p2p (Score:3, Informative)
The 9th Circuit was spot on in this case (Score:5, Informative)
"Further, as we have observed, we live in a quicksilver technological environment with courts ill-suited to fix the flow of internet innovation. The introduction of new technology is always disruptive to old markets, and particularly to those copyright owners whose works are sold through well-established distribution mechanisms. Yet, history has shown that time and market forces often provide equilibrium in balancing interests, whether the new technology be a player piano, a copier, a tape recorder, a video recorder, a personal computer, a karaoke machine, or an MP3 player. Thus, it is prudent for courts to exercise caution before restructuring liability theories for the purpose of addressing specific market abuses, despite their apparent present magnitude."
Re:1984 Decision (Score:5, Informative)
The Ninth Circuit then denied en banc rehearing, meaning that it refused to rehear the case before a panel of all the circuit judges. The Supreme Court took the case and reversed the panel, 5-4.
Justice Kennedy was apparently never involved in the Betamax case at any level.
Re:1984 Decision (Score:3, Informative)
Re:1984 Decision (Score:2, Informative)
I concur.
Petition quote (Score:5, Informative)
I've been reading the documents involved, particularly the Ninth Circuit's decision and the **AA's petition for cert (request that the Supreme Court hear the case). It's been a while since I read Betamax, so I'll have to go back and read it next.
But quotes from the petition are sometimes thought-provoking, sometimes absurd. Most of the petition is **AA saying, "The Ninth Circuit misinterpreted Betamax! Look at the Seventh Circuit; they got it right!" Much of the arguments in the **AA's petition revolve around the argument that since the network could have been designed to block infringement, it should. (Personally, I doubt that the network could be so designed, since not even the mighty **AA has demonstrated an ability to effectively distinguish infringing uses. But most of the arguments have talked about the ability to block, rather than the technically more problematic ability to identify.)
One of the sidesplitters in the petition is this:
Similarly, under the Ninth Circuit's test a defendant's ability to block infringement is rendered irrelevant except in the narrowest circumstances.
The narrowest circumstances? The circumstances we have to consider are those on what we call planet Earth, not whatever alternative dimension that the **AA would like to live in. Indeed, the problem they have is that the "ability to block infringement" is only considered relevant if they actually, in real life do have such ability.
Oh, well, those are narrow circumstances indeed; we should instead consider if, in any imaginable world, they might have such an ability, and bend reality to match that world. Sorry, guys, we have to consider actual ability to block, not what they might have if they set themselves up exactly like Napster.
Most of the petition reads like this. The **AA feel that, because the network was designed without central control, that's evidence that they're guilty. It should have been designed with central control, and should prevent any infringing uses, because that would make the **AA happy. Because it's not designed that way, then Streamcast/Grokster are guilty of contributory and vicarious infringement.
The Ninth Circuit's opinion, by the way, is also a good read. Much less maddening than this petition, for sure.
I read the definition.... (Score:3, Informative)
Kjella
Re:When will they give up ? (Score:3, Informative)
<disclaimer>IANAL. This is not legal advice. If you need legal advice, consult a lawyer.</disclaimer>
Re:In percentage? (Score:3, Informative)
Basically, the 9th Cir. is too big. It needs to be split into a 9th and 12th, just like we split the old 5th into the current 5th and the 11th. (Hell, you might even be able to split it three ways)
Re:its not really about infringement (Score:3, Informative)
The only thing bittorrent does that in any way facilitates piracy is that someone hosting warez doesn't also get hit with a huge bandwidth bill. That's all; other than that, it might as well be nothing more than a webserver.
As for legal uses, besides the stuff on http://www.legaltorrents.com/ [legaltorrents.com], and linux ISOs (bittorrent is really
The solution? An internal bittorrent network. Easy to set up centrally and automate on all the machines, and it takes advantage of the large intra-lab bandwidth. The previous solution - rsyncing from the central machine - would take 5-6 hours and spike the central server's CPU almost the whole time. (the way the disk images change is apparently not rsync-friendly) This solution takes less than an hour with no serious CPU load on the central server; after all, the tracker is only watching a few hundred clients at once.
(Disclaimer: I didn't do this, I just was talking to the guy who did)