Oracle Disagrees With Google’s Suggestion That Sony, Sega Created Exception to Copyrightability

3. Google’s Interoperability Arguments are Irrelevant to Copyrightability

Oracle also argues that the district court erred in invoking interoperability in its copyrightability analysis. Specifically, Oracle argues that Google’s interoperability arguments are only relevant, if at all, to fair use—not to the question of whether the API packages are copyrightable. We agree.

In characterizing the SSO of the Java API packages as a “method of operation,” the district court explained that “[d]uplication of the command structure is necessary for interoperability.” Copyrightability Decision, 872 F. Supp. 2d at 977. The court found that, “[i]n order for at least some of [the pre-Android Java] code to run on Android, Google was required to provide the same java.package.Class.method() command system using the same names with the same ‘taxonomy’ and with the same functional specifications.” Id. at 1000 (emphasis omitted). And, the court concluded that “Google replicated what was necessary to achieve a degree of interoperability—but no more, taking care, as said before, to provide its own implementations.” Id. In reaching this conclusion, the court relied primarily on two Ninth Circuit decisions: Sega Enterprises v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992), and Sony Computer Entertainment, Inc. v. Connectix, Corp., 203 F.3d 596 (9th Cir. 2000).

Both Sega and Sony are fair use cases in which copyrightability was addressed only tangentially. In Sega, for example, Sega manufactured a video game console and game cartridges that contained hidden functional program elements necessary to achieve compatibility with the console. Defendant Accolade: (1) reverse-engineered Sega’s video game programs to discover the requirements for compatibility; and (2) created its own games for the Sega console. Sega, 977 F.2d at 1514-15. As part of the reverse-engineering process, Accolade made intermediate copies of object code from Sega’s console. Id. Although the court recognized that the intermediate copying of computer code may infringe Sega’s copyright, it concluded that “disassembly of copyrighted object code is, as a matter of law, a fair use of the copyrighted work if such disassembly provides the only means of access to those elements of the code that are not protected by copyright and the copier has a legitimate reason for seeking such access.” Id. at 1518. The court agreed with Accolade that its copying was necessary to examine the unprotected functional aspects of the program. Id. at 1520. And, because Accolade had a legitimate interest in making its cartridges compatible with Sega’s console, the court found that Accolade’s intermediate copying was fair use.

Likewise, in Sony, the Ninth Circuit found that the defendant’s reverse engineering and intermediate copying of Sony’s copyrighted software program “was a fair use for the purpose of gaining access to the unprotected elements of Sony’s software.” Sony, 203 F.3d at 602. The court explained that Sony’s software program contained unprotected functional elements and that the defendant could only access those elements through reverse engineering. Id. at 603. The defendant used that information to create a software program that let consumers play games designed for Sony’s PlayStation console on their computers. Notably, the defendant’s software program did not contain any of Sony’s copyrighted material. Id. at 598.

As noted, both cases were focused on fair use, not copyrightability. In Sega, for example, the only question was whether Accolade’s intermediate copying was fair use. The court never addressed the question of whether Sega’s software code, which had functional elements, also contained separable creative expression entitled to protection. Likewise, although the court in Sony determined that Sony’s computer program had functional elements, it never addressed whether it also had expressive elements. Sega and Sony are also factually distinguishable because the defendants in those cases made intermediate copies to understand the functional aspects of the copyrighted works and then created new products. See Sony, 203 F.3d at 606-07; Sega, 977 F.2d at 1522-23. This is not a case where Google reverse-engineered Oracle’s Java packages to gain access to unprotected functional elements contained therein. As the former Register of Copyrights of the United States pointed out in his brief amicus curiae, “[h]ad Google reverse engineered the programming packages to figure out the ideas and functionality of the original, and then created its own structure and its own literal code, Oracle would have no remedy under copyright whatsoever.” Br. for Amicus Curiae Ralph Oman 29. Instead, Google chose to copy both the declaring code and the overall SSO of the 37 Java API packages at issue.

We disagree with Google’s suggestion that Sony and Sega created an “interoperability exception” to copyrightability. See Appellee Br. 39 (citing Sony and Sega for the proposition that “compatibility elements are not copyrightable under section 102(b)” (emphasis omitted)). Although both cases recognized that the software programs at issue there contained unprotected functional elements, a determination that some elements are unprotected is not the same as saying that the entire work loses copyright protection. To accept Google’s reading would contradict Ninth Circuit case law recognizing that both the literal and non-literal components of a software program are eligible for copyright protection. See Johnson Controls, 886 F.2d at 1175. And it would ignore the fact that the Ninth Circuit endorsed the abstractionfiltration-comparison inquiry in Sega itself.

As previously discussed, a court must examine the software program to determine whether it contains creative expression that can be separated from the underlying function. See Sega, 977 F.2d at 1524-25. In doing so, the court filters out the elements of the program that are “ideas” as well as elements that are “dictated by considerations of efficiency, so as to be necessarily incidental to that idea; required by factors external to the program itself.” Altai, 982 F.2d at 707.

