decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Amicus Brief of Intellectual Property Law Professors in Support of Google and Affirmance ~pj
Monday, June 03 2013 @ 03:25 AM EDT

Bit by bit, the amicus briefs on behalf of Google in the Oracle v. Google appeal about the uncopyrightability of Java APIs are becoming available. They are all interesting in different ways, but they all agree -- Oracle is wrong on the law and if it prevails, it will be a sad day for innovation. Copyright protection doesn't extend to procedures, processes, systems, or methods of operation, and it shouldn't.

This brief, on behalf of 39 intellectual property professors, and written and signed by Pamela Samuelson, outlines three legal errors they all believe Oracle is making:

  • that Oracle takes an unduly narrow view of 17 U.S.C. § 102(b)

  • it takes an overbroad view of the copyrightability of the structure, sequense and organization, or SSO, of computer programs -- so did SCO, I can't help but add, also represented by David Boies, and SCO's larks were partly funded by Microsoft, who is supporting Oracle, and

  • it misunderstands the merger doctrine as it applies to interoperability.

Here's where you can find the "Brief of Amici Curiae Intellectual Property Professors in Support of Defendant-Cross Appellant and Affirmance." That's the title of the brief, and it is available on SSRN.

Oracle has struck an ominous chord with its claims, and the alarm they and other amici are expressing is sincere and deep. And what they are saying in chorus is: Oracle is wrong about the law on APIs. In fact, one case Oracle hangs its hat on, Apple Computer, Inc. v. Franklin Computer Corp., isn't binding precedent for Oracle, the brief highlights. It's a Third Circuit case (it was also merely dicta and the facts were distinguishable), and Oracle's case is in the Ninth. The court of appeals is supposed to give deference to the Ninth Circuit precedent. And dicta isn't precedential anyway. The cases that are more binding are cases Oracle ignores, like Computer Associates Int’l, Inc. v. Altai, Inc. and Sega Enterprises, Ltd. v. Accolade, Inc., and under their teaching, "the Java APIs should be deemed unprotectable by copyright law" because the district court found that these Java APIs were necessary to achieve interoperability.

Further, the brief cites Sony Computer Entertainment, Inc. v. Connectix, Inc. , where Connectix emulated the Sony functionality of the Playstation, but the court ruled that the Sony interface procedures were unprotected elements, even though the Connectix software "aimed to be a substitute for the plaintiff's product" and was not fully compatible with the Playstation games. That should put a sock in Oracle's mouth about compatibility, methinks. It keeps saying that Java and Android are not fullly compatible. The answer to that from these IP law professors is, the Ninth Circuit already handled a case like that, and it didn't alter the unprotectability of the interfaces.

They ask the appeals court to affirm Judge William Alsup's decision:

Oracle has invited this Court to ignore or radically reinterpret more than two decades of copyright jurisprudence concerning the application of copyright law to elements of computer programs that are essential to achieving interoperability among programs. This Court should decline this invitation.


Here's the introduction to the brief, which gives the overview:

SUMMARY OF ARGUMENT

Three fundamental errors undergird Oracle’s legal position on this appeal of a District Court ruling that the Java Application Programming Interfaces (APIs) at issue in this case are unprotectable by U.S. copyright law.

First and foremost, Oracle takes an unduly narrow view of 17 U.S.C. § 102(b), which provides that “[i]n no case does copyright protection . . . 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 a protected work. This statute codifies the principal holding of a venerable Supreme Court decision ruling that bookkeeping systems, any methods of operation they might entail, and other useful arts depicted in copyrighted works are not within the scope of protection that copyright law provides to original works of authorship. Systems and methods may be eligible for patent protection, however.

Oracle tries to read the procedure/process/system/method of operation exclusions out of the statute by asserting that to take these exclusions seriously would undermine copyright protection for computer programs. Nothing could be further from the truth. The legislative history of the Copyright Act of 1976 (1976 Act) indicates that Congress was well aware that computer programs would instantiate numerous types of unprotectable processes and methods of operation. It added the § 102(b) exclusions to the statute with the specific intent of ensuring that copyright protection for programs would not be interpreted too broadly.

It is a basic canon of statutory interpretation that courts must endeavor to give all words in a statute appropriate meaning. If Congress has decided that computer programs are copyrightable, but processes and methods they embody are not, then it is incumbent on courts to determine which processes and methods embodied in programs are outside the scope of copyright protection. After a full trial on the merits and consideration of numerous briefs, the District Court determined that the command structure of the Java APIs at issue in this case were methods that enabled program interoperability, and consistent with controlling Ninth Circuit decisions, ruled that these APIs were unprotectable methods under § 102(b).

