paint-brush
Oracle Argues District Court Misapplied Merger Doctrineby@legalpdf

Oracle Argues District Court Misapplied Merger Doctrine

by Legal PDFOctober 11th, 2023
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

On appeal, Oracle argues that the district court: (1) misapplied the merger doctrine; and (2) failed to focus its analysis on the options available to the original author.

People Mentioned

Mention Thumbnail
featured image - Oracle Argues District Court Misapplied Merger Doctrine
Legal PDF HackerNoon profile picture

Oracle vs. Google (2014) Court Filing, retrieved on May 9, 2014, is part of HackerNoon’s Legal PDF Series. You can jump to any part in this filing here. This is part 8 of 16.

a. Merger

The merger doctrine functions as an exception to the idea/expression dichotomy. It provides that, when there are a limited number of ways to express an idea, the idea is said to “merge” with its expression, and the expression becomes unprotected. Altai, 982 F.2d at 707-08. As noted, the Ninth Circuit treats this concept as an affirmative defense to infringement. Ets-Hokin, 225 F.3d at 1082. Accordingly, it appears that the district court’s merger analysis is irrelevant to the question of whether Oracle’s API packages are copyrightable in the first instance. Regardless of when the analysis occurs, we conclude that merger does not apply on the record before us.


Under the merger doctrine, a court will not protect a copyrighted work from infringement if the idea contained therein can be expressed in only one way. Satava v. Lowry, 323 F.3d 805, 812 n.5 (9th Cir. 2003). For computer programs, “this means that when specific [parts of the code], even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.” Altai, 982 F.2d at 708 (citation omitted). We have recognized, however, applying Ninth Circuit law, that the “unique arrangement of computer program expression . . . does not merge with the process so long as alternate expressions are available.” Atari, 975 F.2d at 840.


In Atari, for example, Nintendo designed a program— the 10NES—to prevent its video game system from accepting unauthorized game cartridges. 975 F.2d at 836. Nintendo “chose arbitrary programming instructions and arranged them in a unique sequence to create a purely arbitrary data stream” which “serves as the key to unlock the NES.” Id. at 840. Because Nintendo produced expert testimony “showing a multitude of different ways to generate a data stream which unlocks the NES console,” we concluded that Nintendo’s specific choice of code did not merge with the process. Id.


Here, the district court found that, “no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different.” Copyrightability Decision, 872 F. Supp. 2d at 998. In its analysis, the court identified the method declaration as the idea and found that the implementation is the expression. Id. (“The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.”) (emphases in original). The court explained that, under the rules of Java, a programmer must use the identical “declaration or method header lines” to “declare a method specifying the same functionality.” Id. at 976. Because the district court found that there was only one way to write the declaring code for each of the Java packages, it concluded that “the merger doctrine bars anyone from claiming exclusive copyright ownership” of it. Id. at 998. Accordingly, the court held there could be “no copyright violation in using the identical declarations.” Id.


Google agrees with the district court that the implementing code is the expression entitled to protection—not the declaring code. Indeed, at oral argument, counsel for Google explained that, “it is not our position that none of Java is copyrightable. Obviously, Google spent two and a half years . . . to write from scratch all of the implementing code.” Oral Argument at 33:16.[5] Because it is undisputed that Google wrote its own implementing code, the copyrightability of the precise language of that code is not at issue on appeal. Instead, our focus is on the declaring code and structure of the API packages.


On appeal, Oracle argues that the district court: (1) misapplied the merger doctrine; and (2) failed to focus its analysis on the options available to the original author. We agree with Oracle on both points. First, we agree that merger cannot bar copyright protection for any lines of declaring source code unless Sun/Oracle had only one way, or a limited number of ways, to write them. See Satava, 323 F.3d at 812 n.5 (“Under the merger doctrine, courts will not protect a copyrighted work from infringement if the idea underlying the copyrighted work can be expressed in only one way, lest there be a monopoly on the underlying idea.”). The evidence showed that Oracle had “unlimited options as to the selection and arrangement of the 7000 lines Google copied.” Appellant Br. 50. Using the district court’s “java.lang.Math.max” example, Oracle explains that the developers could have called it any number of things, including “Math.maximum” or “Arith.larger.” This was not a situation where Oracle was selecting among preordained names and phrases to create its packages.[6] As the district court recognized, moreover, “the Android method and class names could have been different from the names of their counterparts in Java and still have worked.” Copyrightability Decision, 872 F. Supp. 2d at 976. Because “alternative expressions [we]re available,” there is no merger. See Atari, 975 F.2d at 840.


We further find that the district court erred in focusing its merger analysis on the options available to Google at the time of copying. It is well-established that copyrightability and the scope of protectable activity are to be evaluated at the time of creation, not at the time of infringement. See Apple Computer, Inc. v. Formula Int’l, Inc., 725 F.2d 521, 524 (9th Cir. 1984) (quoting National Commission on New Technological Uses of Copyrighted Works, Final Report at 21 (1979) (“CONTU Report”) (recognizing that the Copyright Act was designed “to protect all works of authorship from the moment of their fixation in any tangible medium of expression”)). The focus is, therefore, on the options that were available to Sun/Oracle at the time it created the API packages. Of course, once Sun/Oracle created “java.lang.Math.max,” programmers who want to use that particular package have to call it by that name. But, as the court acknowledged, nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result. In such circumstances, the chosen expression simply does not merge with the idea being expressed.[7]


It seems possible that the merger doctrine, when properly analyzed, would exclude the three packages identified by the district court as core packages from the scope of actionable infringing conduct. This would be so if the Java authors, at the time these packages were created, had only a limited number of ways to express the methods and classes therein if they wanted to write in the Java language. In that instance, the idea may well be merged with the expression in these three packages.[8] Google did not present its merger argument in this way below and does not do so here, however. Indeed, Google does not try to differentiate among the packages for purposes of its copyrightability analysis and does not appeal the infringement verdict as to the packages. For these reasons, we reject the trial court’s merger analysis.




[7] The district court did not find merger with respect to the structure, sequence, and organization of Oracle’s Java API packages. Nor could it, given the court’s recognition that there were myriad ways in which the API packages could have been organized. Indeed, the court found that the SSO is original and that “nothing in the rules of the Java language . . . required that Google replicate the same groupings.” Copyrightability Decision, 872 F. Supp. 2d at 999. As discussed below, however, the court nonetheless found that the SSO is an uncopyrightable “method of operation.”


[8] At oral argument, counsel for Oracle was asked whether we should view the three core packages “differently vis-à-vis the concept of a method of operation than the other packages.” See Oral Argument at 7:43. He responded: “I think not your Honor. I would view them differently with respect to fair use . . . . It’s not that they are more basic. It’s that there are just several methods, that is, routines, within just those three packages that are necessary to ‘speak the Java language.’ Nothing in the other thirty-four packages is necessary in order to speak in Java, so to speak.” Id. Counsel conceded, however, that this issue “might go to merger. It might go to the question whether someone—since we conceded that it’s okay to use the language—if it’s alright to use the language that there are certain things that the original developers had to say in order to use that language, arguably, although I still think it’s really a fair use analysis.” Id.



Continue Reading Here.


About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.


This court case 10-CV-3561 retrieved on September 22, 2023, from law.justia.com is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction.