Sony Lawsuits Target PS3 Jailbreak Authors 205
StikyPad writes "PS3News is reporting that Sony's latest legal salvo is targeting the creators of PS JailBreak, PSFreedom and PSGroove-related PS3 hacks, citing numerous court documents for those interested. From one of the documents: 'Having considered the Motion for Expedited Discovery of Plaintiff Sony Computer Entertainment America LLC (oeSCEA) [...] the Court hereby grants SCEA's Motion. IT IS HEREBY ORDERED that [...] SCEA has leave to serve similarly targeted subpoenas or deposition notices to any other third party who SCEA learns may be involved in the distribution or sale of the oePS Jailbreak software, known as, for example, "PSGroove," "OpenPSJailbreak," and "PSFreedom," or who may have knowledge of the distribution or sale of this software.'"
Re:Sony should have lost this already. (Score:5, Informative)
Insofar as "piracy" is a common, if somewhat informal, term for acts which violate copyright law, sure. At least, it is if the SDK is protected by copyright, if the work you create is a derivative work under copyright law, and you have neither a license to use the SDK for the purpose nor the protection of an applicable exception to copyright law.
While, absent litigation on the specific cases, there's may be some room for debate, I'd expect that most uses of a leaked Sony SDK to create homebrew PS3 software, and the copying and distribution of such software after it was created, be "piracy".
Re:Sony should have lost this already. (Score:5, Informative)
The jailbreak itself doesn't use Sony's SDK. Pretty much all currently available homebrew (except maybe PSPong?) does use it however, since there isn't a stable open alternative...yet. Building a complete, mature, and stable SDK for a newly accessible system in, what, a month? is frankly an unreasonable demand.
Sony should be driving legal action to stop the current PSJailbreak scene, but they shouldn't be targeting the creators of PSGroove, PSFreedom, or OpenPSJailbreak -- they should be attacking the people who have released actual homebrew to date using the Sony SDK (which is, admittedly, basically all of it so far and includes the original creators of the PSJailbreak hack). That would protect their copyrights while also encouraging the creation of an open SDK as an alternative to the leaked Sony SDK.
Re:Sony should have lost this already. (Score:3, Informative)
The open source clones actually specifically disable the "piracy" function, by blocking bluray dvd access. It's admittedly not hard by any means to re-enable it, but it's disabled the way it is for a reason -- they haven't found a way to re-enable or reinstall Other OS yet, and the only "piracy" functionality really left after their alteration is "can run unsigned code."
They should crack down on the github branches that re-enable the piracy functionality, and on the so-called "hermes payload" which is an altered payload with more advanced piracy functionality.
Re:Sony should have lost this already. (Score:3, Informative)
The problem is that all of the code is still there and working, they just changed a single string to subtly break it. Right, this "does the job", but it makes it so ridiculously easy to reenable that it could be considered similar to, say, openly selling a game console cheat device that just happens to enable loading copies if you hit the right button combination, load the right hacked configuration file, or enter the right magic cheat code. It's still dodgy.
And heck, I know full well that the people responsible for these open clones (at least the original PSGroove and PSFreedom authors) are perfectly capable of rewriting the code to yank out the piracy parts (and save a lot of space; for technical reasons, the payload is pretty constrained), especially seeing as it's been analyzed pretty thoroughly by now. This is why I'm advocating at least taking the (not much) time to make an independently compilable reimplementation that entirely does away with all of the redirect code, instead of just trivially disabling it.
Re:Sony should have lost this already. (Score:2, Informative)
I don't have a single pirated PSP game on my hacked PSP. Then again I don't know you.
Re:Sony should have lost this already. (Score:3, Informative)
you made me doubt myself and while wikipedia isn't the most reliable source, it's quick and usually in the right direction on non-controversial articles.
Sony vs. Universal City Studios [wikipedia.org]
While the ruling wasn't as strong as I remembered, it was about that there were non-infringing uses and not even that there were widespread use of said non-infringing uses, but just the capability of non-infringing uses.
Re:Sony should have lost this already. (Score:3, Informative)
The US Copyright Office periodically publishes an exclusive list of permitted exceptions to the DMCA's anti-circumvention provisions. Unlocking a phone is on the list. Unlocking a video game console for this purpose isn't.
http://www.copyright.gov/1201/ [copyright.gov]
I think you should be able to do it. The DMCA is a pile of shit. There's no good reason why uses of hardware that don't involve copyright infringement or unauthorized network access should be prohibited,
Re:Sony should have lost this already. (Score:3, Informative)
That's not how copyright works. Derivative works don't have to be in the same class or perform the same function as the original, they just have to be derivative.
Static linking doesn't work like that. Your final binary includes large chunks of the SDK inside it (for typical homebrew, the SDK portions are larger than the homebrew itself). And the addresses of those chunks of code change depending on how things get linked. It's the same output that you would get if you had the full source code of the SDK libraries and used it as part of your app, except you don't get to see or change that code. The end result, nonetheless, includes a fully relocated and linked version of it.
I don't see why there would be an issue enforcing a license which is clearly being violated if you're not an authorized developer. Doing what you want with your own hardware is/should be a right, but you don't have the right to getting a convenient SDK for it.
They are, in fact, equivalent, in this case, as I've explained. This is how embedded SDKs work. This isn't new and applies to every console SDK and also pretty much every embedded SDK. It even applies to PC applications, just to a lesser extent: library code is usually dynamically linked, but header files are statically included, your program includes the compiler's support functions (e.g. floating point emulation where necessary, and general support routines such as function prologue and exception handling helpers). You also use the library's crt0 startup code. Again, these things come with licensing exceptions (e.g. libgcc comes with a linking exception) that we take for granted, but those licensing exceptions are still required.
Compiling code with a development system isn't like producing a data file with an application (e.g. making a document in a word processor). Software compilation always involves copying (sometimes large) parts of code from the SDK into your app.
Using prototype.js or jQuery on your Web application means you COPY them into your website and include them via script tags.
Now s/jQuery/SDK/ and s/Web application/game/ and s/script tags/static linking/. See what I mean?
(ignore the fact that you can include them from external URLs; this isn't an option on consoles. You have to pretend that instead of <script src=...> you actually copy and paste the entire thing into an inline <script> block)