To determine “whether certain aspects of an allegedly infringed software are not protected by copyright law, the focus is on external factors that influenced the choice of the creator of the infringed product.” Dun & Bradstreet Software Servs., Inc. v. Grace Consulting, Inc., 307 F.3d 197, 215 (3d Cir. 2002) (citing Altai, 982 F.2d at 714; Mitel, 124 F.3d at 1375). The Second Circuit, for example, has noted that programmers are often constrained in their design choices by “extrinsic considerations” including “the mechanical specifications of the computer on which a particular program is intended to run” and “compatibility requirements of other programs with which a program is designed to operate in conjunction.” Altai, 982 F.2d at 709-10 (citing 3 Melville B. Nimmer & David Nimmer, Nimmer on Copyright § 13.01 at 13-66-71 (1991)). The Ninth Circuit has likewise recognized that: (1) computer programs “contain many logical, structural, and visual display elements that are dictated by . . . external factors such as compatibility requirements and industry demands”; and (2) “[i]n some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for purposes of copyright.” Sega, 977 F.2d at 1524 (internal citation omitted).

Because copyrightability is focused on the choices available to the plaintiff at the time the computer program was created, the relevant compatibility inquiry asks whether the plaintiff’s choices were dictated by a need to ensure that its program worked with existing third-party programs. Dun & Bradstreet, 307 F.3d at 215; see also Atari, 975 F.2d at 840 (“External factors did not dictate the design of the 10NES program.”). Whether a defendant later seeks to make its program interoperable with the plaintiff’s program has no bearing on whether the software the plaintiff created had any design limitations dictated by external factors. See Dun & Bradstreet, 307 F.3d at 215 (finding an expert’s testimony on interoperability “wholly misplaced” because he “looked at externalities from the eyes of the plagiarist, not the eyes of the program’s creator”). Stated differently, the focus is on the compatibility needs and programming choices of the party claiming copyright protection—not the choices the defendant made to achieve compatibility with the plaintiff’s program. Consistent with this approach, courts have recognized that, once the plaintiff creates a copyrightable work, a defendant’s desire “to achieve total compatibility . . . is a commercial and competitive objective which does not enter into the . . . issue of whether particular ideas and expressions have merged.” Apple Computer, 714 F.2d at 1253.

Given this precedent, we conclude that the district court erred in focusing its interoperability analysis on Google’s desires for its Android software. See Copyrightability Decision, 872 F. Supp. 2d at 1000 (“Google replicated what was necessary to achieve a degree of interoperability” with Java.). Whether Google’s software is “interoperable” in some sense with any aspect of the Java platform (although as Google concedes, certainly not with the JVM) has no bearing on the threshold question of whether Oracle’s software is copyrightable. It is the interoperability and other needs of Oracle—not those of Google—that apply in the copyrightability context, and there is no evidence that when Oracle created the Java API packages at issue it did so to meet compatibility requirements of other pre-existing programs.

Google maintains on appeal that its use of the “Java class and method names and declarations was ‘the only and essential means’ of achieving a degree of interoperability with existing programs written in the [Java language].” Appellee Br. 49. Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing. While Google repeatedly cites to the district court’s finding that Google had to copy the packages so that an app written in Java could run on Android, it cites to no evidence in the record that any such app exists and points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.[15] The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 Java API packages, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Copyrightability Decision, 872 F. Supp. 2d at 978. Google’s interest was in accelerating its development process by “leverag[ing] Java for its existing base of developers.” J.A. 2033, 2092. Although this competitive objective might be relevant to the fair use inquiry, we conclude that it is irrelevant to the copyrightability of Oracle’s declaring code and organization of the API packages.

Finally, to the extent Google suggests that it was entitled to copy the Java API packages because they had become the effective industry standard, we are unpersuaded. Google cites no authority for its suggestion that copyrighted works lose protection when they become popular, and we have found none.[16] In fact, the Ninth Circuit has rejected the argument that a work that later becomes the industry standard is uncopyrightable. See Practice Mgmt. Info. Corp. v. Am. Med. Ass’n, 121 F.3d 516, 520 n.8 (9th Cir. 1997) (noting that the district court found plaintiff’s medical coding system entitled to copyright protection, and that, although the system had become the industry standard, plaintiff’s copyright did not prevent competitors “from developing comparative or better coding systems and lobbying the federal government and private actors to adopt them. It simply prevents wholesale copying of an existing system.”). Google was free to develop its own API packages and to “lobby” programmers to adopt them. Instead, it chose to copy Oracle’s declaring code and the SSO to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages. That desire has nothing to do with copyrightability. For these reasons, we find that Google’s industry standard argument has no bearing on the copyrightability of Oracle’s work.

[15] During oral argument, Google’s counsel stated that “a program written in the Java language can run on Android if it’s only using packages within the 37. So if I’m a developer and I have written a program, I’ve written it in Java, I can stick an Android header on it and it will run in Android because it is using the identical names of the classes, methods, and packages.” Oral Argument at 31:31. Counsel did not identify any programs that use only the 37 API packages at issue, however, and did not attest that any such program would be useful. Nor did Google cite to any record evidence to support this claim.

[16] Google argues that, in the same way a formerly distinctive trademark can become generic over time, a program element can lose copyright protection when it becomes an industry standard. But “it is to be expected that phrases and other fragments of expression in a highly successful copyrighted work will become part of the language. That does not mean they lose all protection in the manner of a trade name that has become generic.” Warner Bros., Inc. v. Am. Broadcasting Cos., 720 F.2d 231, 242 (2d Cir. 1983) (“No matter how well known a copyrighted phrase becomes, its author is entitled to guard against its appropriation to promote the sale of commercial products.”). Notably, even when a patented method or system becomes an acknowledged industry standard with acquiescence of the patent owner, any permissible use generally requires payment of a reasonable royalty, which Google refused to do here. See generally In re Innovatio IP Ventures, LLC, No. 11-C-9308, 2013 U.S. Dist. LEXIS 144061 (N.D. Ill. Sept. 27, 2013).