A second fundamental error in Oracle’s legal position in this appeal is its overbroad understanding about the protectability of “structure, sequence and organization” (SSO) of computer programs. While some case law endorses the view that program SSO may in appropriate cases be within the scope of protection that copyright provides to programmers, courts and commentators have recognized that the SSO concept is too imprecise to be useful in software copyright cases. The main reason is because this concept does not help courts to make appropriate distinctions between protectable and unprotectable structural elements of programs.

Procedures, processes, systems, and methods of operation, almost by definition, contribute to the structure and organization of works of authorship that may describe or embody them. But this does not make those elements protectable by copyright. The main reason why computer programs have a “thinner” scope of protection than, say, Harry Potter novels is that programs have more functional design elements, including processes and methods, that are beyond copyright’s scope.

A third fundamental error in Oracle’s legal position in this appeal lies in its mistaken understanding of the merger doctrine as applied to elements of computer programs that are essential to interoperability. Oracle wants to believe that as long as its engineers exhibited creativity in the design of the Java APIs and those engineers were not constrained in their choices about how to construct the APIs, the APIs are ab initio copyright-protectable expression. This view is mistaken. The case law is clear that when the design choices of subsequent programmers are constrained by the interface designs embodied in earlier programs, the merger doctrine applies to the reuse of elements necessary to achieving interoperability. All that subsequent programmers must do is to reimplement those elements in independently created code, as the District Court found that Google had done in this case.

You'll find the list of all the professors who are joining in this brief in its Appendix A, 39 of them, if I've counted correctly, and you'll find some names you recognize. Professor Michael Risch is there; so is Brian J. Love and Jessica Litman and Mark Lemley, and James Grimmelmann, and Brian Carver, Julie E. Cohen, and Dan Burk, and Dennis S. Karjala, and the list goes on and on. These are heavy duty names, and I'm just picking out a few at random. No one can say these professors of law don't know what they are talking about. More than that, they are not Google puppets or speaking for anyone but themselves, as they themselves point out:
We represent no institution, group, or association and have no personal interest or stake in the outcome of this case. Our sole interest in this case is with respect to a number of traditional principles of copyright law that we, as instructors and commentators on intellectual property law, believe should be considered in determining the proper scope of copyright protection for certain elements of computer programs. We oppose Oracle’s legal position in this case on the merits and urge this Court to affirm the lower court’s ruling on the copyrightability of the application program interfaces at issue. We believe that the outcome of this case will have a significant impact on software copyright law, particularly with regard to interoperability, and on innovation and competition, which intellectual property law seeks to maintain.
Here's the full list of signatories:
APPENDIX A: List of Signatories

(Institutions are listed for identification purposes only)

Jonas Anderson, Assistant Professor American University, Washington College of Law

Timothy K. Armstrong, Professor University of Cincinnati College of Law

Dan Burk, Professor University of California, Irvine, School of Law

Michael A. Carrier, Professor Rutgers Law School – Camden

Michael Carroll, Professor American University, Washington College of Law

Brian Carver, Assistant Professor University of California, Berkeley, School of Information

Margaret Chon, Professor Seattle University School of Law

Julie E. Cohen, Professor Georgetown University Law Center

Ralph Clifford, Professor University of Massachusetts School of Law

Stacey L. Dogan, Professor Boston University School of Law

Shubha Ghosh, Professor University of Wisconsin Law School

James Grimmelmann, Professor New York Law School

Paul Heald, Professor University of Illinois College of Law

Peter Jaszi, Professor American University, Washington College of Law

Dennis S. Karjala, Professor Sandra Day O’Connor College of Law, Arizona State University

Marshall Leaffer, Distinguished Scholar in IP Law and University Fellow Indiana University Maurer School of Law

Mark Lemley, Professor Stanford Law School

Yvette Joy Liebesman, Assistant Professor Saint Louis University School of Law

Jessica Litman, Professor University of Michigan Law School

Lydia Pallas Loren, Professor Lewis & Clark Law School

Brian J. Love, Assistant Professor Santa Clara University School of Law

Glynn S. Lunney, Jr., Professor Tulane University School of Law

Michael J. Madison, Professor University of Pittsburgh School of Law

Stephen McJohn, Professor Suffolk University Law School

Charles R. McManis, Professor Washington University School of Law

Lateef Mtima, Professor Howard University School of Law

Mark Patterson, Professor Fordham University School of Law

Aaron Perzanowski, Associate Professor Case Western Reserve University School of Law

Victoria Phillips, Professor American University, Washington College of Law

Malla Pollack, co-author, CALLMANN ON UNFAIR COMPETITION, TRADEMARKS & MONOPOLIES (Thomson-Reuters 4th ed.)

