The Oracle v. Google jury is struggling with technical terminology and may, once again, be hung and potentially deliver another partial verdict. In this recent post, I discussed the patent liability issues the jury is dealing with.
In parallel to the jury's patent-related deliberations, Judge Alsup is working on his decision on the copyrightability of the structure, sequence and organization (SSO) of the 37 asserted Java APIs. Yesterday he sent the parties some excellent questions concerning interoperability. This post here is a follow-up to that post on interoperability in the sense that it focuses on the Sega and Sony decisions Judge Alsup referenced in yesterday's request for further briefing -- not in the form of an endorsement but simply because Google put those cases front and center, so the judge needs to analyze whether those two pillars of Google's anti-copyrightability argument are strong or not.
There are reasons for which Google's argument based on those cases is not only far-fetched but also besides the point.
I discussed Sega v. Accolade and Sony v. Connectix (which is partly based on Sega) in a recent post on Google's "fair use" argument. Those are "fair use" cases that say very little about copyrightability. Google claims that Sega nevertheless supports its anti-copyrightability case:
"Thus, under Oracle's definition, all of the SSO of all 166 J2SE 5.0 API packages is functionally required for compatibility--which includes the SSO of each and every one of those packages.
Under Sega, this means that the SSO of all 166 J2SE 5.0 API packages is uncopyrightable. 977 F.2d at 1522. Notably, although Sega was a fair use case, the Ninth Circuit did not rely on fair use to conclude that functional requirements for compatibility are not copyrightable. Instead, the court relied on section 102(b). Indeed, the ultimate fair use holding depends on this statement of law."
I will now explain why this -- especially the central sentence that begins with "Notably" -- is just wrong.
The Sega decision was, as I explained in the "fair use" context, not a decision on API copyrightability per se. The issue was intermediate copying, and the only copyrightable material that appeared in the finished product was minuscule (20-25 bytes, as opposed to hundreds of APIs comprising many thousands of methods).
The final sentence in the above quote (which begins with "Indeed") is accurate only in one respect: the "fair use" decision in Sega took into consideration the purpose for which the defendant (Accolade) infringed copyrights through intermediate copying for the purpose of reverse engineering. The word "depends", especially since it's italicized, overstates the relevance of this, but I don't deny that there's some relevance of the aforementioned purpose. However, what's wrong is to describe the sentence "functional requirements for compatibility are not copyrightable" as a "statement of law", and to then suggest (in connection with the Java APIs) that anything that is needed for copyrightability is by definition copyright-free.
I have read the Sega decision several times, and it uses compatibility only as an argument in favor of "fair use" (i.e., as part of a justification of an infringement), but never once as an argument against copyrightability of anything. Yes, never once.
What Sega says is simply that functional elements of a program -- unlike expressive elements -- aren't protected by copyright. That wasn't a new "statement of law". It merely restated what the law has always been ever since anyone claimed copyright in a computer program.
There's a right way and a wrong way to read Google's statement that "functional requirements for compatibility are not copyrightable":
The wrong way -- the one suggested by Google -- is to read it like this:
"The functional_requirements_for_compatibility are not copyrightable"
(looking at the four words connected with underscore symbols as a definition of one category of non-copyrightable material)
The right way is this:
"Functional elements of a computer program have never been copyrightable. In Sega, the unprotected elements at issue happen to be relevant to compatibility, which has no bearing on copyrightability but plays a role in the 'fair use' context."
I can prove this right-way-wrong-way comparison based on actual quotes from the Sega decision. The second and the third sentence of the ruling summarize the "fair use" part, and if you bear in mind the distinction I just outlined, you will see that it's supported by those two sentences:
"We are asked to determine, first, whether the Copyright Act permits persons who are neither copyright holders nor licensees to disassemble a copyrighted computer program in order to gain an understanding of the unprotected functional elements of the program. In light of the public policies underlying the Act, we conclude that, when the person seeking the understanding has legitimate reason for doing so and when no other means of access to the unprotected elements exists, such disassembly is as a matter of law a fair use of the copyrighted work."
As you can see in the above passage, the Ninth Circuit's own summary of the "fair use" part of its ruling doesn't even mention "compatibility" -- a concept that Google says the ruling "depends" on. Instead, the Sega logic is that some infringement in the process of disassembly must be tolerated if it's (i) needed "in order to gain an understanding of the unprotected functional elements of the program" (which aren't necessarily limited to compatibility) and (ii) if there's a further "legitimate reason for doing so", which in the Sega case happened to be compatibility but could also be some other "legitimate reason" -- for example, I could imagine a scenario in which someone would use the need to fix a security hole as an excuse for reverse engineering.
Here's another sentence -- the one that is closest to Google's alleged "statement of law" and still says something that doesn't help Google in any way:
"The declarations of Accolade's employees indicate, and the district court found, that Accolade copied Sega's software solely in order to discover the functional requirements for compatibility with the Genesis console – aspects of Sega's programs that are not protected by copyright. 17 U.S.C. Section 102(b)."
Again, the reason for denying copyrightability here is the functional nature, not the purpose of compatibility.
The focus on access -- as opposed to redistribution -- is also underscored by this passage from the Sega decision:
"We conclude that where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law. Our conclusion does not, of course, insulate Accolade from a claim of copyright infringement with respect to its finished products. Sega has reserved the right to raise such a claim, and it may do so on remand."
This shows that the Ninth Circuit didn't rule out that Accolade might actually have used some copyrighted material from Sega in its finished products. There was just enough of a legitimate reason for disassembly because there was some unprotected material to be discovered.
The bottom line is that Sega, apart from being a "fair use" rather than copyrightability case and dealing on the copyright infringement side with two issues that are worlds apart from the Android/Java case (intermediate copying in Sega, high-volume distribution in Oracle v. Google; use of the string "SEGA" in Sega, use of hundreds of APIs comprising many thousands of methods in Oracle v. Google), didn't make any "statement of law" that would create any kind of tension or conflict between compatibility and copyrightability. Sega didn't restrict the scope of copyrightable subject matter in the slightest -- it only restated the non-news that "functional elements" are unprotected by copyright, something that I've never seen Oracle deny anyway.
The Sony case doesn't narrow the scope of copyrightable subject matter either. Much to the contrary, while it frequently cites Sega, it doesn't even contain any passage that Google could take out of context like its alleged "statement of law". In the Sony decision, any reference to what is and what isn't protected by copyright is unequivocally based on the fact that functional elements aren't protected. For example, the second and third sentence of the section on "fair use" make perfectly clear that this was once again an access-centric line of thought, a conclusion that infringements of protected material may be allowed, within reason and with sufficient justification, in order to discover unprotected material:
"The unprotected ideas and functions of the code therefore are frequently undiscoverable in the absence of investigation and translation that may require copying the copyrighted material. We conclude that, under the facts of this case and our precedent, Connectix's intermediate copying and use of Sony's copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony's software."
Since Sony never even appears to link copyrightability and compatibility to each other, Google doesn't quote from it too much. But Sony was even more "fair use"-friendly than Sega, and just as copyrightability-neutral.
In other words, there's absolutely no reasonable take-away from Sega and Sony for the purposes of arguing against API copyrightability. Neither ruling said that the more something is related to compatibility, the less likely it is to be copyrightable. No such correlation.
As a result, we're back to square one and have to make a distinction between functional and expressive elements. I discussed the idea/expression dichotomy before, such as in connection with the Johnson Controls case.
The Java APIs are clearly so expressive that they easily meet the Johnson Controls hurdle for a copyrightable SSO. And in terms of expressiveness, they're fundamentally different from what was at issue in both Sega and Sony. In those video game console cases, the kind of compatibility that was needed was just binary compatibility: one could take a binary executable and it would work (Accolade's cartridges ran on Sega's consoles, Sony's and other publishers' PlayStation games ran on Connectix's emulator). I have plenty of experience with entirely binary interfaces. Back in the 1980s I wrote several books on certain binary APIs (the Commodore 64 operating system and GEOS, a graphical operating system for Commodore home computers). The game consoles at issue in Sony and Sega also had binary APIs. "Binary API" means that a program calls a particular fixed address in memory, such as $8000 (hexadecimal for 32,768), and provides certain parameters in accumulators and registers or fixed memory locations. While the developers who write the code of and behind the binary APIs do give those functions (and sometimes the parameters) names in their own assembly source code, neither Accolade nor Connectix needed to know those names -- and they wouldn't have found them in the code they disassembled (they could only have found those names in some official developer documentation). Knowing all those names wouldn't have helped them to achieve compatibility: they needed binary compatibility so that existing binary files could run.
In Oracle v. Google, the closest concept to this binary compatibility issue is the structure of the Java bytecode and the format of the related files. But Oracle doesn't say Google isn't allowed to let app developers provide Java bytecode to the Android development tools such as "dx" that convert Java bytecode to Dalvik executable (Dex) code.
Therefore, even if one wanted to blow out of proportion the fact that the Ninth Circuit considered those binary APIs to be unprotected by copyright, one still wouldn't be able to deny that there's a fundamental difference from a copyrightability point of view between an entirely binary API (which was also much smaller in terms of the number of function calls than the 37 asserted Java APIs) and the structure, sequence and organization of the Java APIs. If Sega and Sony had established a rule that anything, no matter how expressive, is unprotected by copyright just because it serves a compatibility purpose, and if one also followed some other flawed elements of Google's proposed logic, then the difference between binary and expressive APIs wouldn't be outcome-determinative. But as I explained, that's simply not what Sega and Sony say. They only attach importance to compatibility in the "fair use" context.
"Fair use" is another thing that has to be determined here, provided that the SSO of the asserted APIs is deemed copyrightable by Judge Alsup and/or the appeals court. Google asked for a retrial, but it's worth noting that the Sega ruling explains that "fair use" questions can be decided as a matter of law after the facts have been established by the trial court:
"The statutory factors are not exclusive. Rather, the doctrine of fair use is in essence 'an equitable rule of reason.' Harper & Row, Publishers, Inc. v. Nation Enterprises, 471 U.S. 539, 560 [225 USPQ 1073] (1985) (quoting H.R. Rep. No. 1476, 94th Cong., 2d Sess. 65, reprinted in 1976 U.S.C.C.A.N. 5659, 5679). Fair use is a mixed question of law and fact. Id. . 'Where the district court has found facts sufficient to evaluate each of the statutory factors,' an appellate court may resolve the fair use question as a matter of law. Id.."
The cited Harper case also comes up in Oracle v. Google all the time. I discussed that one, too, in a recent post on "fair use" (where I called it the "President Ford biography" case). I just wanted to mention this here because it shows that Oracle might be able to defeat Google's "fair use" defense at the appeals court -- a hung jury is not the end of the road, nor is a retrial the only way to overcome such an impasse.
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:
