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 | # ]
|
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 | # ]
|