Jerome Reichman, Professor Duke University School of Law

Michael Risch, Associate Professor Villanova University School of Law

Michael Rustad, Professor Suffolk University Law School

Matthew Sag, Professor Loyola University Chicago School of Law

Pamela Samuelson, Professor University of California, Berkeley, School of Law

Joshua D. Sarnoff, Professor DePaul University College of Law

Christopher Sprigman, Professor University of Virginia School of Law

Katherine Strandburg, Professor New York University School of Law

Rebecca Tushnet, Professor Georgetown University Law Center

See what I mean? And to journalists, this is a handy list for you when a case is in the news and you want to understand some aspect of it or need a comment for your article.

I'd like to highlight Section III in particular, because it directly responds to Oracle's position on SSOs, and it also explains what the merger doctrine is, in case you were wondering:

III. When a Computer Program Interface Constrains the Design Choices of
Subsequent Programmers, the Merger Doctrine Precludes Copyright Protection
for that Interface Design.

Oracle wants to believe that as long as its engineers were not constrained in their design choices as they developed the Java APIs at issue in this case, as long as they exercised creative judgments in selecting and arranging the structure and other components of each API, and as long as these designs satisfy the minimal creativity requirement for copyright protection, the Java APIs and their SSO are protectable by copyright law. See Appellant’s Br. at 36-45.

17

The software copyright case law of the last 21 years demonstrates that this view is plainly erroneous. Altai established, and other courts later followed, the rule that external factors such as the “compatibility requirements of other programs with which a program is designed to operate” limit the scope of copyright in programs because these factors constrain the freedom of design choices of subsequent programmers. Altai, 982 F.2d at 709-10. To interoperate with existing programs, any new program must send and be designed to receive information in the precise fashion required by the interface specifications of the programs with which it is to be compatible. Anyone who develops an API is, in a very real sense, designing that aspect of the program for itself and for others.

The Second Circuit was convinced that Altai had taken from CA’s program only what was necessary to achieve compatibility. See id. at 714-15. By contrast, Atari Games copied more than was necessary to achieving compatibility with Nintendo’s programs, which was why the Federal Circuit ruled against its compatibility defense in that case. See Atari Games, 975 F.2d at 840.

The Second Circuit in Altai referred to the merger doctrine in discussing why external factors such as compatibility needs limited the scope of copyright protection in programs. See Altai, 982 F.2d at 708-09. That is a sound doctrinal basis for such a ruling. Courts often recognize that when there is only one or a

18

small number of ways to express an idea, idea and expression will be considered to have merged, and no copyright protection is available to the merged elements.

The merger principle, like the exclusion of methods and processes, derives from Baker v. Selden. There, the Supreme Court observed that “where the [useful] art [a work] teaches cannot be used without employing the methods and diagrams used to illustrate the book, or such as are similar to them, such methods and diagrams are to be considered as necessary incidents to the art, and given therewith to the public.” Baker, 101 U.S. at 103. Baker had no choice but to use substantially the same arrangement of headings and columns if he wanted to reimplement Selden’s bookkeeping system in his own independently written work. APIs pose similar constraints on the design choices of subsequent programmers.

The Ninth Circuit, whose rulings should be given considerable deference on this appeal, has reached the same conclusion about the unprotectability of interfaces necessary for interoperability as the Second Circuit did in Altai. It did not matter in Sega that the plaintiff had designed the interface procedures for its Genesis console in a creative way. The Sega interface procedures constrained Accolade’s design choices when it sought to write a program that would run on the Sega platform. See Sega, 977 F.2d at 1522. For this reason, the interface procedures were unprotected aspects of the Sega program under § 102(b). See id. at 1526. Nor did it undercut Accolade’s defense that Sega had a licensing program

19

for Genesis-compatible videogames in which Accolade declined to participate. See id. at 1514, 1523.

Eight years after Sega, the Ninth Circuit revisited the legality of reverse-engineering copyrighted program code, considering this time the development of software that could interoperate with third-party software designed to run on the plaintiff’s platform. In Sony Computer Entertainment, Inc. v. Connectix, Inc., 203 F.3d 596 (9th Cir. 2000), Connectix developed a program to emulate the functionality of the Sony PlayStation for which many videogames had been developed. Sony sought to distinguish the Sega decision on numerous grounds, all of which were unavailing. See id. at 602-07. The bottom line was the same. The Sony interface procedures were unprotected elements of the PlayStation software, see id. at 603, and reverse engineering Sony’s code to get access to these unprotected elements was fair use. See id. at 608. It did not matter that the Connectix software aimed to be a substitute for the plaintiff’s product, see id. at 606-07, and not merely a complementary product as in Sega v. Accolade. See Sega, 977 F.2d at 1522. Nor, apparently, did it matter that the Connectix software was not fully compatible with the PlayStation games. See Connectix, 203 F.3d at 599.

