|
Oracle v. Google - The Copyright Contentions |
|
Tuesday, March 13 2012 @ 11:30 AM EDT
|
Last Friday the parties submitted their respective copyright liability trial briefs, i.e., what they are going to argue with respect to copyright at trial. (Google's Brief [PDF; Text]; Oracle's Brief [PDF; Text] The respective briefs are interesting both from the view of what they agree on (mainly whether matters are for the court to decide or the jury) and what they don't agree on (pretty much everything else, especially the burden of proof). We will walk through the Oracle's contentions of infringement with Google's response, and then Google's defenses and Oracle's response.
First, what's at issue. Oracle says it is copying and creating derivative works of: (a) 37 Java API design specifications; (b) the implementations of those specifications (here Oracle contends the source code may be original to Google but that such source code is a derivative work of the specifications); and (c) 11 Java software code files. With respect to the specifications, Oracle contends that Google copied them almost verbatim in creating the corresponding Android API specifications.
Oracle describes those specifications as defining:
... a package, and [with] a unique
name, such as “java.nio” or “java.util.” Packages may include classes, interfaces, and subpackages. For
each class in a package, the API specification describes the fields and methods within it and identifies those that are exposed to other classes. ... Methods are described by their “method signatures,” which include the
method name and the method parameters and their order, as well as the method return type and
any exception types thrown by the method. Fields are described by their name and type. Field
and method declarations may also include various modifiers that change their behavior,
inheritability, and accessibility. The API specification also describes the relationship of each
class to other classes and packages of classes. The Java API designers who wrote the
specifications decided which packages, classes, Interfaces, methods, and fields to include in the
API specifications, as well as the relationships and interdependencies among the thousands of
individual elements. ... These relationships can be found within a package or may extend
across different packages.
[emphasis added] I find the highlighted statement to be intriguing. I don't claim to be all that tech savvy, but it strikes me that what goes into an API is what has to go into an API for it to be effective. You are defining an interface. To be able to take advantage of that interface certain things have to be present, and in turn, certain information will be returned. Now I would agree that the programmers have a choice as to whether to create an interface, but once it is determined to be either necessary or desirable, what goes into that interface is far less subjective. Moreover, keep in mind that these APIs are, according to Google, necessary to make the freely available Java programming language functional.
So what did Google copy? Oracle provides an example:
In the case of the java.util package
alone, Google copied 49 classes, 16 interfaces, 20 exceptions, 85 fields, and 369 methods.
Google also copied the structural relationships among these elements within java.util, as well as
their relationships to the elements of other packages.
Oracle does not offer comparative information on how many classes, interfaces, exceptions, field, and methods there are in java.util. But let's assume Google copied most of them. By their very nature most of these elements are functional, and thus not protected by copyright.
Oracle then compares Java to a large literary work:
The Java API implementations are analogous to a multi-volume history, such as the
Durants’ eleven-volume The Story of Civilization, and the Java API specifications are like the
author’s meticulously detailed outline of those works. It would be copyright infringement for a
second author to take the outline and publish a second multi-volume work containing identical
names for each volume, chapter, and subchapter, identical topics, facts, and primary sources
discussed to the same level of detail, appearing in exactly the same order, and accompanied by identical photographs and drawings, but change the wording of the text. And it would be
copyright infringement for the second author to publish an outline of the second multi-volume
work that matches the original author’s outline almost exactly.
This is a terrible analogy. Books and software are not really that comparable. Books would tend to have far less content that would be deemed unprotectable by copyright, although they would have some (historical facts, photographs that are in the public domain, etc.) I am quite certain that from Google's perspective in this analogy they copied information that was not and could not be protected by copyright.
Let's not even dwell on the 11 code files. Google admitted they got into Android, but they have also been removed from the Android distribution.
Oracle then turns to its assertions of liability. To show direct infringement Oracle need only show that it owns the copyrights and that "constituent elements of the work that are original" have been copied by Google. I don't recall Google ever questioning Oracle's ownership of the copies, so let's assume that is a given.
The real question is one of whether Google copied "original element," i.e., subject matter protected by copyright. This is the argument over the selection, arrangement and structure of the API specifications, and there are two issues present: (1) whether APIs by their nature are protectable by copyright; and (2) who bears the burden of proof of such protection. Interestingly, the parties disagree most vigorously on the second point. Oracle contends that Google bears that burden of proof and cites to Lanard Toys Ltd. v. Novelty, Inc.,
375 Fed. Appx. 705 (9th Cir. 2010). Google contends that Oracle bears the burden of proof and cites to Jada Toys, Inc. v. Mattel, Inc. 518 F.3d 628 (9th Cir. 2008). It can't be both ways, so this is clearly a threshold issue for the court.
Let's set aside the Oracle contentions with respect to indirect infringement for the time being. For there to be indirect infringement there must be direct infringement by someone. So the issue of indirect infringement only comes into play if Oracle can establish direct infringement.
That leaves us with the Google affirmative defenses, which are: (a) the selection, arrangement and structure of the API elements are unprotected by copyright; (b) the selection, arrangement and structure of the APIs are unprotected under the doctrine of scenes a faire; (c) the selection, arrangement and structure of the APIs are unprotected under the doctrine of merger (the expression and the idea are merged and, thus, unprotected); and (d) any copying in the context of Oracle's damage claims has been de minimis and thus a fair use. In descending order of utility, I think the strength of these arguments are (a), (c), (b), and (d). In other words, if Google is unable to demonstrate the functional nature of much of the subject matter in which Oracle claims a copyright, then the scenes a faire and de minimis copying arguments get much more difficult.
The separate derivative work claim continues to be the most interesting to me, i.e., that, according to Oracle, any source code implementation of an API specification is a derivative work of that specification. As I have noted before, I have a real problem. Google sums it up as follows:
If Oracle is correct, any implementation of any API specification is a derivative work, because as Oracle's expert concedes, implementing the APIs requires following the "rules" described in the specifications. ... Thus, although the Ninth Circuit has held that "functional requirements for compatibility" are not copyrightable, ..., following functional requirements for compatibility - according to Oracle - leads directly to infringement.
Finally, Google advances a number of equitable defenses substantially relying on Sun's tacit approval of Android. If anything, those defenses may influence (diminish) the amount of damages that may be awarded if Google is, in fact, found infringing of the Oracle copyrights, but it is doubtful that they would provide a primary line of defense to the claim of infringement itself.
****************
Documents
778
KEKER & VAN NEST LLP
ROBERT A. VAN NEST, #84065
[email]
CHRISTA M. ANDERSON, #184325
[email]
MICHAEL S. KWUN, #198945
[email address telephone fax]
KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email address telephone fax]
KING & SPALDING LLP
SCOTT T. WEINGAERTNER
(Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[address telephone fax]
IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
GREENBERG TRAURIG, LLP
[address telephone fax]
Attorneys for Defendant
GOOGLE INC.
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.
Case No. 3:10-CV-03561-WHA
GOOGLE'S OPENING COPYRIGHT
LIABILITY TRIAL BRIEF
Judge: Hon. William Alsup
TABLE OF CONTENTS
|
|
Page |
I. |
INTRODUCTION |
1 |
II. |
BRIEF SUMMARY OF REMAINING COPYRIGHT CLAIMS AND
ISSUES |
1 |
III. |
THE SPECIFICATION CLAIMS |
2 |
|
A. |
The Court must decide whether the selection, arrangement and
structure of the API elements are copyrightable, including any
subsidiary fact questions |
2 |
|
|
1. |
The APIs and the selection, arrangement and structure of
the API elements are uncopyrightable under 17 U.S.C.
§ 102(b) |
4 |
|
|
2. |
Alternatively, the selection, arrangement and structure of
the APIs are unprotected scenes a faire |
7 |
|
|
3. |
Alternatively, any expression in the selection,
arrangement and structure of the APIs has merged with
the underlying ideas |
9 |
|
B. |
The Court must decide whether the standard of substantial
similarity or virtual identity applies to Oracle's Specifications
Claims |
10 |
|
C. |
To the extent there are material disputed facts, the jury must
decide whether Google's use is a fair use
Claims |
11 |
IV. |
THE DERIVATIVE WORK CLAIMS |
12 |
V. |
THE FILE CLAIMS |
13 |
|
A. |
The Court should hold that the File Claims are moot |
13 |
|
B. |
If the File Claims are not moot, the Court should determine the
relevant "work as a whole," and the jury should decide whether
the alleged infringement was de minimis |
14 |
VI. |
GOOGLE'S EQUITABLE DEFENSES |
14 |
i
TABLE OF AUTHORITIES
| Pages(s) |
|
Federal Cases | |
|
Allen v. Academic Games League of Am., Inc.
89 F.3d 614 (9th Cir. 1996) |
9, 10 |
Apple Computer, Inc. v. Microsoft Corp.
35 F.3d 1435 (9th Cir. 1994) |
3, 5, 9, 10 |
Brown Bag Software v. Symantec Corp.
960 F.2d 1465 (9th Cir. 1992) |
11 |
Campbell v. Acuff-Rose Music, Inc.
510 U.S. 569 (1994) |
11, 12 |
Computer Assocs. Int'l., Inc. v. Altai
982 F.2d 693 (2nd Cir. 1992) |
7, 8, 9, 10, 14 |
Ets-Hokin v. Skyy Spirits, Inc.
323 F.3d 763 (9th Cir. 2003) |
11 |
Gates Rubber Co. v. Bando Chemical Industries, Ltd.
9 F.3d 823 (10th Cir. 1993) |
10 |
Harper House, Inc. v. Thomas Nelson, Inc.
889 F.2d 197 (9th Cir. 1989) |
4 |
Jada Toys, Inc. v. Mattel, Inc.
518 F.3d 628 (9th Cir. 2008) |
7, 9 |
Jonathan Browning, Inc. v. Venetian Casion Resort LLC
No. C 07-03983 JSW, 2009 U.S. Dist. LEXIS 57525 (N.D. Cal. June 18, 2009) |
3 |
Kelly v. Arriba Soft Corp.
335 F.3d 811 (9th Cir. 2003) |
11, 12 |
Lotus Dev. Corp. v. Borland Int'l, Inc.
788 F. Supp. 78 (D. Mass. 1992) |
3, 5, 6 |
Lujan v. Defendersw of Wildlife
504 U.S. 555 (1992) |
13 |
Mirage Editions v. Albuquerque A.R.T. Co.
856 F.2d 1341 (9th Cir. 1988) |
13 |
MiTek Holdings, Inc. v. ArcE Eng'g Co.
89 F.3d 1548 (11th Cir. 1996) |
14 |
Montgomery v. Noga
168 F.3d 1282 (11th Cir. 1999) |
3 |
Newton v. Diamond
388 F.3d 1189 (9th Cir. 2004) |
14 |
ii
Pivot Point, Int'l, Inc. v. Charlene Prods., Inc.
932 F. Supp. 220 (N.D. Ill. 1996) |
3 |
Satava v. Lowry
323 F.3d 805 (9th Cir. 2003) |
10 |
Sega Enters. Ltd. v. Accolade, Inc.
977 F.2d 1510 (9th Cir. 1992) |
passim |
Sony Comp. Ent't, Inc. v. Connectix Corp.
203 F.3d 596 (9th Cir. 2000) |
12 |
Sony v. Bleem
214 F.3d 1022 (9th Cir. 2000) |
11 |
Swirsky v. Carey
376 F.3d 841 (9th Cir. 2004) |
7 |
Tattoo Art, Inc. v. TAT Int'l, LLC
704 F. Supp. 2d 634 (E.D. Va. 2011) |
14 |
|
Federal Statutes | |
|
17 U.S.C. § 102(b) | 4, 5, 6 |
17 U.S.C. § 107 | 11 |
iii
I. INTRODUCTION
The Android platform includes over 150 source code libraries1 for use by Android developers. Among those libraries are ones that implement the specifications for over 50 Java API packages that facilitate the use of the freely available Java programming language to write applications. These Java API packages were originally developed by Sun and/or third parties, and have been public for many years. They are well-known to and commonly used by application developers, and have in the past been independently implemented and publicly distributed by third parties. Like the other independent implementations, the Android API libraries—37 of which are at issue in Oracle's copyright claim—utilize the functional elements of the API specifications (including the names, structure and organization of elements of the APIs), coupled with implementing source code independently developed by Google or based on existing, open-source independent implementations. The purpose of the API implementations in Android is to facilitate the use of the freely available Java programming language, consistent with application developers' expectations and enabling code written by third-party developers to be compatible between Android and other Java programming language environments.
II. BRIEF SUMMARY OF REMAINING COPYRIGHT CLAIMS AND ISSUES
Oracle alleges that Android infringes versions 1.4 and 5.0 of the Java 2 Standard Edition platform (collectively, "J2SE"). Am. Compl. [Dkt. 36], Ex. H. Oracle asks that the jury address three forms of alleged copyright infringement:
(1) Oracle claims that the Android specifications infringe the specifications of 37 Java API packages—that is, the documentation that describes the selection, arrangement and structure of the API elements, and the narrative descriptions that explain how the APIs can be used and what they do (the "Specifications Claims").
(2) Oracle claims that the source code implementation of the Android core libraries is a derivative work of the Oracle specifications (the "Derivative Work Claims").
(3) Oracle claims that 12 Android files—out of over 50,000 files in Android— include code or comments taken from 11 Oracle files (the "File Claims").
See Oracle's Proposed Verdict Form [Dkt. 531-1], Question l.a-c.2
1
Google contends that the selection, arrangement and structure of the API elements are not copyrightable, for several reasons. First, the selection, arrangement and structure are uncopyrightable ideas, processes, systems or methods of operation. Second, the selection, arrangement and structure are functional requirements for compatibility, and thus not protectable. Third, the selection, arrangement and structure are unprotectable scenes a faire, and/or their expression has merged into unprotected underlying ideas. Even if they are copyrightable, Google contends that any similarities arising from use of any protectable elements either are not substantial and are therefore noninfringing, or are a fair use.
Google contends that the File Claims are moot, because Oracle is entitled to neither damages nor injunctive relief in connection with these claims. To the extent that the File Claims are not moot, Google contends any alleged copying is de minimis, and thus not actionable.
Finally, Google contends that Oracle's copyright claims are barred by the equitable doctrines of laches, estoppel, waiver and implied license.
III. THE SPECIFICATIONS CLAIMS
In support of the Specifications Claims, Oracle argues (1) that the selection, arrangement and structure of the API elements are copyrightable—separate and apart from the code that implements the APIs—and that for the 37 API packages at issue, the Android specifications use substantially the same selection, arrangement and structure as the J2SE specifications; and (2) that the narrative descriptions in the Android specifications for the APIs are substantially similar to the narrative descriptions in Oracle's specifications for J2SE.
A. The Court must decide whether the selection, arrangement and structure of the API elements are copyrightable, including any subsidiary fact questions.
The Court has already held that the names of the API elements are not copyrightable. Copyright MSJ Order [Dkt. 433] at 7-8 ("Because names and other short phrases are not subject to copyright, the names of the various items appearing in the disputed API package specifications are not protected."). Moreover, aside from the File Claims, which are discussed separately below, Oracle does not claim that any of the Android source code that implements the
2
APIs was copied. Finally, Oracle does not claim copyright protection for the Java programming language itself. See id. at 3 ("The Java programming language has been made freely available for use by anyone without charge. Both sides agree on this.")
Oracle nonetheless argues that Google has copied the selection, arrangement and structure of API elements from the J2SE specifications. There is no dispute that the Android specifications for the 37 API packages at issue have substantially the same selection, arrangement and structure of API elements as the J2SE specifications. The parties disagree whether this selection, arrangement and structure is protected by copyright.
Copyrightability is a question of law. The Ninth Circuit has held that "[u]sing analytic dissection ... the court must determine whether any of the allegedly similar features are protected by copyright." Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1443 (9th Cir. 1994) (emphasis added).3
The Court must resolve any factual issues relevant to copyrightability; there are no subsidiary fact issues for the jury. Lotus Dev. Corp. v. Borland Int'l, Inc., 788 F. Supp. 78, 96 (D. Mass. 1992) ("issues of copyrightability, including any fact questions bearing upon them, must be determined by the court, not the jury." (emphasis added)). As Judge Easterbrook has explained, "[a] jury has nothing to do with" the copyrightability determination. Pivot Point, Int'l, Inc. v. Charlene Prods., Inc., 932 F. Supp. 220, 225 (N.D. 111. 1996).4
Indeed, there is no practicable way for the jury to decide any subsidiary fact issues. The issue of copyrightability must be decided before the jury deliberates, so that the Court can
3
instruct the jury what elements sshould be considered when deciding whether there was infringement.5 If there were threshold facts for the jury to decide prior to a copyrightability determination, the jury would first have to deliberate and decide those factual issues, the Court would then have to decide copyrightability and instruct the jury thereon, and the jury would thereafter have to continue its deliberations. Google is aware of no case where any court has ever adopted such a convoluted procedure for a copyright trial.6
Different courts have applied different doctrines to conclude that software interfaces are not copyrightable. While the doctrines relied upon by these courts have varied—with some concluding that the interfaces are unprotectable methods of operation or otherwise excluded by 17 U.S.C. § 102(b), others that the interfaces are unprotected scenes a faire, and others that any expression has merged with the underlying ideas—the end result has been the same. And the principles relevant to the inquiry are often the same, regardless of which doctrine is invoked.
1. The APIs and the selection, arrangement and structure of the API
elements are uncopyrightable under 17 U.S.C. § 102(b).
The Court must first decide whether the selection, arrangement and structure of the API elements are copyrightable subject matter. The Copyright Act states:
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
17 U.S.C. § 102(b) (emphasis added). In the order on Google's copyright motion for summary judgment, the Court held that the API package specifications are not methods of operation.
4
Copyright MSA Order [DKt. 433] at 11.
The Court, however, expressly left open whether the APIs described in the specifications are methods of operation. Id. at 10. ("Because the issue is not properly teed up for summary judgment, this order does not decide whether APIs are methods of operation.") "[T]he party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements." Apple, 35 F.3d at 1446 (quotation marks and citation omitted). Thus, even if the specifications are not methods of operation, Oracle cannot rely on any similarity between Android and J2SE that results from any elements of the specifications (such as the APIs, and the selection, arrangement and organization of the elements of the APIs) that are methods of operation (or ideas, processes or systems).
The API package specifications at issue provide access to standard Java language libraries that programmers learn to use when they learn to program in the Java programming language. The APIs themselves, which are described in the API package specifications, are the means by which developers can access the implementing code in the Java language libraries. They provide, in a very literal sense, the methods for operating the libraries. In the words of Oracle's expert, Dr. Mitchell, "an API consists of a set of names that can be used to access features of the library, together with specified conventions about their use," and an "API specification .. . describes a set of rules that the code implementing the library must follow." Mitchell Copyright Opening Report [Dkt. 341-1] fflf 52, 175. The APIs (including the individual elements of the APIs) are thus uncopyrightable methods of operation. See Lotus Development Corp. v. Borland Int'l, Inc., 49 F.3d 807, 815-16 (1st Cir. 1995), aff'd by an evenly divided court, 516 U.S. 233 (1996) ("We hold that the Lotus menu command hierarchy is an uncopyrightable 'method of operation.' The Lotus menu command hierarchy provides the means by which users control and operate Lotus 1-2-3." (emphasis added)).
The Court has asked "whether or not the copyrightability of the selection, arrangement, and structure of the APIs depend on the underlying programming language being Java as opposed to Python or QBASIC or other non-Java programming language." Order Requesting Discussion in Copyright Briefs [Dkt. 754] at 1. It does not. In offering the opinions quoted
5
above, Dr. Mitchell was explaining what APIs are generally, and did not limit his description to the Java language APIs. Similarly, in Lotus, which did not involve the Java language, "Borland did not copy any of Lotus's underlying computer code; it copied only the words and structure of Lotus's menu command hierarchy." 49 F.3d at 810. "As the Lotus menu command hierarchy serves as the basis for Lotus 1-2-3 macros, the Lotus menu command hierarchy is a 'method of operation.'" Id. at 818 (emphasis added). As with the unprotectable Lotus menu hierarchy (which functioned as an API for a macro programming language), APIs in any programming language serve as the means for accessing and controlling the code in the associated libraries.
The Ninth Circuit has held that 17 U.S.C. § 102(b) precludes copyright protection for "functional requirements for compatibility." Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992) (citing 17 U.S.C. § 102(b)).7 The selection, arrangement and structure upon which Oracle relies to prove infringement are functional requirements for compatibility with code that uses the Java language APIs. Even according to Oracle's expert, in order to be compatible with the 37 Oracle API package specifications at issue, Google had to ensure that the Android libraries that implemented those specifications used the same "set of names" and the same "specified conventions" for their use, and that the packages followed the "set of rules" described in the specifications. Mitchell Copyright Opening Report [Dkt. 341-1] ff 52, 175. Oracle's expert thus confirmed that the APIs at issue—and, necessarily, the selection, arrangement and structure of the API elements described in the API specifications—are excluded from copyright protection by 17 U.S.C. § 102(b).
Because all API specifications, by design, describe precisely the elements of APIs that are needed for compatibility between implementations of the APIs, and with programs that use the APIs, Sega applies to APIs regardless of the programming language. As Oracle's expert has
6
explained, APIs provide the "rules" that must be followed when implementing the specifications. Thus, because functional requirements for compatibility are not copyrightable, Sega, 977 F.2d at 1522, APIs are not copyrightable, regardless of the programming language.
Google does not believe there are any facts material to copyrightability that truly can be disputed. To the extent the Court must resolve any subsidiary fact questions to decide whether the APIs are copyrightable subject matter, however, Oracle bears the burden of proof. A copyright plaintiff "must show that he or she owns the copyright and that defendant copied protected elements of the work." Jada Toys, Inc. v. Mattel, Inc., 518F.3d628, 636 (9th Cir. 2008) (quotation marks and citation omitted, and emphasis added). Because Oracle bears the burden of proving that protected elements were copied, it necessarily bears the burden of proving the elements are copyrightable and thus protected.
2. Alternatively, the selection, arrangement and structure of the APIs
are unprotected scenes a faire.
"Under the scenes a faire doctrine, when certain commonplace expressions are indispensable and naturally associated with the treatment of a given idea, those expressions are treated like ideas and therefore not protected by copyright." Swirsky v. Carey, 376 F.3d 841, 850 (9th Cir. 2004). In the computer context, this includes situations where
a programmer's freedom of design choice is . . . circumscribed by extrinsic
considerations such as (1) the mechanical specifications of the computer on which
a particular program is intended to run; (2) compatibility requirements of other
programs with which a program is designed to operate in conjunction;
(3) computer manufacturers' design standards; (4) demands of the industry being
serviced; and (5) widely accepted programming practices within the computer
industry.
Computer Assocs. Int'l, Inc. v. Altai, 982 F.2d 693, 709-10 (2d Cir. 1992) (emphasis added).
Here, Google had to use the same selection, arrangement and structure of API elements in the 37 API package specifications to ensure compatibility with the APIs described in those specifications (Computer Assocs. point 2); to meet demands of the Java language programming community (Computer Assocs. point 4); and to comply with accepted Java language programming practices (Computer Assocs. point 5).
Oracle's expert essentially concedes these points. As discussed above, he has opined that
7
the specifications provide the "rules" that implementations of those specifications "must"follow. And although Dr. Mitchell argues that Google did not need to implement the APIs, he does not that Java language programmers expect to be able to use the APIs, and that it is accepted practice to use the APIs when programming in the Java language. Indeed, Dr. Mitchell claims that if Google had not adopted the Java APIs, it would have "went to market with an unfamiliar application development environment. . . ." Mitchell Copyright Opp. Report [Dkt. 341-2] ¶ 60. Dr. Mitchell even suggests that Java programmers "may want and expect" Java APIs in addition to the ones that Google implemented. Id. at 107. Industry demand and accepted programming practices are also evidenced by the fact that two other major independent and open source Java library implementations (Apache Harmony and GNU Classpath) include implementations of all 37 of the API package specifications at issue, and have done so openly for years.8
But according to Oracle, the constraints that Google faced when designing Android are irrelevant. Oracle urges the Court to look only at the constraints Sun may have faced at the time the APIs were designed. Copyright MS J Opp. [Dkt. 339] at 16 (citing Control Data Sys., Inc. v. Infoware, Inc., 903 F. Supp. 1316, 1323 (D. Minn. 1995)). The Ninth Circuit, however, has held that when "specific [computer] instructions, 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." Sega, 977 F.2d at 1524 (quotation marks and citation omitted, and emphasis added). While the Ninth Circuit did not specifically identify the legal doctrine on which it was relying, the result is that APIs are not copyrightable.9
Similarly, in Baystate Techs v. Bentley Sys., the court explained that "[u]nder the scenes a faire doctrine, protection is denied to those elements of a program that have been dictated by external factors." 946 F. Supp. 1079, 1088 (D. Mass. 1996) (citing Gates Rubber Co. v. Bando
8
Chemical Industries, Ltd., 9 F3d 823 , 838 (10th Cir. 1993)). The Baystate court concluded that the selection and organization that the defendant had copied was dictated by external factors:
The product being developed is a data translator that is designed to "read" the data files of CADKEY. The process of "reading" the CADKEY data files requires that the elements contained within the data structures of the Translator be organized in the same manner as the elements in the data structures of CADKEY. Without such compatibility, the Translator would not function because it would "misread" the CADKEY data files.
946 F. Supp. at 1088. That the plaintiff could have chosen a different selection and organization for the elements of the CADKEY data files did not keep the district court from concluding that the scenes a faire doctrine precluded copyrightability. See id.
These principles apply to any set of APIs that is considered standard by that language's developer community. Such APIs are unprotectable scenes a faire because, regardless of the language, the APIs represent standard tools learned and then used by that particular developer community. See Sega, 977 F.2d at 1524; Computer Assocs., 982 F.2d at 709-10.
Finally, although Google has the burden of raising the doctrine of scenes a faire, Sega demonstrates that Oracle has the ultimate burden of persuasion. In Sega, the Ninth Circuit held there was no infringement by relying on the absence of evidence showing alternatives to the defendant's copying of a twenty to twenty-five byte segment of the plaintiffs software. 977 F.2d at 1524 n.7. If the defendant had the burden of proof, that lack of evidence could not have cut against the plaintiffs position. Implicitly, then, the Ninth Circuit held that the plaintiff has the burden of proof. This is consistent with the court's statement, in Jada Toys, that the plaintiff has the burden of proving that protected elements have been copied. 518 F.3d at 636.
3. Alternatively, any expression in the selection, arrangement and
structure of the APIs has merged with the underlying ideas.
The merger doctrine is closely related to the doctrine of scenes a faire. When an idea "can only be expressed in so many ways," the expression has "merged" with the idea. Apple, 35 F.3d at 1444. In such a situation, "even verbatim reproduction of a factual work may not constitute infringement." Allen v. Academic Games League of Am., Inc., 89 F.3d 614, 617-18 (9th Cir. 1996).10
9
In Allen the 9th Circuit noted that the doctrine of merger is "particularly applicable with respect to games" because they "consist of abstract rules and play ideas." 89 F.2d at 617-18 (quotation marks and citation omitted). The same principle applies here, where the Court has already noted that an API is "the abstract concept of an interface between programs." Copyright MSJ Order [Dkt. 433 at 10]. "In order not to confer a monopoly of the idea upon the copyright owner, such expression should not be protected." Computer Assocs., 982 F.2d at 708 (citing Herbert Rosenthal Jewelry Corp. v. Kalpakian, 446 F.2d 738, 742 (9th Cir. 1971)).
The Allen court held that the plaintiff had "not shown that it is possible to distinguish the expression of the rules of his game manuals from the idea of the rules themselves." 89 F.3d at 618. Here, the selection, arrangement and structure of the APIs are, according to Oracle's own expert, "rules" that must be followed by implementing libraries. Mitchell Copyright Opening Report [Dkt. 341-1] f| 52, 175. This result does not depend on the Java programming language in particular, but is true for APIs generally.
And, as with scenes a faire, Oracle bears the burden of persuasion. In Allen, the Ninth Circuit affirmed the district court's grant of summary judgment because "Allen has not shown that it is possible to distinguish the expression of the rules of his game manuals from the idea of the rules themselves." 89F.3dat618. A mere failure of proof would not support summary judgment for the defendant unless the plaintiff had the burden of proof.
B. The Court must decide whether the standard of substantial similarity or
virtual identity applies to Oracle's Specifications Claims.
Choosing between the substantial similarity and virtual identity standards is an issue for the Court. See Apple, 35 F.3d at 1443 ("Depending on the degree of protection, the court must set the appropriate standard for a subjective comparison of the works to determine whether, as a whole, they are sufficiently similar to support a finding of illicit copying."). If the Court concludes that the range of protectable expression is narrow, the standard for copying is not just substantial similarity but virtual identity. See id. at 1446; see also Satava v. Lowry, 323 F.3d
10
805, 812 (9th Cir. 2003). ("Satava posses a thin copyright that protects against only virtually identical copying."); Ets-Hokin v. Skyy Spirits, Inc. 323 F.3d 763, 766 (9th Cir. 2003)("When we apply the limiting doctrines, subtracting the original elements, Ets-Hokin is left with only a "thin" copyright, which protects against only virtually identical copying.")
Once the Court resolves the copyrightability issue, Google believes that it will be entitled to a judgment as a matter of law of noninfringement.11 If, however, the Court concludes that the infringement question should be sent to the jury, Google believes that the virtual identity standard should apply. Whichever standard applies, Oracle bears the burden of proof. E.g., Brown Bag Software v. Symantec Corp., 960 F.2d 1465, 1472 (9th Cir. 1992).
C. To the extent there are material disputed facts, the jury must decide whether Google's use is a fair use.
Although fair use can be decided by the Court if the relevant facts are undisputed, see, e.g., Kelly v. Arriba Soft Corp., 336 F.3d 811, 817-22 (9th Cir. 2003), fair use is a jury issue where there are material disputes of fact. The Copyright Act lists several non-exhaustive factors to be considered in determining whether a use is fair: "(1) the purpose and character of the use, including whether such use is of a commercial nature or is for non-profit educational purposes; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and (4) the effect of the use upon the potential market for or value of the copyrighted work." 17 U.S.C. § 107.
"The four factors are to be considered together in light of the purposes of copyright, not in isolation." Sony v. Bleem, 214 F.3d 1022, 1026 (9th Cir. 2000) (citation omitted). Copyright's "very purpose" is '"[t]o promote the Progress of Science and useful Arts. . . .'" Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569, 575 (1994) (quoting U.S. Const, Art. I, § 8, cl. 8).
With respect to the first factor, the Supreme Court has explained that
The central purpose of the investigation is to see, in Justice Story's words, whether the new work merely "supersede[s] the objects" of the original creation, or instead adds something new, with a further purpose or different character,
11
altering the first with new expression, meaning, or message: it asks, in other words, whether and to what extent the new work is "transformative."
Campbell, 510 U.S. at 579 (citations omitted).
According to the Ninth Circuit,
The second statutory factor , the nature of the copyrighted work, reflects the fact that not all copyrighted works are entitled to the same level of protection. The protection established by the Copyright Act for original works of authorship does
not extend to the ideas underlying a work or to the functional or factual aspects of the work. 17 U.S.C. § 102(b). To the extent that a work is functional or factual, it may be copied, Baker v. Selden, 101 U.S. (11 Otto) 99, 102-04, 25L£d 841 (1879), as may those expressive elements of the work that "must necessarily be used as incident to" expression of the underlying ideas, functional concepts, or facts, id. at 104. Works of fiction receive greater protection than . . . works that have strong functional elements, such as accounting textbooks, Baker, 101 U.S. at 104.
Sega, 977F.2d at l524.
With respect to the third factor, "[i]f the secondary user only copies as much as is necessary for his or her intended use, then this factor will not weigh against him or her." Kelly v. Arriba Soft Corp., 336 F.3d 811, 820-21 (9th Cir. 2003).
Finally, although the fourth factor considers market harm, not all "harms" are cognizable. In Sony Comp. Ent't, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000), the Ninth Circuit explained, for example, that "an attempt to monopolize the market by making it impossible for others to compete runs counter to the statutory purpose of promoting creative expression and cannot constitute a strong equitable basis for resisting the invocation of the fair use doctrine." Id. at 607-08 (citing Sega, 977 F.2d at 1523-24). In particular, a transformative use that "does not merely supplant" the original work can render the secondary user a "legitimate competitor," in which case "some economic loss ... does not compel a finding of no fair use." Id. at 607.
Weighing these factors together, the evidence will show that Google's use is a fair use. See Google's Copyright MSJ [Dkt. 260] at 19-22; Copyright MSJ Reply [Dkt. 368] at 9-10.
IV. THE DERIVATIVE WORK CLAIMS
Oracle also claims that the source code implementation of the Android core libraries is a derivative work, because it allegedly is "derived" from Oracle's specifications. Oracle's argument is breathtaking. If Oracle is correct, any implementation of any API specification is a derivative work, because as Oracle's expert concedes, implementing the APIs requires following
12
the "rules" described in the specifications. Mitchell Copyright Opening Report [Dkt. 341-1] ¶¶ 52, 175. Thus, although the Ninth Circuit ha held that "functional requirements cor compatibility" are not copyrightable, Sega, 977 F.2d at 1522, following functional requirements for compatibility-according to Oracle-leads directly to infringement.
Regardless, material only qualifies as an ulawful derivative work if derived from material that is itself infringing.12 Thus, if the Specifications Claims fail, then the source code implementation of the Android core libraries is not a derivative work. The legal issues relevant to the Specifications Claims are therefore also relevant to the Derivative Work Claims.
V. THE FILE CLAIMS
A. The Court should hold that the File Claims are moot.
The Court should hold that the File Claims are moot, and thus that there is no need to present them to the jury. As the Court has noted, Oracle's damages expert performed no analysis of damages caused by the alleged copying of portions of the 11 Oracle files. Order re Google's MIL No. 3 [Dkt. 685] at 10. Indeed, Oracle has never articulated any damages theory based on the File Claims. Moreover, the allegedly copied portions of these files have all been removed from Android. Thus, there is no basis or need for injunctive relief.
Because Oracle is entitled neither to damages nor equitable relief with respect to the File Claims, a verdict in Oracle's favor would not redress any alleged harm arising from the File Claims. On these facts, Oracle's File Claims are moot. See Lujan v. Defenders of Wildlife, 504 U.S. 555, 560-61 (1992) ("the irreducible constitutional minimum of standing contains three elements," the third of which is redressibility).
B. If the File Claims are not moot, the Court should determine the relevant
"work as a whole," and the jury should decide whether the alleged
infringement was de minimis.
If, however, the File Claims are tried, the jury will need to decide whether any alleged copying in the 12 Android files is de minimis. De minimis acts of copying are not actionable.
13
Newton v. Diamond, 388 F.3d 1189, 1192-93 (9th Cir. 2004). Where the only similarity is as to "nonessential matters," the copying is de minimis. See id. at 1195 (quoting 4 Nimmer on Copyright § 1303[A][2], at 13-48). Where a defendant copies only "a portion of the plaintiff's work exactly or nearly exactly ... the dispostive question is whether the copying goes to trivial or substantial elements." Id. That substantiality is judged by "considering the qualitative and
quantitative significance of the copied portion in relation to the plaintiffs work as a whole." Id. (emphasis added); see also Computer Assoc., 982 F.2d 693 at 714-15. Oracle bears the burden of proving the significance of any copied code. MiTek Holdings, Inc. v. ArcE Eng'g Co., 89 F.3d 1548, 1560 (11th Cir. 1996) ("The burden is on the copyright owner to demonstrate the significance of the copied features, and, in this case, MiTek has failed to meet that burden.").
To instruct the jury, the Court will need to determine what the relevant "work as a whole" is. Google contends that the relevant "work as a whole" is J2SE, the works that Oracle registered with the Copyright Office. Oracle, in contrast, has previously argued that the allegedly copied material in each of the 12 Android files must be compared to the individual file from which the material allegedly was taken. Oracle's Opp. to Copyright MSJ [Dkt. 339] at 23.
The Court has not yet decided this issue. See Copyright MSJ Order [Dkt. 433] at 6-7. To the extent that the Court concludes that an individual Oracle code file could ever be the "work as a whole" for purposes of the de minimis analysis, Oracle has the burden of proving, at a minimum, that the individual files have "independent economic value." Tattoo Art, Inc. v. TAT Int'l, LLC, 794 F. Supp. 2d 634, 652 (E.D. Va. 2011) (quoting Gamma Audio & Video, Inc. v. Ean-Chea, 11 F.3d 1106, 1117 (1st Cir. 1993), and considering what constitutes a "work" for purposes of statutory damages). Google is unaware of any evidence suggesting that the individual code files have any independent economic value.
VI. GOOGLE'S EQUITABLE DEFENSES
The Court should follow its inclination to "ask the jury for an advisory verdict on all equitable defenses." Final Pretrial Order [Dkt. 675] at 2. The evidence will demonstrate that Oracle's claims are barred by Google's defenses of laches, estoppel, waiver and implied license.
As early as 2005, Sun was fully aware of Google's efforts to develop the free, open
14
source, full stack Android mobile operating platform partly written in the Java programming language. Despite this knowledge, Sun never said a cross word to Google when Android was publicly announced in 2007 and then released in late 2008. Certainly Sun never asserted that Android infringed copyright or threatened to sue over it. Sun didn't change its tune until after it changed its name to Oracle America in early 2010, by which time Google and its many partners in the Open Handset Alliance had invested enormous amounts of time, money and sweat in building the Android platform into a commercial success.
These and other similar statements by Sun establish Google's equitable defenses—each premised on the fact that Sun expressly and publicly approved of Android and never suggested it would sue Google. In fact, even before it completed its acquisition of Sun, Oracle applauded the Android platform, announcing in 2009 at the Java One conference that it was "flattered" by Android and further emphasizing that there were likely to be Android netbooks using the Java programming language as a result of the efforts of "our friends at Google." Oracle cannot renege on these representations, claiming entitlement to revenues associated with Android now that Android is a success.
Dated: March 9, 2012
KEKER & VAN NEST LLP
/s/ Robert A. Van Nest
By: ROBERT A. VAN NEST
GOOGLE INC.
15
1 "Libraries" can also be referred to as "packages." The terms have the same meaning.
2 Oracle refers to "[c]opying 12 Java software code files." Id. But two of the Android files allegedly copied the same nine lines from a single Oracle file. Thus, although there are 12 allegedly infringing files, there are only 11 files from which material was allegedly copied.
3 See also Jonathan Browning, Inc. v. Venetian Casino Resort LLC, No. C 07-03983 JSW, 2009 U.S. Dist. LEXIS 57525, at *2 (N.D. Cal. June 18, 2009) ("Determinations of copyrightability are indeed questions of law reserved for the judge, and not the jury.").
4 Oracle has suggested that there are "threshold factual determinations" for the jury. See 10/27/11 Jacobs Ltr. [Dkt. 566] at 3 (citing 3 Melville B. Nimmer & David Nimmer, Nimmer On Copyright § 12.10[B][1], which cites Montgomery v. Noga, 168 F.3d 1282,1291 n.14 (11th Cir. 1999)). Oracle is incorrect. Although there was a jury trial in Montgomery, see 168 F.3d at 1286, the Eleventh Circuit explained that as to copyrightability it was reviewing a factual finding by the district court, and made no reference to any subsidiary fact findings by the jury. Id. at 1291 n. 14. The court expressly noted that it was reviewing the district court's factual findings for clear error, id., which is the standard of review applicable to findings by a court, not a jury. Thus, while the question of infringement was of course submitted to the jury, the threshold legal question of copyrightability was decided by the district court, without the jury being asked to make any subsidiary findings of fact.
5 Harper House, Inc. v. Thomas Nelson, Inc., 889 F.2d 197, 207-08 (9th Cir. 1989) ("Given the extremely limited protection that Harper House's organizers receive, the jury instructions covering copyright infringement liability did not adequately distinguish between protectable and unprotectable material. ... We hold that, viewing the jury instructions as a whole, the trial court's instructions on copyrightability were not adequate to ensure that the jury fully understood the issues, and therefore constituted error requiring a new trial on the liability and damages phase of the infringement claim.").
6 Notably, Oracle's proposed verdict form does not ask the jury to decide any factual questions on which the issue of copyrightability supposedly depends. See Dkt. 531-1. Instead, in its proposed jury instructions, Oracle states that "upon the close of evidence, the Court should instruct the jury as to which works are protected by copyright.. . ." Joint Proposed Jury Instructions [Dkt. 539] at 54. Thus Oracle proposes that the Court decide copyrightability without first having the jury make any threshold factual determinations.
7 Sega is a fair use decision, but its analysis of section 102(b) is not limited to that context. The Ninth Circuit held that Accolade's copying and disassembly of Sega object code was a fair use, because the "disassembly [was] the only means of gaining access to . .. unprotected aspects of the program . . . ." Id. at 1520. The reason the Ninth Circuit so held was because it agreed with Accolade that the disassembly of Sega's code was "necessary in order to gain access to the ideas and functional concepts embodied in the code, which are not protected by copyright." Id. at 1519. The Sega court's ultimate finding of fair use depended on the predicate legal principle that section 102(b) precludes copyright protection for functional requirements for compatibility.
8 At trial, Jonathan Schwartz, who was Sun's CEO when Android was being developed and when it was released, will testify that he was well aware of the Apache Harmony and GNU Classpath API implementations, that Sun never objected to those implementations, and that he believed that widespread use of the APIs was good for Sun.
9 See also Paul Goldstein, Goldstein On Copyright § 2.3.2.1 (3d ed. 2011) (in the Ninth Circuit, "it is the range of expressive choice that existed at the time the competing product was created—not the range of expression that existed at the time the copyrighted work was created-that controls" (emphasis added)).
10
See also Computer Assocs., 982 F.2d at 707 (in analyzing computer programs, "expression necessarily incidental to the idea being expressed" is unprotectable); Gates Rubber, 9 F.3d at 836-38 (software that is "inseparable from or merged with the ideas, processes, or discoveries underlying the expression" is unprotectable to avoid "unwittingly granting] protection to an idea by granting exclusive rights to the only, or one of only a few, means of expressing that idea.").
11 If the Court concludes the selection, arrangement and structure of the API elements is not copyrightable, Oracle may still argue that the narrative descriptions in the Android specifications infringe. Google, however, believes that no reasonable jury could find infringement on that basis, and that it therefore will be entitled to judgment as a matter of law.
12
Mirage Editions v. Albuquerque A.R. T. Co., 856 F.2d 1341, 1343 (9th Cir. 1988) ("a work will be considered a derivative work only if it would be considered an infringing work if the material which it has derived from a preexisting work had been taken without the consent of a copyright proprietor of such preexisting work") (quotation marks and citation omitted).
780
MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
[email]
KENNETH A. KUWAYTI (Bar No. 145384)
[email]
MARC DAVID PETERS (Bar No. 211725)
[email]
DANIEL P. MUINO (Bar No. 209624)
[email address telephone fax]
BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[email address telephone fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email address telephone fax]
ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email address telephone fax]
Attorneys for Plaintiff
ORACLE AMERICA, INC.
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.
Case No. CV 10-03561 WHA
ORACLE’S MARCH 9, 2012 BRIEF
REGARDING COPYRIGHT ISSUES
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup
TABLE OF CONTENTS
|
|
Page |
I. | COPYRIGHTS IN SUIT | 1 |
|
A. | Google copied 37 Java API specifications nearly verbatim into Android |
1 |
|
B. |
Google copied source code, object code and comments from 11 Java code
files into Android |
3 |
II. | ORACLE’S COPYRIGHT LIABILITY CLAIMS |
3 |
| A. | Direct Infringement | 3 |
| | 1. | Ownership |
4 |
| | 2. | Validity of Copyright | 4 |
| | 3. | Copying | 6 |
| | |
a. | Google copied the Java API specifications | 6 |
| | |
b. | Google copied Java Software Code | 7 |
| | 4. | Originality | 8 |
| B. | Indirect Infringement | 9 |
III. | GOOGLE’S AFFIRMATIVE DEFENSES | 10 |
| A. | Elements Are Not Protected By Copyright | 10 |
| | 1. | Merger and Scenes A Faire | 10 |
| | 2. | Other challenges based on functionality | 11 |
| B. | Fair Use | 12 |
| C. | De Minimis Copying | 13 |
| D. | Equitable Defenses | 14 |
IV. | EFFECT OF PROGRAMMING LANGUAGE | 14 |
i
TABLE OF AUTHORITIES
| Pages(s) |
|
Cases | |
|
Bibbero Sys., Inc. v. Colwell Sys., Inc.,
893 F.2d 1104 (9th Cir. 1990) | 4, 11 |
Brocade Commc’ns Sys., Inc. v. A10 Networks, Inc.,
2011 U.S. Dist. LEXIS 91384 (N.D. Cal. Aug. 16, 2011) | 6, 8 |
CDN Inc. v. Kapes
197 F.3d 1256 (9th Cir. 1999) | 9 |
Del Madera Props. v. Rhodes & Gardner, Inc.,
820 F.2d 973 (9th Cir. 1987) | 4 |
Dream Games of Ariz., Inc. v. PC Onsite,
561 F.3d 983 (9th Cir. 2009) | 4 |
Ets-Hokin v. Skyy Spirits, Inc.,
225 F.3d 1068 (9th Cir. 2000) | 5, 8, 10, 11 |
Feist Publ’ns, Inc. v. Rural Tel. Serv. Co.,
499 U.S. 340 (1991) | 9 |
Funky Films, Inc. v. Time Warner Entm’t Co.,
462 F.3d 1072 (9th Cir. 2006) | 3 |
Harper & Row Publishers, Inc. v. Nation Enters.,
471 U.S. 539 (1985) | 12, 13 |
Jacobsen v. Katzer,
2009 U.S. Dist. LEXIS 115204 (N.D. Cal. Dec. 10, 2009) | 8 |
Jartech, Inc. v. Clancy,
666 F.2d 403 (9th Cir. 1982) | 12 |
Johnson Controls, Inc. v. Phoenix Control Sys., Inc.,
886 F.2d 1173 (9th Cir. 1989) | 9, 11 |
Lanard Toys Ltd. v. Novelty, Inc.
375 Fed. Appx. 705 (9th Cir. 2010) | 5, 11 |
Louis Vuitton Malletier, S.A. v. Akanoc Solutions, Inc.,
658 F.3d 936 (9th Cir. 2011) | 9 |
Maljack Prods., Inc. v. UAV Corp.,
964 F. Supp. 1416 (C.D. Cal. 1997) | 5 |
ii
MDY Indus., LLC v. Blizzard Entm’t, Inc.,
2011 U.S. App. LEXIS 3428 (9th Cir. Feb. 17, 2011) | 10 |
Merch. Transaction Sys., Inc. v. Nelcela, Inc.,
2009 U.S. Dist. LEXIS 25663 (D. Ariz. Mar. 17, 2009) | passim |
Newton v. Diamond,
388 F.3d 1189 (9th Cir. 2004) | 13 |
Perfect 10, Inc. v. Amazon.com, Inc.,
508 F.3d 1146 (9th Cir. 2007) | 12 |
Pye v. Mitchell,
574 F.2d 476 (9th Cir. 1978) | 7 |
Range Road Music, Inc. v. East Coast Food, Inc.,
2012 U.S. App. LEXIS 3173 (9th Cir. Feb. 16, 2012) | 6, 13 |
Satava v. Lowry,
323 F.3d 805 (9th Cir. 2003) | 14 |
Swirsky v. Carey,
376 F.3d 841 (9th Cir. 2004) | 8 |
Three Boys Music Corp. v. Bolton,
212 F.3d 477 (9th Cir. 2000) | 6 |
United States v. King Features Entm’t, Inc.,
843 F.2d 394 (9th Cir. 1988) | 14 |
|
STATUTES |
17 U.S.C. |
| § 107(1) | 12 |
| § 410(c) | 4 |
|
OTHER AUTHORITIES |
3-12 Nimmer on Copyright § 12.10[B][1] | 8 |
Bjarne Stroustrup, THE C++ PROGRAMMING LANGUAGE § 16.1 (3d ed. 1997) | 15 |
James Gosling et al., JAVA LANGUAGE SPECIFICATION § 4.3.2 (3d ed. 2005) | 15 |
iii
This brief responds to the Court’s Feb. 1, 2012 Order Regarding Copyright Issues and its
Feb. 29 supplemental order.
I. COPYRIGHTS IN SUIT
The copyrighted works at issue are (a) 37 Java API design specifications and
implementations and (b) 11 Java software code files. Google is liable for copyright infringement
because Google copied from and prepared derivative works from Oracle’s copyrighted materials
to create Android specifications and implementations, which it then distributed.
A. Google copied 37 Java API specifications nearly verbatim into
Android
The 37 Java API specifications at issue are the blueprints for the design of Java core class
libraries. They describe an extraordinarily complex, intricate structure of hierarchy and
interdependency, painstakingly designed by Sun engineers over years of effort. Sun carefully
maintained the copyrighted status of the works at issue in this lawsuit. Google infringed the
copyrighted works in order to attract the 6-million-strong Java developer community, which
enabled Google to capture smartphone market share quickly, advertise thousands of applications
in a robust Android market, and create a loyal customer base.
Google initially copied from the documentation for Java 2 Standard Edition 5.0 (“J2SE
5.0”), and later copied from the updated J2SE 6.0 documentation. Oracle’s copyright in J2SE 5.0
materials was registered with the U.S. Copyright Office under registration numbers TX 6-066-
538 and TX 6-143-306. J2SE 5.0 revised and built upon earlier versions of Java.1
Each of the 37 Java API specifications Google copied defines a package, and has a unique
name, such as “java.nio” or “java.util.” (See Mitchell Opening Rep., ECF No. 397 ¶ 202 (listing
37 API specifications at issue).) Packages may include classes, interfaces, and subpackages. For
each class in a package, the API specification describes the fields and methods within it and
_________________________________________
1 Sun obtained copyright registrations TX0004616088 [1.2 Beta 2]; TX0005359984 [1.2];
TX0005359985 [1.2]; TX0005359986 [1.2]; TX0005359987 [1.2]; TX0005271787 [1.3];
TX0005316757 [1.3]; TX0005316758 [1.3]; TX0005392885 [1.3]; TX0006196514 [1.4]and
TX0006848555 [6.0]. Sun also obtained copyright registrations TX0004326014 on a book
entitled “The Java Application Programming Interface, Volume 1 Core Packages,” which
described an early version of the API specifications.
1
identifies those that are exposed to other classes. (See, e.g., id. ¶ 171; Mitchell Opp. Rep., ECF
No. 397-2 ¶¶ 20-28.) Methods are described by their “method signatures,” which include the
method name and the method parameters and their order, as well as the method return type and
any exception types thrown by the method. Fields are described by their name and type. Field
and method declarations may also include various modifiers that change their behavior,
inheritability, and accessibility. The API specification also describes the relationship of each
class to other classes and packages of classes. The Java API designers who wrote the
specifications decided which packages, classes, Interfaces, methods, and fields to include in the
API specifications, as well as the relationships and interdependencies among the thousands of
individual elements. (See id.) These relationships can be found within a package or may extend
across different packages. This is a vast amount of expression: when printed out, Oracle’s 37 API
specifications are more than 11,000 pages long. (Swoopes Decl., ECF No. 343 ¶ 28.)
Google copied nearly all of that expression verbatim. In the case of the java.util package
alone, Google copied 49 classes, 16 interfaces, 20 exceptions, 85 fields, and 369 methods.
Google also copied the structural relationships among these elements within java.util, as well as
their relationships to the elements of other packages. For example, according to Oracle’s java.util
API specification, the Hashtable class is a subclass of Dictionary, and implements three
interfaces: Serializable, Cloneable, and Map, which are found in the java.lang, java.io, and
java.util packages, respectively. Android’s Hashtable class is likewise a subclass of Dictionary,
and implements the same three interfaces, with the same three names, found in the same three
corresponding Android packages. This organization is hardly preordained, but Google copied it,
just as it did for all the other elements of java.util that it wanted for Android.
The Java API implementations are analogous to a multi-volume history, such as the
Durants’ eleven-volume The Story of Civilization, and the Java API specifications are like the
author’s meticulously detailed outline of those works. It would be copyright infringement for a
second author to take the outline and publish a second multi-volume work containing identical
names for each volume, chapter, and subchapter, identical topics, facts, and primary sources
discussed to the same level of detail, appearing in exactly the same order, and accompanied by
2
identical photographs and drawings, but change the wording of the text. And it would be
copyright infringement for the second author to publish an outline of the second multi-volume
work that matches the original author’s outline almost exactly.
While Google copied far more than the core library names, its copying of the names is
actionable as well. While the Court held individual names are not copyrightable, together the
names copied in this case—at least 5,500—are copyrightable if they are “numerous enough and
their selection and arrangement original enough that their combination constitutes an original
work of authorship.” Merch. Transaction Sys., Inc. v. Nelcela, Inc., 2009 U.S. Dist. LEXIS
25663, at *46 (D. Ariz. Mar. 17, 2009) (claim based on selection and arrangement of field names
in software). The Court has held that Oracle may present at trial a theory of copyright
infringement based on the selection and arrangement of names. (See ECF No. 433 at 8.)
B. Google copied source code, object code and comments from 11 Java
code files into Android
Google also copied 11 of Oracle’s Java software code files into 12 Android code files:
- the entire code for AclEntryImpl.java, AclImpl.java, GroupImpl.java,
OwnerImpl.java, PermissionImpl.java, PrincipalImpl.java, PolicyNodeImpl.java,
and AclEnumerator.java, obtained by decompiling object code for these classes
- code from Arrays.java
- comments from CodeSource.java
- comments from CollectionCertStoreParameters.java
II. ORACLE’S COPYRIGHT LIABILITY CLAIMS
Oracle has asserted two copyright liability theories: (1) direct infringement and (2)
indirect infringement, including vicarious and contributory infringement.
A. Direct Infringement
“A plaintiff bringing a claim for copyright infringement must demonstrate ‘(1) ownership
of a valid copyright, and (2) copying of constituent elements of the work that are original.’”
Funky Films, Inc. v. Time Warner Entm’t Co., 462 F.3d 1072, 1076 (9th Cir. 2006) (quoting Feist
3
Publ’ns, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 361 (1991)). The burdens of proof for these
elements are discussed separately below.
1. Ownership
“A certificate of registration raises the presumption of copyright validity and ownership.”
Dream Games of Ariz., Inc. v. PC Onsite, 561 F.3d 983, 987 n.2 (9th Cir. 2009). As noted above,
Oracle’s copyrights in J2SE 5.0 materials were registered with the U.S. Copyright Office under
registration numbers TX 6-066-538 and TX 6-143-306. J2SE 5.0 was registered as a collective
work, comprising prior works by Sun, licensed-in components, and new and revised computer
code and accompanying documentation and manuals. (See ECF No. 36-8 at 7.) The registration
form lists Sun’s copyright registrations for earlier versions. (See id. at 7-8.) Oracle America, Inc.
is the same corporate entity as Sun, which changed its corporate name after Oracle acquired it.
Thus Oracle America, Inc. is the owner of the registered copyrights in J2SE 5.0 and Sun’s other
registered copyrights covering earlier and later versions of the Java API specifications,
implementations, and other documentation. (See n.1, supra.)
If Google disputes ownership based on the legal interpretation of copyright regulations or
registrations, that interpretation is for the Court to make. If Google is raising a factual challenge
to ownership, such as to authorship, that issue is for the jury to decide. See, e.g., Del Madera
Props. v. Rhodes & Gardner, Inc., 820 F.2d 973, 980 (9th Cir. 1987) (“The question of
authorship of a copyrighted work is a question of fact for the jury.”).
2. Validity of Copyright
The parties agree that the Court decides copyrightability. (ECF No. 525 at 10.)
A “certificate of copyright registration constitutes prima facie evidence of copyrightability
and shifts the burden to the defendant to demonstrate why the copyright is not valid.” Bibbero
Sys., Inc. v. Colwell Sys., Inc., 893 F.2d 1104, 1106 (9th Cir. 1990); see also 17 U.S.C. § 410(c)
(“In any judicial proceedings the certificate of a registration made before or within five years after
first publication of the work shall constitute prima facie evidence of the validity of the copyright
and of the facts stated in the certificate.”).
4
The presumption that a work is entitled to copyright protection also extends to constituent
elements of the work. The presumption can be rebutted.
In Lanard Toys Ltd. v. Novelty, Inc., the Ninth Circuit approved use of a jury instruction
requiring defendants to prove elements were not subject to copyright protection:
As Nimmer explains, “[U]nlike a patent claim, a claim to copyright is not
examined for basic validity before a certificate is issued. ... There is one important
respect, however, in which the Copyright Office does perform a substantive
examination within its particular expertise to determine validity: whether the work
falls within the subject matter of copyright. The Office will register only works as
to which, ‘after examination,’ it determines that ‘the material deposited constitutes
copyrightable subject matter...’” 3-12 Nimmer § 12.11[B][3] (citing 17 U.S.C. §
410(a)). Accordingly, the district court did not err by instructing the jury that
appellants bore the burden of proving that any functional elements of Lanard's
toys were not subject to copyright protection, and that any similarity between their
products and Lanard's works were limited to such functional elements.
375 Fed. Appx. 705, 711 (9th Cir. 2010) (omission in original and emphasis added); see also
Maljack Prods., Inc. v. UAV Corp., 964 F. Supp. 1416, 1426 (C.D. Cal. 1997) (“The burden of
proving invalidity lies with the party making the invalidity claim”).
Other courts, however, have characterized the burden as one to come forward with
evidence: “‘To rebut the presumption, an infringement defendant must simply offer some
evidence or proof to dispute or deny the plaintiff’s prima facie case of infringement.’” Ets-Hokin
v. Skyy Spirits, Inc., 225 F.3d 1068, 1076 (9th Cir. 2000) (citation omitted). Ets-Hokin sums up
the burden with respect to a photograph this way: “In short, to overcome the presumption of
validity, defendants must demonstrate why the photographs are not copyrightable.” Id.
The Court should follow Lanard Toys and hold that Google has the burden of proving that
the elements it copied are not subject to copyright protection. But regardless of how it is
articulated, Google’s burden extends to each feature Google copied. As Judge Murguia held in
Merchant Transaction Systems v. Nelcela:
Th[e] presumption extends to the Court’s use of analytic dissection under the
extrinsic test to determine whether any of the allegedly similar features are
protected by copyright. See Apple Computer, 35 F.3d at 1443. Because Lexcel
satisfied its prima facie burden and was determined to possess a valid copyright,
Lexcel is entitled to a presumption that the common features and elements in the
Lexcel and Nelcela software are copyrightable. See Swirsky, 376 F.3d at 851. As
such, contrary to Nelcela’s assertion that “it is Lexcel’s burden to prove the
significance of the elements copied” (Dkt. # 603, p.4), the burden in fact shifts to
5
Nelcela to demonstrate why those common features and elements are not protected
by copyright.
2009 U.S. Dist. LEXIS 25663, at *26-27 (citing Bibbero, 893 F.2d at 1106); see also Brocade
Commc’ns Sys., Inc. v. A10 Networks, Inc., 2011 U.S. Dist. LEXIS 91384, at *7 (N.D. Cal. Aug.
16, 2011) (“[I]t is also true that if Brocade registered its software within 5 years of publication,
this entitles Brocade to a presumption of validity, and shifts the burden to A10 to rebut that the
allegedly copied elements are not protectable expression.”) (citing Merch. Transaction).
3. Copying
Copying is an issue of fact for the jury, and Oracle bears the burden of proof. See Three
Boys Music Corp. v. Bolton, 212 F.3d 477, 481-82 (9th Cir. 2000). Oracle can fulfill this burden
with evidence of direct copying or by showing that Google had access to the copyrighted work
and that there is a substantial similarity between the copyrighted and infringing works. Id. at 481.
The Ninth Circuit has held there is no need to prove similarity if direct copying is shown:
“Substantial similarity” is not an element of a claim of copyright infringement.
Rather, it is a doctrine that helps courts adjudicate whether copying of the
“constituent elements of the work that are original” actually occurred when an
allegedly infringing work appropriates elements of an original without reproducing
it in toto.
Range Road Music, Inc. v. East Coast Food, Inc., 2012 U.S. App. LEXIS 3173, at *10 (9th Cir.
Feb. 16, 2012). Here, there is substantial evidence proving copying under either theory.
a. Google copied the Java API specifications
Google copied the designs expressed in the Java API specifications, which include
thousands of elements and the relationships among them, essentially in their entirety. Google
does not deny that this copying took place. To the contrary, its expert, Owen Astrachan,
acknowledges that Google copied the API specifications deliberately, opining that “Even the
slightest changes to the names or organization of API elements will thwart compatibility and
interoperability, because existing code that used those elements would not run properly, and
programmers would have to learn new API element names.” (Astrachan Opening Rep., ECF No.
262-1 ¶ 131). This is sufficient to satisfy Oracle’s burden to show copying under Range Road
Music, supra. It is no defense for Google to claim it copied from a third party. A defendant is
6
liable when it copies from a third party, with or without a license. Pye v. Mitchell, 574 F.2d 476,
481 (9th Cir. 1978).
While Oracle is not required to also prove copying through access and substantial
similarity, it can do so. The Java API specifications were available on the Sun (now Oracle)
website, subject to explicit copyright protection, and Google admits Android developers had
access to them. (Google Resp. to RFA No. 168.) Bob Lee, the lead developer for the Android
core libraries, testified that Google worked to “implement core libraries according to Java APIs.”
(Lee Dep. 14:7-11 (emphasis added).) Mr. Lee “consulted Sun’s website for the API
specifications when doing the work for Google.” (Id. at 66:7-9.) He did so knowing that the
specifications were subject to a copyright notice. (Id. at 65:8-67:5.)
There is no real question of substantial similarity. (See, e.g., Mitchell Opening Rep. Ex.
Copyright A-D, ECF No. 397 at 124-160 (comparing specifications).) On summary judgment,
the Court ruled as to the API specifications that “Because Google has not proven that a
substantial portion of the specifications is unprotected, Google’s justification for applying the
virtual identity standard fails.” (ECF No. 433 at 11.) Google will not be able to prove so at trial
either. However, Oracle could satisfy a virtual identity standard as well.
b. Google copied Java Software Code
Oracle will show that Google copied source code, object code, and comments from 11
Java software code files. Google’s expert has not denied this copying, but only denies its
significance. (See Astrachan Opening Rep., ECF No. 262-1 ¶¶ 145-175.) Again, evidence of this
direct copying satisfies Range Road Music, but Oracle can show access and similarity as well.
Google engineer Josh Bloch, formerly of Sun, conceded that there “is a strong indication that it is
likely” that he accessed the Oracle source code for the method called “rangeCheck” when he
wrote the same method in Android. (Bloch Dep. 181:7-14.) And the evidence shows Google
decompiled Java object code, which can be retrieved from most desktops or many other places
Java is available. A side-by-side comparison of the copied code and comments shows they are
virtually identical. (See Mitchell Opening Rep., ECF No. 397 ¶¶ 77, 206-26.)
7
4. Originality
Google’s challenge to originality is a question for the Court to decide. See 3-12 Nimmer
on Copyright § 12.10[B][1]. But threshold determinations of fact are for the jury. Id. When
there are no genuine issues of fact, as is the case here, originality may be resolved as a matter of
law. Jacobsen v. Katzer, 2009 U.S. Dist. LEXIS 115204, at *9-10 (N.D. Cal. Dec. 10, 2009).
The Court denied Oracle’s request to file a summary judgment motion on the issue of
originality of selection and arrangement of names of APIs, stating that “The judge will understand
the complications of the issues much better after the detailed trial evidence is laid out and crossexamined.
It would be hard for the judge to master the material with the same grasp via a cold
written record.” (ECF No. 584.) Accordingly, the Court should decide the originality issue on a
full record, after hearing fact and expert witness testimony regarding the API design, and should
instruct the jury on this issue. While the Court may determine it wishes to submit a threshold
issue of fact to the jury, Oracle does not believe that will be necessary.
Because its copyrights were timely registered, Oracle is entitled to a presumption of
originality as to the copied elements, and the burden shifts to Google to demonstrate why they are
not original. See, e.g., Ets-Hokin, 225 F.3d at 1075-76 (“In short, to overcome the presumption of
validity, defendants must demonstrate why the photographs are not copyrightable.”). Moreover, a
copyright registration creates a presumption of originality as to the specific elements of a
registered work. See, e.g., Swirsky v. Carey, 376 F.3d 841, 851 (9th Cir. 2004) (valid registration
certificate entitled plaintiff to presumption of originality “as to first measure of chorus” of song);
Merch. Transaction, 2009 U.S. Dist. LEXIS 25663, at *26-27 (registration shifts burden to
defendant “to demonstrate why those common features and elements are not protected by
copyright”); Brocade, 2011 U.S. Dist. LEXIS 91384, at *7 (registration shifts burden to
defendant “to rebut that the allegedly copied elements are not protectable expression”). Google’s
burden is a difficult one to meet, in part because there is only a minimal degree of originality
required. In ruling on summary judgment on the copyrightability of individual names, the Court
stated that Oracle had not shown that it was entitled to a presumption of originality because it
cited “no authority requiring a presumption of originality as to specific elements of a registered
8
work.” (ECF No. 433 at 8 (emphasis in original).) Based on the authority cited immediately
above, however, the presumption should be applied at trial.
Regardless, the legal threshold for originality is low: “To be sure, the requisite level of
creativity is extremely low; even a slight amount will suffice.” Feist, 499 U.S. at 345 (citation
omitted). In CDN Inc. v. Kapes, for example, the Ninth Circuit found that prices in a guide for
collectible coins were protected by copyright, emphasizing that the required level of originality is
“minimal.” 197 F.3d 1256, 1262 (9th Cir. 1999). The court explained that the white pages phone
listings in Feist “did not qualify because they fell into the ‘narrow category of works in which the
creative spark is utterly lacking or so trivial as to be virtually nonexistent.” Id. at 1259-60
(quoting Feist, 499 U.S. at 359).
The API specifications express a highly creative, complex interplay of elements. Oracle
will present evidence at trial about the many design choices involved in creating the Java APIs,
their uniqueness, and the skill required to write them. Google’s own employees have extolled the
creative expression in a well-constructed API. For example, former Sun engineer and current
Google employee Josh Bloch testified that a good API will “read like prose” and wrote that “API
design is a noble and rewarding craft.” (Bloch Dep. 81:13-82:7, 90:8-91:11.) No court has ever
held that a structure with the level of expression, intricacy, complexity and interdependency
present here lacks the creativity to qualify for copyright protection.
Google cannot mount a serious challenge to the originality of code it literally copied
either. Indeed, its only defense is that its copying was minimal. “Source and object code, the
literal components of a program, are consistently held protected by a copyright on the program.”
Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989).
B. Indirect Infringement
Oracle has claims against Google for both contributory and vicarious infringement.
To establish contributory infringement Oracle must show: (1) Google knew or had reason
to know of the infringing activity of others; and (2) Google intentionally or materially contributed
to the infringing activity. Louis Vuitton Malletier, S.A. v. Akanoc Solutions, Inc., 658 F.3d 936,
943-44 (9th Cir. 2011). Intent to infringe is not required. Id. at 943.
9
To establish vicarious infringement, Oracle must show that: (1) Google profited directly
from the infringing activity of others; (2) Google had the right and ability to supervise and control
the infringing activity; and (3) Google failed to exercise that right and ability. MDY Indus., LLC
v. Blizzard Entm’t, Inc., 2011 U.S. App. LEXIS 3428, at *10 (9th Cir. Feb. 17, 2011).
The evidence will show Google requires mobile manufacturers to include the 37
infringing API implementations on their devices as part of its licensing terms, and has profited
handsomely from the infringing activity. Google also knowingly included the infringing
rangeCheck code on Android handsets, where it remains to this day. Google has the ability to
force updates to code on existing handsets remotely, but has not done so. Google published the
other 10 files containing copied code and comments on its Android developer website, but took
them down after it was caught.
III. GOOGLE’S AFFIRMATIVE DEFENSES
A. Elements Are Not Protected By Copyright
Google’s answer incorporates several different arguments under this general heading.
(See ECF No. 51 at 10-11.)
1. Merger and Scenes A Faire
In the Ninth Circuit, merger and scenes a faire are both viewed as defenses to a claim of
infringement, rather than challenges to copyrightability. See Ets-Hokin, 225 F. 3d at 1082.
Google accordingly has the burden of proof. Merch. Transaction, 2009 U.S. Dist. LEXIS 25663,
at *27-28.
In ruling on summary judgment, the Court rejected Google’s attempt to claim that entire
categories of elements in the APIs were unprotectable, stating that, “This order declines to hold
that API package specifications, or any particular category of elements they contain, are
unprotectable under the scenes a faire or merger doctrines.” (ECF No. 433 at 9.) The Court ruled
that, “If Google believes, for example, that a particular method declaration is a scene a faire or is
the only possible way to express a given function, then Google should provide evidence and
argument supporting its views as to that method declaration.” (Id.)
10
Merger and scenes a faire are issues for the Court to decide. Ets-Hokin, 225 F.3d at 1082.
But these fact intensive questions will require examination of a full record at trial. The Court
may wish to seek an advisory verdict from the jury on the underlying factual question of whether
a challenged element is “the only possible way to express a given function” (ECF No. 433 at 9) or
a “commonplace expression[] that [is] indispensable and naturally associated with the treatment
of a given idea.” (Id. at 8 (quoting Swirsky v. Carey, 376 F.3d at 850).)
2. Other challenges based on functionality
Google generally alleges as its affirmative defense that the copyrights at issue are not
protectable because they are works that are “functional.” (ECF No. 51 at 10.) It has framed this
argument in various ways throughout the case, claiming that the APIs are unprotectable “methods
of operation” or “functional requirements for compatibility.” The parties agree that
copyrightability is an issue of law to be addressed by the Court. (ECF No. 525 at 10.)
The Court should follow the Ninth Circuit’s decision in Lanard Toys and hold that Google
has the burden of proving the allegedly functional elements it copied are not subject to copyright
protection. Lanard Toys, 375 Fed. Appx. at 711. Oracle’s registration certificates create a
rebuttable presumption that shifts the burden to Google to demonstrate why Oracle’s copyrights
as to the API specifications are invalid. Bibbero, 893 F.2d at 1106.
Merely labeling something “functional” or a “method of operation” does not decide the
issue of copyrightability. All computer programs are functional. “Whether the non-literal
components of a program, including the structure, sequence and organization and user interface,
are protected depends on whether, on the particular facts of each case, the component in question
qualifies as the expression of an idea, or an idea itself.” Johnson Controls, 886 F.2d at 1175. To
establish that an element is disqualified from copyright protection because of functionality,
Google should be required to satisfy the merger doctrine’s requirement that it is “the only
possible way to express a given function.” (See ECF No. 433 at 9 (citing Satava v. Lowry, 323
F.3d 805, 812 n.5 (9th Cir. 2003).)
The Court has already rejected Google’s argument that the API specifications are
“methods of operation.” (Id. at 11.) As discussed in Oracle’s opposition to summary judgment,
11
Google’s method of operation argument relies on Lotus v. Borland, which is factually
distinguishable because it related to a much simpler consumer user menu. Just as importantly,
Lotus has never been followed in the Ninth Circuit, and other Circuit courts have expressly
refused to adopt its reasoning. (See ECF No. 339 at 9-12.)
Google’s tautological claim that it copied “functional requirements for compatibility” ―
by which it means it copied in order to be compatible with those features of Java it wished to
copy ― should be evaluated as part of Google’s fair use defense, discussed below.
B. Fair Use
The parties agree that the jury should decide Google’s fair use defense. (ECF No. 525 at
15.) See, e.g., Jartech, Inc. v. Clancy, 666 F.2d 403, 405, 407 (9th Cir. 1982) (upholding special
jury verdict finding that defendants’ use of films was fair use). Google bears the burden of
proving fair use. Perfect 10, Inc. v. Amazon.com, Inc., 508 F.3d 1146, 1158 (9th Cir. 2007).
The Court previously rejected Google’s efforts to determine fair use as a matter of law,
finding that “fact issues preclude a summary judgment finding.” (ECF No. 433 at 13.) Google
must therefore present its defense of fair use to the jury. However, Oracle believes a directed
verdict in its favor is appropriate because Google cannot meet its burden of proof.
In determining whether a use is fair, 17 U.S.C. § 107 sets out four factors to consider,
although other factors may be considered as well:
(1) Purpose and character of use – This expressly includes “whether such use is of a
commercial nature or is for nonprofit educational purposes.” 17 U.S.C. § 107(1). Google’s use is
clearly commercial, which “tends to weigh against a finding of fair use.” Harper & Row
Publishers, Inc. v. Nation Enters., 471 U.S. 539, 562 (1985). The Supreme Court held that
“[a]lso relevant to the ‘character’ of the use is ‘the propriety of the defendant’s conduct.’” Id.
(quoting 3 Nimmer on Copyright § 13.05[A], at 13-72). Google’s decision to push forward with
Android without a license, when it knew one was required, weighs strongly against fair use.
(2) Nature of the copyrighted work – The Java APIs are highly creative works, as
discussed above. (See, e.g., Astrachan Dep. 128:9-13 (“Just as it’s hard to find people that are
really good at anything that’s hard, whether it be, you know, being an artist, a football player, a
12
concert violinist. Those things are hard. This [API design] is something that’s hard in the same
way.”); see also evidence discussed at section I.A, supra.)
(3) Amount and substantiality of the work used – This inquiry includes both qualitative
and quantitative evaluations. In Harper, the Supreme Court found that copying even 300 words
from Gerald Ford’s unpublished manuscript was not fair use because of the “qualitative nature of
the taking.” 471 U.S. at 545, 564-65. Google copied from the core Java API specifications —
about one-quarter of the Java APIs in total — and will not be able to establish that its copying
was quantitatively or qualitatively insignificant.
(4) Effect of the Use on the Market for or Value of the Copyrighted Work – The
Supreme Court has stated that “This last factor is undoubtedly the single most important element
of fair use.” Id. at 566-67 (citation omitted). Google’s copying has dramatically impaired the
market and value of Java, by creating a free competing platform in the mobile device arena, and
by fragmenting Java and undermining its “write once, run anywhere” promise.
C. De Minimis Copying
Google asserts its literal copying of Oracle source code and comments is not actionable
because it is de minimis. “[A] use is de minimis only if the average audience would not recognize
the appropriation.” Newton v. Diamond, 388 F.3d 1189, 1193 (9th Cir. 2004). Whether the
“average audience” would recognize Google’s copying is a jury issue. Google has the burden to
show its copying was de minimis. See, e.g., Range Road Music, 2012 U.S. App. LEXIS 3173, at
* 10 (plaintiff with evidence of direct copying not required to show substantial infringement).
The Court, however, should instruct the jury which “works” it should compare. Google
copied eight source code files in their entirety, and those are the works the jury should compare.
Google argues its code copying should be compared to the entire Java platform because Oracle
registered it as a single work. The Court rejected this argument on summary judgment, finding
that “Google has not shown that the Java platform is the proper basis for comparison.” (ECF No.
433 at 6.) The Court ruled that “[t]he plain meaning of [37 C.F.R. § 202.3(b)(4)(i)(A)] is that
when a single published unit contains multiple elements ‘that are otherwise recognizable as self-
13
contained works,’ the unit is considered a single work for the limited purpose of registration,
while its elements may be recognized as separate works for other purposes.” (Id.)
But if Google is correct that its copying should be compared to the Java platform as a
whole, the significance of its copying cannot be determined by examining its literal code copying
in isolation. The jury should also take into account its copying of the 37 API specifications.
D. Equitable Defenses
Finally, Google raises defenses of implied license, equitable estoppel, laches, and waiver.
Google has the burden to prove all elements of these defenses. See, e.g., United States v. King
Features Entm’t, Inc., 843 F.2d 394, 399 (9th Cir. 1988) (affirming summary judgment where
defendant “has not shown that he has evidence to establish three of the[] elements” of estoppel.)
The parties agree these are equitable defenses for the Court to decide. Nevertheless,
Google has requested an advisory verdict from the jury on these defenses. There is no reason for
jury input on these defenses, because they are equitable, meritless, and prejudicial. Google will
not be able to establish that there is a triable issue on the necessary elements of these defenses,
such as reasonable reliance, and they can be decided against Google as a matter of law.
IV. EFFECT OF PROGRAMMING LANGUAGE
The Court has asked “whether or not the copyrightability of the selection, arrangement,
and structure of the APIs depend on the underlying programming language being Java as opposed
to Python or QBASIC or other non-Java-programming language.” (ECF No. 754.) The Java
programming language provides many options that facilitate expressive, copyrightable API
design. But it does not compel or require any particular design.
The Java programming language places almost no requirements on the selection,
arrangement, and structure of the Java API elements. Java is a powerful, flexible, state-of-the-art
programming language for expressing APIs. It includes several features, such as interfaces and
packages, intended to facilitate API design. This empowers developers to express Java API
specifications in myriad ways, and supports their copyrightability. Cf. 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
14
monopoly on the underlying idea.”). But, while the language created the opportunity for Sun to
develop rich, expressive APIs, it did not compel Sun to do so. Sun made a deliberate design
decision to include extensive class libraries and a robust set of APIs. In contrast, although C++ is
as powerful a language as Java, it has a much more Spartan set of APIs, reflecting the minimalist
philosophy of their designer. (See Bjarne Stroustrup, THE C++ PROGRAMMING LANGUAGE § 16.1
(3d ed. 1997). ) Only a very small number of API elements are so closely tied to the language that
they are formally required by the language specification. For example, the language requires the
classes java.lang.Object, java.lang.Class and java.lang.String to be present. (See James Gosling
et al., JAVA LANGUAGE SPECIFICATION § 4.3.2 (3d ed. 2005).)
QBASIC is a simpler programming language than Java, with fewer linguistic options. It
is not an object-oriented language, and so has fewer alternatives available for expressing
arrangement and structure of API elements. It can be compared to a human language that has
only the present tense: there are obviously more expressive options in languages that allow for
past, future, and other tenses. Python is a more extensive and sophisticated language than
QBASIC, but still does not include all of the same features that Java has to facilitate API design.
For example, Python’s method signatures do not have types associated with the parameters. In
Java, an API designer can give each parameter a type, such as a class or interface created by the
designer, expressing how developers should use the parameter. This form of expression is
unavailable in Python and related languages.
Like Sun, Google had many options in creating the Android API specifications and
libraries, as illustrated by the other APIs it chose to design itself without copying from Sun.
Google took what it wanted. It copied by choice, not by necessity.
Dated: March 9, 2012
MORRISON & FOERSTER LLP
By: /s/
Michael A. Jacobs
Attorneys for Plaintiff
ORACLE AMERICA, INC.
15
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 11:40 AM EDT |
If Oracle wins on this API issue does that mean every book covering Java
violates their copyrights?
[ Reply to This | # ]
|
|
Authored by: stegu on Tuesday, March 13 2012 @ 11:43 AM EDT |
Please state the error and your correction already in the title,
like this: "Error -> Correction".
[ Reply to This | # ]
|
|
Authored by: feldegast on Tuesday, March 13 2012 @ 12:04 PM EDT |
Please make links clickable
---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.[ Reply to This | # ]
|
|
Authored by: feldegast on Tuesday, March 13 2012 @ 12:05 PM EDT |
Please make links clickable
---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.[ Reply to This | # ]
|
|
Authored by: feldegast on Tuesday, March 13 2012 @ 12:06 PM EDT |
Thank you for your support
---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.[ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 12:10 PM EDT |
Because Google's implementation can do what the Oracle (originally SUN) software
can do, that's a violation? Then Microsoft is in deep doo-doo for DOS, which
copied CPM in function (although, not as well).
[ Reply to This | # ]
|
|
Authored by: mcinsand on Tuesday, March 13 2012 @ 12:20 PM EDT |
Will someone please help me to understand how the presence, Sun/Oracle approval,
and continued growth of Openjdk does not undercut any complaints about
'derivative works.' To me, this seems to be the ultimate 'derivative work,' and
it's out there as GPL, right? Did Sun/Oracle have strings attached when they
got the Openjdk ball rolling?
To me, it seems like the principle of laches would have to kick in to reduce, if
not eliminate, any validity to a complaint Oracle would have about 'derivative
works.'
;) Could Google just claim to be their product on Openjdk, rather than Java?[ Reply to This | # ]
|
|
Authored by: SLi on Tuesday, March 13 2012 @ 12:25 PM EDT |
I don't claim to be all that tech savvy, but it
strikes me that
what goes into an API is what has to go into an
API for it to be effective. You
are defining an interface. To be
able to take advantage of that interface
certain things have to
be present, and in turn, certain information will be
returned.
Now I would agree that the programmers have a choice as to
whether
to create an interface, but once it is determined to be
either necessary or
desirable, what goes into that interface is
far less
subjective.
Well, no. As a computer scientist, I can tell you
that's a bit
like saying "once you have decided to design a programming
language, what it will end up like is almost settled" (or imagine
a natural
language if you will, they are not that different).
I think the mistake you
make is that you think of too simple
an interface. Think about the interface
you use for driving a
car. Even that interface has gone through a fairly large
number
of revisions before it ended up in the current form. I'd say
that's a
fairly simple API, yet there's lot of choices to be made
there unless you just
intend to copy the way it's been done in
every car since, what, 70 years ago?
Many of the earlier designs
were poor. You might have had two levers (or
pedals) to
separately turn the left and right tires in different directions.
The steering wheel was by no means an obvious thing. Etc.
Also there's
certainly some truth to the idea that designing
the API is in many cases
the central engineering feat
of, especially, libraries. From an API
specification a code
monkey with two years worth of education could probably
write a
satisfactory implementation.
While method and class names are
important, they are probably
the most mechanical and non-creative part (still
you can make
poor decisions there). What to include and what to leave out is
quite a crucial decision. Include too much - like allowing the
user to
separately control left and right tires - and you are
essentially tying
yourself to a single possible way of
implementing the library. If you later
find out that wasn't
the best way, you are out of luck. Include too little and
it will
be hard to accomplish what needs to be accomplished using your
API.
Some things are a lot harder to do with automatic gears than
manual ones, for
example.
Note that I'm not claiming APIs should be copyrightable. I
don't
think they should. But designing them most certainly
involves creativity. If
they shouldn't be copyrightable, I think
it's the job of you law guys (and the
lawmakers) to figure out
how to find them not copyrightable despite designing
them
involving a huge amount of creativity. [ Reply to This | # ]
|
- Prior art;- an old idea cast your mind back - Authored by: Anonymous on Tuesday, March 13 2012 @ 12:40 PM EDT
- Creativity in API design - Authored by: tknarr on Tuesday, March 13 2012 @ 12:47 PM EDT
- Creativity in API Clue Sticks - Authored by: webster on Tuesday, March 13 2012 @ 01:02 PM EDT
- Yes, there is a lot of creativity - Authored by: jbb on Tuesday, March 13 2012 @ 01:46 PM EDT
- Creativity in API design - Authored by: PolR on Tuesday, March 13 2012 @ 02:01 PM EDT
- Creativity and APIs - Authored by: Anonymous on Tuesday, March 13 2012 @ 03:48 PM EDT
- Ships Wheel and TIller styles - Authored by: Anonymous on Tuesday, March 13 2012 @ 04:34 PM EDT
- Creativity in API design - Authored by: Anonymous on Tuesday, March 13 2012 @ 09:39 PM EDT
- APIs as language - Authored by: Anonymous on Tuesday, March 13 2012 @ 09:48 PM EDT
- Creativity in API design - Authored by: Anonymous on Wednesday, March 14 2012 @ 02:10 AM EDT
- I never read so much misguided rubbish on Groklaw. - Authored by: Anonymous on Wednesday, March 14 2012 @ 08:05 AM EDT
|
Authored by: Ian Al on Tuesday, March 13 2012 @ 12:42 PM EDT |
The author decided which events to include, as well as the relationships and
interdependencies among the thousands of individual events.
We own the selection, arrangement, and structure of the historical events. It
would be copyright infringement for a second author to take the historical
outline and publish a second multi-volume work in the order of the historical
events and therefore containing identical names for each volume, chapter, and
subchapter, identical events, facts, and primary sources discussed to the same
level of detail, appearing in exactly the same historical order, and accompanied
by identical copies of paintings and drawings produced at the time of those
events.
Scènes à faire just isn't a defence against this infringement... it just
isn't... only we have a right to those events in history.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 01:00 PM EDT |
Sun sued Microsoft *for not exactly following the Java API*.
I know, it's not exactly the same. Sun sued to keep Microsoft from adding
things to the standard packages. The upshot was that Microsoft couldn't call
the result "Java". Whereas Google isn't calling the result
"Java", but *is* using the API.
Still, there has to be some kind of precedent from that case, which would make
Oracle have to answer some *very* uncomfortable questions about precedent,
estoppel, and the like.
MSS2[ Reply to This | # ]
|
|
Authored by: tknarr on Tuesday, March 13 2012 @ 01:08 PM EDT |
One thing I'd note: the things Oracle are alleging Google copied about the
API are in fact the exact things any Java programmer needs to copy merely to use
the API. When I write Java code I need to use the class and method names,
arranging them according to the defined class hierarchy, and I need to use the
exact order and types of arguments to the functions. If I do not copy those
elements into my Java code, it won't work. If copying those elements constitutes
making a derivative work, then every Java program ever written is
necessarily a derivative work of the Java language and infringes on Oracle's
copyrights.
Of course, here's the kicker: Oracle's JVM is, by the same
logic, a derivative work of glibc. Oracle releases their own JVM for Linux-based
systems, all of which use glibc. To write the JVM, Oracle had to use the glibc
API and it's copyrighted selection and arrangement of function names and
arguments and such. If doing so is copyright infringement, then Oracle is
infringing on the FSF's copyright on glibc by distributing their JVM (which is
according to Oracle's argument a derivative work of glibc) under terms not
compatible with the LGPL. That's obviously not so, but if Oracle wants to argue
that it is... [ Reply to This | # ]
|
|
Authored by: tbranaman on Tuesday, March 13 2012 @ 01:27 PM EDT |
So: If any code implementing a specification is a
copyright
violation,
is Oracle guilty of copyright infringement for
implementing the SQL
specifications? If so, they must owe a
huge amount of money to somebody! [ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 03:52 PM EDT |
Oracle's argument would make impementing any compatible interface copyright
infringement and would probably also make any use of an interface copyright
infringment. Oracle itself will face massive copyright liability for virtually
everything they have written. It will become impossible to use standardized
interfaces for anything.
I hope they win. This kind of insane scorched-earth policy might be just what
is needed to wake up Congress, CAFC, and the Supreme court and eliminate the
insanity of software patents forever.[ Reply to This | # ]
|
|
Authored by: Steve Martin on Tuesday, March 13 2012 @ 03:58 PM EDT |
PDF's on the way to Mark, but here's the gist:
For the
reasons stated, the independent-significance
approach is STRICKEN.
The
econometric analysis is STRICKEN. The conjoint analysis’
determination of
market share is
STRICKEN in both Dr. Shugan’s and Dr. Cockburn’s reports.
However, the conjoint analysis’
determination of relative importance between
application
startup time and availability of
applications is not stricken. The
“upper bound” calculation
in the group-and-value approach is
STRICKEN. The
“lower bound” calculation in the group-and-
value approach shall be adjusted
by
deducting $37 million for the value of the unasserted
copyrights from
the adjusted starting point
of $598 million. Therefore, $561 million
shall be the total
value of the copyrights in suit and 569
patents in Sun’s
Java mobile patent portfolio. Both parties
shall please advise the Court how
Dr.
Cockburn’s report could calculate a reasonable royalty for
each individual
patent in light of the
items stricken by this order. The parties shall submit
ten-
page statements on this by NOON ON
MARCH
19.
--- "When I say something, I put my name next to
it." -- Isaac Jaffe, "Sports Night" [ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 04:26 PM EDT |
Oracle is simply wrong, or all the legal precedent (as well
as industry standard practices) regarding implementation of
APIs has to go into the trash bucket.
They must be living on another planet or something.
DSB[ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 05:04 PM EDT |
Isn't the development of the Java spec done by working
groups? I'm not a Java programmer, but I'm sure I remember
committees working on the API. Did they have to assign their
work to Sun? Or are the files/elements that Oracle claims
were copied developed before the standardisation effort?
I'm just wondering whether Oracle does in fact hold
copyright.[ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 05:08 PM EDT |
Reading Oracle sometimes referring to Java APIs, and sometimes
to API Specifications, made me go back to check. If anyone else
is confused the 37 allegedly copied "packages" are listed
in Mitchell's Opening Expert Report to be found at:
Groklaw -> Timelines -> OracleGoogle -> 341 -> Exhibit 1 -> p.62
All the exhibits to the declaration are illustrative of how
Oracle believes the disputed material is copyrightable.
[ Reply to This | # ]
|
|
Authored by: jbb on Tuesday, March 13 2012 @ 05:35 PM EDT |
Once APIs are protected by copyright, clean-room re-implementations will be
worthless. Every case where a clean-room re-implementation defense was
successful can now be revisited and the previous verdict can be overturned.
Perhaps more common will be new law suits in situations where there was no suit
because everyone assumed clean-room re-implementations were legal.
This
will go back at least as far as the BIOS wars in the early 1980's. The PC
revolution was launched when it was determined by a court of law that a
clean-room re-implementation of IBM's BIOS API was legal. If APIs themselves
are protected by copyright then clean-room re-implementations are useless
because they all start with the API and then create everything else from
scratch.
If APIs become protected by copyright then IBM might be owed the
biggest windfall in the history of the human race.
--- Shirky
Principle: Institutions will try to preserve the problem to which they are the
solution. [ Reply to This | # ]
|
|
Authored by: mjscud on Tuesday, March 13 2012 @ 06:46 PM EDT |
Leaving aside the question of whether APIs in general are or should be
copyrightable (I don't think they are, and they certainly shouldn't be), there's
the question of what Sun/Oracle has advertised as free to use: the Java
Language.
In 1998 Guy Steele gave a Growing a
Language lecture where he defined or gave a generating form for every
multisyllabic word he used in the talk. The point was to refute the then popular
notion that languages needed to be small and every user build their own
libraries (and APIs!) on top of them. It was an excellent and persuasive
lecture.
But the point is that, as the specifier of Java and an
evangelist for Sun, what he called the Java language specifically included the
growing set of APIs that made the Java language more useful than competing
languages.
The representations that Sun made, and Oracle has inherited,
of the freely available Java languages include the APIs that Oracle is now
trying to withdraw from what is freely available. Moreover, this representation
was specifically promoted as a reason for people to choose the Java language,
and users have relied on that to their detriment if the APIs once free are
withdrawn.
Therefore the doctrine of Laches is an affirmative defence
when using Java APIs, even if APIs in general were somehow held to be otherwise
protectable.
--- Even a fool, when he keeps silent, is considered
wise. Proverbs 17:28 [ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 07:02 PM EDT |
Looks like the good judge rolled over and let Oracle rub his tummy.
From what I've read so far, Oracle got most of what they wanted.[ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 10:29 PM EDT |
Have Oracle checked this assertion? Or does it just sound
right to them? Apart from including photos and drawings, it
seems that there would be no copying of creative expression.[ Reply to This | # ]
|
|
Authored by: hardmath on Tuesday, March 13 2012 @ 10:29 PM EDT |
Apologies in advance for diving into the weeds with this post.
Not
infrequently in technical writing the same word gets used in ways with different
meanings. Such is the case here with the word "interface".
Used as the "I"
in API (or equivalently, in Google's brief, as in "software interface"),
something quite general is meant. API's or "software interfaces" are the
specifications attributed to certain well-defined software of how newly written
software is supposed to communicate ("link") with it. Software interfaces might
define communication in either direction, for "new" software to call the "old"
or vice versa.
The meaning of "Interface" in Java programming is more
limited, a very special case of the above. An Interface (which Oracle refers to
while listing the bunches of things Google is alleged to have unlawfully copied)
is defined in reference to object-oriented programming(OOP). Now Java is not
the first OOP language, and it will not be the last, so none of what I'm
about to describe is unique to Java programming.
An overly concise notion of
object-oriented programming is that code becomes compartmentalized by Classes
which implement Methods (the functions or routines of OOP).
An Interface
(capital I) is a collection of Methods defined apart from any particular
implementation of those by a Class. The notion is that two not-necessarily
related Classes might both implement the same Interface, and with this
circumstance code depending only on the Methods of that Interface might be used
interchangeably with either Class.
While this notion might apply to almost
any OOP language, it has special utility for OOP languages that provide "strict"
type-checking, which includes Java and essentially all of the OOP languages
which are derived from C (not itself an OOP language, but the source of Java's
many curly brackets and semi-colons).
Without Interfaces, Java would lack a
general way of confirming for the linker that all the required Methods will
absolutely/positively be there (so that it's "strictly" okay to go ahead and
build something that combines the old and new software). You'd still have a way
of doing it in special cases (where one Class "inherits" from another), but not
in a general way.
It's that generality that allows third-party Java
developers to implement libraries that work with existing Java packages, without
needing access to the source of those packages. This is a good thing for both
the package developers and the third-parties, just like the proverbial good
fences that make good neighbors.
regards, hm
--- Do the arithmetic
or be doomed to talk nonsense. -- John McCarthy (1927-2011) [ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, March 13 2012 @ 11:12 PM EDT |
Either Oracle has completely misunderstood what the judge
requested, or chose
to ignore it:
The Court has asked “whether or not the
copyrightability of the selection, arrangement, and
structure of the APIs
depend on the underlying programming
language being Java as opposed to Python
or QBASIC or other
non-Java-programming language.” (ECF No.
754.)
Oracle's reply to this is:
The Java programming
language places almost no
requirements on the selection, arrangement, and
structure of
the Java API elements. Java is a powerful, flexible,
state-
of-the-art programming language for expressing APIs. It
includes several
features, such as interfaces and packages,
intended to facilitate API design.
[...] In contrast,
although C++ is as powerful a language as Java, it has a
much more Spartan set of APIs, reflecting the minimalist
philosophy of their
designer. [...] Python is a more
extensive and sophisticated language than
QBASIC, but still
does not include all of the same features that Java has to
facilitate API design. For example, Python’s method
signatures do not have
types associated with the parameters.
In Java, an API designer can give each
parameter a type,
such as a class or interface created by the designer,
expressing how developers should use the parameter. This
form of expression is
unavailable in Python and related
languages.
They are first
saying (lengthily) that the Java language does not require the API to be what it
is. Then they go on to say that other languages implement different APIs
(captain obvious agrees).
Then they use type-less languages as an excuse to say
that their APIs are different.
Let me put this out there, as a (former)
developer: This API can be implemented in a large number
of programming
language. If I wanted C++ to use the same API, I could program it. If I wanted
Python
to use the same API, I could (less the types, but type checks can be
forced in the methods). This
could be implemented in PERL, ActionScript, LISP,
you name it. These APIs would look slightly
different, depending on the syntax
of the programming language itself; the methods may or may not be
typed, have
protection (public/private), etc. The closest in syntax could implement
virtually identical APIs - C++
and
C#, I am looking at you (probably objective
C as well).
The fact that (almost) nobody does this does not mean that
it is not possible - the selection,
arrangement and structure of the API does
not depend on the programming language, if the syntax is
close enough to
Java. If the syntax is different, the arrangement may differ (as dictated by
the
programming language syntax), but the selection and structure should be
very close. [ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, March 14 2012 @ 11:31 AM EDT |
Am I confused?
Definition of the Term Specification: a specification is a
very detailed description of a thing or how something works;
a technical schematic; a recipe.
Note Recipes are not actually protectable and even if some
very elaborate recipe was protectable, it would still not
give the copyright holder any rights to the food thus
created ...not really :-) Thats why the Copyright Office
says: if you want to keep your recipe secret then don’t
publish it.
So why is this Judge suggesting otherwise?
If a Work derived from a Specification is a copyright
infringement where does that put us?
Lets say: I read the K&R Book on the C Programming Language
(thats certainly a specification). I then write a cool
program referring to that book for in-depth specifications
enabling me to correctly program my code. Would that have
given K&R any rights to my Program?
If I read a very detailed technical Book on Personnel
Management (the Book details what kind of data is needed for
a Personnel Record, and even goes so far to suggest sizes
and data-types, for the various elements of a record). Lets
say it also gives very detailed insights in how staffing and
auto-staffing for various kinds of projects might be done
(no code included...).
Highly inspired by this I would then sit down and write a
nifty program to manage my team of engineers, including
auto-staffing functions.
How could my usage of the information in that Book possibly
constitute a copyright infringement in such a case, assuming
my program was at least partially derived from the
information given in it (without code copying) ?
I am frankly beginning to have doubts about the Judges
statements on copyright implications of
API specifications. Is he trying to create a new class of
IP by creating a new IP-Category around specifications for
API’s?
Verbatim copying is maybe a little bit more problematic, at
least it dosen’t look so good for Google purely optically in
front of a Jury, is that why the Judge is facilitating a
Jury trial? And is he really as impartial as he is required
to be?
I am concerned.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, March 14 2012 @ 05:56 PM EDT |
The Java API implementations are analogous to a multi-volume history, such
as the Durants’ eleven-volume The Story of Civilization, and the Java API
specifications are like the author’s meticulously detailed outline of those
works.
This is a false comparison. It suggests that the structure
of a program is copied when you use an API and that is not the case. A more
correct comparison would be to say that a Dictionary is equivalent to a
programming API. A dictionary describes what each word means in context, as an
API describes functions/suroutines and their context.
The order an
Author uses to create a story using words is uniquely his/hers, as is the order
a programmer uses the API functions/routine within their software.
Does
the publisher of a dictionary own all books as they are now derivative works of
a dictionary? I think not!
By the same logic, using an API does not
mean that your software is now a derivative work of that API owner ...
[ Reply to This | # ]
|
|
|
|
|