Judge William Alsup, the federal judge presiding over Oracle v. Google, is working hard on his upcoming decision on the copyrightability of the 37 asserted Java APIs. If the jury doesn't render a patent verdict by 1 PM local time today, the trial will resume on Tuesday, but the judge will likely spend quite some time on the copyrightability question. I really liked the questions he asked the parties on Monday because the answers to those questions, which are due by noon today, may help to clarify the essential distinction between an effort to make program A interoperate with program B (such as making a Java app run on a virtual machine) versus an arbitrary usurpation of intellectual property that results in fragmentation, the very opposite of compatibility.
This morning, Judge Alsup proactively raised a follow-up question for the parties' counsel that relates to the Sony v. Connectix video game emulator case (which Google quotes a lot and which I already discussed in connection with "fair use"):
"In the reply briefs due tomorrow at noon, please address the following question: In Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000), what did the accused infringer Connectix ultimately duplicate to allow desktops to run Playstation games? For example, was it application binary interfaces (if so, be specific and use examples as to what this would have included)? Was it names that would have been in the source code of the Playstation BIOS?"
To me, the answer is obvious: Connectix's product emulated binary system calls, and even if Connectix had copied the names in the source code of the PlayStation operating software somewhere, that wouldn't have made a single game run on the emulator. The emulator also had to emulate the CPU instructions, which are also just binary (and didn't appear to be at issue).
The fact that this was a binary emulator makes it fundamentally different from the Android/Java situation as I explained in yesterday's post, in which I also talked about those Sega and Sony decisions, which were "fair use" cases that didn't do anything to narow the scope of copyrightable subject matter. Google likes to portray those decisions as having created some kind of interoperability privilege. They may have established a kind of interoperability privilege at the level of "fair use", a question that is subsequent to infringement, which in turn has copyrightability as a prerequisite -- but those decisions don't change anything about the fact that copyrightability is a question of (functional) idea v. expression. That approach makes sense: if copyrightability is denied because something can be (but is not necessarily) used for compatibility/interoperability purposes, those pursuing fragmentation of the "embrace-extend-extinguish" kind get the benefit of a privilege that is meant to achieve the opposite. Copyrightability should depend on creativity, and if the use of copyrightable material is legitimate for overarching reasons, that determination can still be made at the "fair use" stage, which has the benefit that the way in which the relevant material is actually (as opposed to just potentially) used can be fully considered.
In the overall copyrightability context, I think a lot of people miss the point because they focus on elements and aspects that are clearly not copyrightable (such as short, simple names). But everything copyrightable consists of non-copyrightable elements. A single musical note isn't copyrightable, but a melody of a certain length may be. A simple black circle isn't copyrightable, but a larger picture that contains a black circle is. This blog post contains words, not a single one of which is copyrightable, but the text as a whole is, and even paragraphs or smaller units that consist of multiple words. A simple line of program code isn't copyrightable, but a useful computer program will consist of many simple lines. A cube isn't copyrightable, but an architectural work that consists of many cubes may be. Ultimately, everything copyrightable is not copyrightable because the material it's made of (if one breaks it down to the atomic level) is copyrightable on its own, but because of the structure, sequence and organization (SSO) of a number of non-copyrightable elements. And in my view, there's no reason why this shouldn't include the SSO of the asserted Java APIs. Sure, a single definition of a constant or a single definition of a function call for drawing a rectangle may not be copyrightable, but we're talking about many thousands of such elements, structured in a way that takes thought and creativity.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