The District Court found that the Java APIs at issue in this case were necessary for achieving interoperability. Oracle, 872 F. Supp. 2d at 979-81.

20

Accordingly, under Altai and Sega, the Java APIs should be deemed unprotectable by copyright law.

Oracle tries to make much of a few statements made by the Third Circuit Court of Appeals in Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983). See Appellant’s Br. at 64-65. Apple sued Franklin for copyright infringement because Franklin copied the Apple operating system (OS) programs in order to make a computer that would be compatible with programs written to run on the Apple II computer. See Apple, 714 F.2d at 1243-44. One of Franklin’s defenses was that it was necessary to copy the Apple OS in order to be compatible with the applications software developed to run on the Apple platform, for there were only “a limited number of ways to arrange operating systems to enable a computer to run . . . Apple-compatible software.” Id. at 1253 (citation omitted) (internal quotation marks omitted).

It is true that the Third Circuit regarded Franklin’s compatibility argument as having “no pertinence to either the idea/expression dichotomy or merger.” Id. Compatibility was, in its view, “a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and expressions have merged.” Id.

These statements do not provide as much support for Oracle’s appeal as it thinks for three reasons. First, Franklin made no effort to reimplement the

21

interface procedures embedded in the Apple OS in independently written code. It just copied the Apple programs exactly, bit for bit. See id. at 1245. Second, these statements were made at an earlier stage in the evolution of software copyright law, well before the Altai, Atari Games, Sega v. Accolade, and Connectix cases that provided more thorough analyses of the copyright implications of a second comer’s reimplementation of interface procedures necessary for interoperability. Third, the very purpose of developing and promoting widespread use of Java APIs was to enable greater interoperability among programs.

In our view, the District Court gave appropriate weight to the later Ninth Circuit rulings and wisely eschewed blindly embracing the anti-compatibility dicta from the earlier Franklin decision.4

CONCLUSION

Oracle has invited this Court to ignore or radically reinterpret more than two decades of copyright jurisprudence concerning the application of copyright law to elements of computer programs that are essential to achieving interoperability among programs. This Court should decline this invitation.

________________
4 In addition, the Franklin decision came out of the Third Circuit Court of Appeals and is in no way a binding precedent in a case such as Oracle, which arose in the Ninth Circuit.

22

This sentence particularly struck me: "Third, the very purpose of developing and promoting widespread use of Java APIs was to enable greater interoperability among programs." As Jonathan Schwartz testified, it was designed to help people escape Microsoft's monopoly, so you could function without having to write a check to Microsoft. From Google's appeal brief:
Sun Microsystems, with other companies, developed the Java Programming Language ("JPL") and platform in the 1990s in an effort to bypass Microsoft's Windows-based monopoly. Former Sun CEO Jonathan Schwartz explained that Sun's goal was to create a platform that would enable programmers to "'write once, run anywhere,' as opposed to 'write once, and write a check to Microsoft to run it.'" Sun worked with other companies to create "the Java Community," whose members "agree on the language and the specifications" for Java so that, "when [programmers] at Oracle or SAP write an application, it can run on an IBM computer. . . . It can run on a Sun computer. It can run on any computer that runs Java. And that was our way of bypassing the monopoly."

Sun and its collaborators, including Oracle, recognized that they could not accomplish these goals by creating another proprietary platform, which Microsoft would dwarf. Instead, they made Java open and free for anyone to use, to create a larger and more competitive market. Sun's strategy was to "build trust" with potential partners by declaring that all specifications would be "decided in the open" and that "[e]veryone [would] have equal access to them" so that they could then "go off and create [their] own products." As part of that strategy, Sun "made a lot of noise about open APIs" so as to "bring in as many people as possible . . . to the Java Community. . . . We wanted to basically build the biggest tent and invite as many people as possible."

That was how Oracle felt before it bought Sun and with it Java. When it didn't own it, its position was that Java should be open and free. I left off the footnotes for readability, by the way, but you can find them at the link.

How ironic that now Oracle would like to make Java APIs proprietary, so you can't touch them without crossing Oracle's palm with silver and getting its permission. People didn't contribute code to Java for that to be the outcome, where you merely replace one oppressive monopoly with another. It's a travesty.

Note that some of the amicus briefs that are showing up are not yet accepted by the court. There could be corrections required regarding formatting or whatever else the court deems required. That's fairly common. If that happens with this one, I'll make a note in an update.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )