decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
The case seems apt - but what was Sony's reply? | 393 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Directional compatibility
Authored by: Chromatix on Friday, May 25 2012 @ 03:09 PM EDT

Connectix is a fairly well-known software vendor in Mac circles. I initially didn't recognise their name because the documents said "personal computer".

The PlayStation is a video game console that enables users to play video games on a television set. Connectix necessarily used code resident in the PlayStation during Connectix' reverse engineering process to understand how to emulate it. Then, Connectix created an entirely new work, VGS, that allows PlayStation games to run on Macintosh computers. Sony concedes that Connectix' final product does not contain or otherwise infringe any of Sony's copyrighted code; Sony also concedes that copying and disassembly of Sony's code is necessary to create a compatible product.

This is slightly different from what Google has done in the following, arguably minor, ways:

1: Connectix had to reverse-engineer Sony's code in order to obtain the required information to implement the APIs and ABIs that PS games rely on. Google obtained equivalent information from openly published books (at least two of which are now court exhibits) and Open Source software.

2: Connectix, in seeking to emulate the PlayStation, aimed for 100% compatibility and correspondence, at the binary level, with Sony's APIs. Google, in seeking to create a new software platform for mobile phones, aimed for compatibility with Java only at the source level, and with clear deviations from the original when engineering considerations (eg. the different input and rendering models) deemed it necessary.

3: Connectix succeeded in making their end-user product 100% copyright independent of Sony's work. Google didn't quite manage that, though the overlap was extremely small (if you ignore the API SSO itself) and very easily corrected once identified.

[ Reply to This | Parent | # ]

Directional compatibility
Authored by: Anonymous on Friday, May 25 2012 @ 03:27 PM EDT
Hi PJ,

I've read pages 1-28 of the pdf (up to the start of "Summary of the Argument" section) and here is what I have gleaned so far.

The case concerns the Sony BIOS code from the original PlayStation. This is a bunch of compiled code which is stored in ROM on every PlayStation, and exposes an API to PlayStation games so they can use it. Part of the BIOS is a "function table" which contains of code addresses, one for each API function in the BIOS. Each function expects to be invoked with specific arguments, to accomplish a specific thing--for example, there might be a function which copies some data from one memory address to another address, and it would expect 3 parameters: a source address, a destination address, and a size.

Anyway, here is what Connectrix did: First, they wrote all of the other parts of their "VGS" program -- a PlayStation emulator (code to emulate its CPU, its sound chip, its video chip, etc.) That was kind of like writing an entire Java VM. While doing this, they loaded a copy of Sony's BIOS into their VGS emulator, and also loaded PlayStation games into the emulator, and the combination of those two pieces of software plus their emulator code for emulating the hardware, makes up a complete system. But they didn't distribute or sell anything with the Sony BIOS in it. Apparently, they went to visit Sony and made one demonstration of their emulator code plus Sony's BIOS.

Anyway, they knew they couldn't use Sony's copyrighted BIOS code in their own product. They had to write their own code. But it would only work if it was 100% compatible. If a PlayStation game invoked the BIOS function in slot 10 of the function table, their replacement BIOS would have to do the exact same things that Sony's original BIOS would do (i.e. they had to implement the exact same API).

Unlike the current case, they may not have had access to API documentation spelling out exactly what each function had to do. The brief says they used reverse-engineering techniques on Sony's BIOS, to understand exactly what each function would do. It claims that they collected all of this information (about exactly what each function was supposed to do), and then used it to write a completely new implementation. I'm not sure if those two different activities overlapped temporally or not. The brief does assert that they did not start with Sony's BIOS and "incrementally replace" pieces of the code with their own code; it says they started with a blank slate and incrementally added their own code until it was done.

In some cases, they had problems running PlayStation games with their replacement BIOS (because of bugs). To track down these bugs, they would run the same game twice, once using Sony's original BIOS and once using their new replacement BIOS. They would record lots of data about what was going on in the emulator (probably traces of each instruction it executed, etc.) and then painstakingly analyzed these to understand the behavioural differences between Sony's BIOS and their own. I should emphasize here that they were doing this to identify every tiny functional element which was necessary for 100% compatibility. They would figure out details like "oh! when this function is passed *this* kind of invalid argument, it has to return *that* value". These are the same kinds of things that are part of the Java APIs -- not just the signatures of the Java methods, but the *ideas* about what exactly that method is supposed to do. It is the kind of information which is normally contained in the Java documentation. (However, in my past life working on a Java VM team, I know that our cleanroom class library implementors did not get 100% of their information from the Java documentation either; there are many tiny functional details which are not properly documented anywhere, and could only be discovered by reverse-engineering of Sun's implementation. Because we were doing a cleanroom implementation, our classlibrary implementors were not allowed to look at anything from Sun other than their public documentation. We had to have a separate team of different people, who would do the necessary reverse engineering and give very specific and narrow replies to the questions asked by our classlibrary team).

Anyway, by using reverse-engineering techniques, Connectrix was able to deduce the functional information about exactly what each function needed to do (because various PlayStation games would rely on those details, and might not work properly if these functional elements were not 100% compatible). And then write their own code for each function. They didn't implement every function from Sony's BIOS, only the ones that were used by some PlayStation games (around half of all of the functions). The unused functions they just left blank in their new BIOS's function table, since none of the games needed them. They did not use any of Sony's code in the final product, they only studied it to learn the ideas (and functional API elements) from it.

This is analogous to Apache Harmony using Sun's documentation and other information sources, to deduce exactly what each class and method in Sun's Java packages was supposed to do, and writing their own implementation from scratch. They had to have a 100% compatible API, and meet the same functional requirements -- do the same things, but not necessarily in the same way.

Connectrix argues in this brief, that Sony is not entitled to patent-like protection (protection of the ideas) on their Sony BIOS, and that preventing Connectrix from reverse-engineering those ideas and making their own implementation of the same ideas, is beyond the scope of copyright law. In effect, they argued that the APIs are functional elements which would necessarily have to be copied exactly in any compatible implementation, and that Sony could not use copyright law to prevent Connectrix from re-implementing these APIs.

Oracle is claiming copyright protection on the SSO of their Java APIs, and if the court admits their, erm, "novel" interpretation of copyright law, it will have the same effect that Connectrix claimed: it will give Oracle "patent-like" protection on their APIs, preventing other people from re-implementing them. It will become impossible to make a compatible, interoperable replacement for someone else's software library without risk of infringement.

[ Reply to This | Parent | # ]

The case seems apt - but what was Sony's reply?
Authored by: bugstomper on Friday, May 25 2012 @ 11:24 PM EDT
Given that Connectix won that appeal, I suppose their brief is more important
than Sony's counter to it, but what about the actual decision that resulted from
this case - Is the court's decision available to read?

Just from the Connectix brief, as a techie and not a lawyer I would say that
Google's charactizaton of it is spot on.

The major difference in the cases favors Google. Connectix had to resort to
reverse engineering in order to learn about the API of the BIOS before they
could duplicate the "SSO" of the BIOS. Google was able to work from
freely available information, as there was no question that they were allowed to
read the Java API specification.

What I see as quite significant about Sony v Connectix are all the references to
what Connectix gleaned about the BIOS from their reverse engineering as being
not protected by copyright. The case was about the actual copies of the BIOS
that Connectix made as part of the reverse engineering process. There is no
indication that the SSO was considered protected. There is mention of what was
copied, which I think was the SSO, not being protected.

The fact that Connectix replicated only the 137 of the 242 functions in the BIOS
that their tests showed were needed by common games matches well with Google
implementing only the sixty-something packages that they considered important
for compatibility.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )