Innovators, Entrepreneurs and Funds File Amicus in Support of Google in Oracle v. Google Appeal ~pj Updated

Friday, May 31 2013 @ 03:44 PM EDT

Contributed by: PJ

The remarkable outpouring of support for Google in the Oracle v. Google appeal continues, with a group of well-known innovators, start-ups, and those who fund them -- innovators like Ray Ozzie, Tim O'Reilly, Mitch Kapor, Dan Bricklin, and Esther Dyson -- standing with yesterday's group of leading computer scientists in telling the court that Oracle's attempt to copyright its Java APIs would be damaging to innovation.

Why? Because it would represent a change in the way copyright has worked since at least 1879, when Baker v. Selden was decided. "The scope of copyright protection for computer programs has always been carefully and purposefully limited," the brief notes. Remember Lotus v. Borland where the court found that a menu command hierarchy was an uncopyrightable method of operation "because it was essential to making use of the program’s functional capabilities"? "The Java API elements at issue here are comparable to the menu hierarchy in Lotus: uncopyrightable because they constitute the method of operation through which a user’s program accesses, controls, and makes use of the functional capabilities of the Java API," they tell the court. So why is Oracle trying to upset this careful balance?

Jennifer Urban, with the Samuelson Law, Technology and Public Policy Clinic at the U.C. Berkeley School of Law is representing this group, and here's their amicus brief [PDF] in support of Google. They tell the court why they care about this case and how they hope to be helpful to the court:

Amici are software innovators, start-ups, and investors. The signatories on this brief include innovators, and founders of software and Internet companies that actively innovate in and compete across a wide array of markets. Signatories also include investors who invest in, and are expert in assessing the risks of investing in, companies that rely on APIs and other interoperability tools. Amici have broad first-hand experience in the role of interoperability—and the balanced and stable copyright rules on which it depends—in driving innovation in the technology sector. A full list of amici with individual descriptions can be found at http://www.law.berkeley.edu/amici.htm.

Amici’s shared interest in this case is in preserving the deliberate balance Congress and the courts have established for software copyright, including longstanding limits on copyrightability that enable innovation by fostering interoperability and competition. Amici join to explain the importance to innovation and investment in innovation of upholding the District Court’s careful application of these limitations to the Java API elements at issue in this case.

I'm so glad people who fully understand the technology are stepping up to explain it to the court, in the hope that it will help the court to reach a better decision. It must be very difficult to rule on a case if you don't understand the technology or fully grasp the implications of a case. And as the brief points out, if Oracle's position were to be adopted, even in part, it would "drastically expand copyrightability".

That's what I've been writing here on Groklaw since we began covering this case, and now you know, it's not just li'l ol' me. That really is what is at stake. Venture capitalist Jason Mendelson explains why his company, Foundry Group, signed this brief, and he ends by urging others to follow suit:

Recently, our company signed onto an amicus brief that might be the most important issue that we’ve faced. In short, Oracle is threatening to chill innovation in the software industry by arguing that APIs are copyrightable. Google is the defendant and should Oracle win this case, the implications are disastrous for our startup ecosystem and our economy.

Thankfully the folks at the University of California, Berkeley, spearheaded by Jennifer Urban see this as a major threat as well and wrote a cogent and powerful amicus brief to the court. The list of signatories to the brief are here and represent a wide constituency of the industry.

Thank you Jennifer and team for your tireless efforts. Startup land: please support and help recognize these important efforts.

Here's where you can find Oracle's position most fully expressed, as represented by its appeal brief [PDF].

I'll work on a text version of the amicus brief's PDF for you, but here's the opening summary of their argument:

SUMMARY OF ARGUMENT

Interoperability between programs and systems is key to software innovation. It allows systems to connect and individuals to apply knowledge and skills from one environment to another. By easing the way for software developers to build upon existing platforms, interoperability allows efficient software ecosystems to grow, fueling the development of innovative new products and services and increasing competition to the benefit of consumers.

Copyright’s foundational rules—including its carefully crafted limitations on copyrightability—are fundamental to the efficient development of interoperable systems. At least since Baker v. Selden was decided in 1879, it has been firmly established that copyright law extends only to creative expression and not to ideas. 101 U.S. 99 (1879). Similarly, copyright protection does not extend to methods of operation, procedures, processes, or systems. 17 U.S.C. § 102(b). Because they preserve the availability of the basic building blocks required to create communication between systems, these limitations are essential to ensuring that interoperability remains a reliable feature of software development. In turn, the resulting software ecosystems and platforms undergird rapid innovation in beneficial new products and services.

Regardless of the mix of intellectual property rights on which they choose to rely, innovators and their investors need certainty about how copyright applies to

2

computer programs. In this case, the district court properly ruled that the elements of the Java APIs at issue are not copyrightable. It correctly recognized that these elements instead constitute “methods of operation” that allow developers to access functions within the Java programming language itself. Under this ruling, computer programs remain covered by the same carefully crafted copyright protection that has been in place for the past thirty years. Oracle’s preferred analysis, Opening Br. and Addendum of Pl.-Appellant 31–34 (“Appellant’s Br.”), if adopted whole or in part, would upset this stable regime and drastically expand copyrightability. This would not only limit innovators’ ability to develop interoperable systems—it would also introduce uncertainty into longstanding software development practices and investment in software innovation. Maintaining the conditions—including stable and balanced copyright rules—that enable software innovation also means maintaining strongly interoperable systems and competitive markets. The case at hand is a case in point. The number of start-up software companies has dramatically increased over the last decade as it has become comparatively easier to transform an idea into reality, in significant part because of the interoperability fueled by APIs. By creating a communicative interface between two software components,2 APIs allow start-ups to create programs that can communicate with and integrate the technology of

3

existing systems, powering development and increasing the programs’ usefulness. APIs therefore support rapid innovation and afford start-ups a greater chance at success, enabling angel investors, venture capitalists, and other investors to readily fund innovative ideas and help bring them to market.

Relatedly, interoperability is essential to maintaining robust competition in software development. Because it allows individuals to efficiently build programs and services that can communicate with and complement existing products, interoperability supports market entrance by new competitors. This accelerates the development of new uses, products, and services in a wide variety of fields, including both traditional and open source development, fueling competition.

Reversing the district court’s ruling would create uncertainty for software development that relies on APIs and development that feeds into interoperable systems more generally. This would harm what is presently a vital and robust industry, chilling both innovation and the investment that supports it. Amici therefore respectfully request that this Court affirm the district court’s decision in order to ensure that copyright remains in proper balance, supporting interoperability instead of restricting it, and allowing innovation to flourish.

__________
2 See James Gosling et al., The Java Application Programming Interface, Volume 1, xv–xx (1996).

4

As the brief states, "...Google replicated what was necessary to achieve a degree of interoperability." APIs make it possible for folks to access what they need to in order to interact and expand on the software -- that's what boosts innovation. Here's a brief part of that argument in this brief:
Indeed, interoperability -- whether created through controlled or “open” ecosystems -- is a foundational requirement of software innovation. To function, software programs must be able to interact with other computer software and hardware. Interoperability also allows customizations which connect to original software, expanding the software’s usefulness and its competitive value. ... APIs, specifically, create interoperability between programs and systems, giving start-up innovators the ability to connect to and build on what has come before. APIs facilitate this interaction between programs because they “provide access to functionality that is not easily achievable without the APIs . . . .” Jeffery Stylos & Brad Myers, Mapping the Space of API Design Decisions, 2007 IEEE Symposium on Visual Languages and Human-Centric Computing 51 (2007) (hereinafter “IEEE Report”). In fact, programmers often “must use the provided APIs because the implementation details are intentionally hidden” to protect intellectual property rights in protectable elements of interacting programs....

Software developers thus depend on APIs as a key method for achieving interoperability. The practice of creating via API-enabled platforms in turn depends on established limits to copyright protection. Indeed, start-ups, including many founded or funded by amici, can efficiently use APIs precisely because elements necessary to creating interoperability are not covered by copyright. The importance of these APIs to innovative software start-ups reflects the overall importance of preserving these limitations in copyright law....

Dramatically expanding copyright’s scope, as Oracle seeks to do, would upend this balance. If the elements of the Java API at issue here were held to be copyrightable, this would create uncertainty regarding other API elements long understood to be free from copyright protection. New copyright protections -- or uncertainty regarding the default rules of copyrightability -- could be used as a weapon to block innovation. Further, companies that presently provide complementary services by connecting to existing systems would be required instead to undertake a development process fully duplicative of the existing system, limiting offerings to consumers....

Because Oracle’s preferred interpretations, Appellant’s Br. at 31-34, would confuse well-settled law regarding protectable and unprotectable elements of computer programs more generally, see infra Section III, the uncertainty would also extend more generally into investment in computer software start-ups.

Destabilizing copyright limitations would thus also destabilize funding sources for software start-ups, disrupting their ability to bring innovative new products and services to market....Proper limitations on copyrightable subject matter are necessary for competition because they ensure that the facts, ideas, and other essential elements underlying copyrighted works are equally available to new market entrants and incumbents....

A program that uses the Java API calls upon a method in the API through the method’s header, which consists solely of the names of the method, class, and package the method is classified under: uncopyrightable features that must be operated for a program to use a function within the API.

I left out a footnote, but you can find Mapping the Space of API Design Decisions here.

The brief also highlights how important APIs are to FOSS companies and developers. While the brief approaches the issue from the positive standpoint that Open Source has shown the advantages of openness, it also mentions that if FOSS can't interoperate with proprietary software, the danger is obvious:

Importantly, OSS represents strong competitive alternatives in the software market. Samba, an OSS project, presents users with an important alternative way to connect Linux and Windows-based computers. Amicus Mozilla provides a variety of important OSS alternatives, including: the Firefox browser, Thunderbird e-mail client, the SeaMonkey Internet application suite, and the FileZilla FTP client. Word processing software OpenOffice competes with Microsoft’s Word. Open source blogging platform WordPress is widely used; indeed, Microsoft now uses WordPress in place of its own Live Spaces offering.

In order to build a truly broad set of competitive alternatives, however, open source developers must be able to write code that interoperates with “proprietary” software—that is, software that is not licensed under open source terms. It is imperative that the methods of operation and other functional elements of the code remain available for use outside of proprietary licenses. Should this change, owners of market-dominant proprietary software would have more power to restrict the types of open source software that can communicate with their software. For example, OSS projects like the Firefox browser and OpenOffice rely on interacting with proprietary computer operating systems in order to compete with other programs. In the case of OpenOffice, this interaction directly allows competition with Microsoft’s proprietary Word product....

Open source and reliable open standards provide important examples of the stakes at issue for competition in this case, but these stakes apply more broadly. Expanding copyrightability beyond its traditional bounds to elements essential for communication between software––such as the Java API elements at issue here–– could create the type of “control points” that allow market incumbents to limit entrance by competitors more generally, slowing innovation and harming consumers. Regardless of their business models, developers would be limited in their ability to connect competing products to existing networks, harming competition.

Does that not explain what this case is all about? But there is another issue -- APIs matter to the cloud:
Millions of users employ cloud services to store backups, access web-based applications, and provide services or content. Start-ups like those supported by the investor amici often leverage cloud platforms’ services—usually via APIs—to achieve scalability that would not be possible using in-house systems.

Competition in the burgeoning cloud services market depends, in part, on copyright limitations. Cloud services rely heavily on interoperability -- and specifically on APIs -- to work. If the elements of the Java API at issue were held to be copyrightable, the ensuing uncertainty would seriously undermine the active innovation and robust competition that are current features of the cloud market. See Robert McMillan, Could an Oracle Win Against Google Blow Up the Cloud?, Wired (June 15, 2012).

Do you understand now what Oracle is up to, and why it seems everyone who matters in the computer field is so focused on this litigation?

Update: I see Groklaw member tknarr has offered an analogy that might help everyone to understand:

An API is the computer equivalent of the gas pedal being on the right side of the brake pedal and the steering wheel turning left to turn the car left or right to turn the car right. Now, imagine a world where if Ford was the first auto maker to use that convention, no other car maker could build cars using it without permission from Ford. Does that world make sense?
It not only wouldn't make sense, it would be dangerous.

Here it is, as text:

*********************

In the

United States Court of Appeals
for the
Federal Circuit

______________

ORACLE AMERICA, INC.,
Plaintiff-Appellant,

v.

GOOGLE INC.,
Defendant-Cross Appellant.

_________________

On Appeal from the United States District Court for the Northern District of California
in case no. 10-CV-3561, Judge William H. Alsup.

_______________

BRIEF AMICI CURIAE OF SOFTWARE INNOVATORS, START-UPS,
AND INVESTORS IN SUPPORT OF AFFIRMANCE

______________

JENNIFER M. URBAN, ESQ.
Counsel of Record
SAMUELSON LAW, TECHNOLOGY
AND PUBLIC POLICY CLINIC
U.C. BERKELEY SCHOOL OF LAW
[address, phone, fax ] Attorney for Amici Curiae

May 30, 2013

On the brief:
Christopher Civil
Michael Liu Su
Clinical Student Interns

Amici Curiae Software Innovators, Start-ups, and Investors:

Apiary, Inc.

Azavea, Inc.

Daniel Bricklin

Bright Funds, Inc.

Esther Dyson

EDventure Holdings

Engine Advocacy

fasterlighterbetter d/b/a Copper

Foundry Group

Robert Glushko

Hattery

Mitchell Kapor

Katkar Flink Corporation d/b/a Hipiti

Mozilla Corporation

Tim O'Reilly

Raymond Ozzie

Union Square Ventures, LLC

Zubhium, Inc. d/b/a Vessel

CERTIFICATE OF INTEREST

Pursuant to Federal Circuit Rules 29(a) and 47.4, counsel for Amici Curiae certifies that:

1. The full names of every party or amicus represented in the case by me are:

See attachment to Certificate of Interest.

2. The name of the real party in interest (if the party named in the caption is not the real party in interest) represented by me is:

N/A

3. All parent corporations and any publicly held companies that own 10 percent or more of stock of any party or amicus curiae represented by me are:

Mozilla Foundation is the parent corporation of Mozilla Corporation.

4. The names of all law firms and the partners or associates that appeared for a party or amicus now represented by me in the trial court or are expected to appear in this Court are:

Jennifer M. Urban
Samuelson Law, Technology and Public Policy Clinic
U.C. Berkeley School of Law

Signed: /s/ Jennifer M. Urban
Jennifer M. Urban
Counsel of Record
Attorney for Amici Curiae

Dated: May 30, 20013

i

ATTACHMENT TO CERTIFICATE OF INTEREST
LIST OF AMICI CURIAE

(In alphabetical order -- descriptions available at
http://www.law.berkeley.edu/amici.htm)

1. Apiary, Inc.

2. Azavea, Inc.

3. Daniel Bricklin

4. Bright Funds, Inc.

5. Esther Dyson

6. EDventure Holdings

7. Engine Advocacy

8. fasterlighterbetter d/b/a Copper

9. Foundry Group

10. Robert Glushko

11. Hattery

12. Mitchell Kapor

13. Katkar Flink Corporation d/b/a Hipiti

14. Mozilla Corporation

15. Tim O'Reilly

16. Raymond Ozzie

17. Union Square Ventures, LLC

18. Zubhium, Inc. d/b/a Vessel

ii

TABLE OF CONTENTS

CERTIFICATE OF INTEREST......................... i

TABLE OF AUTHORITIES...................v

INTEREST OF AMICI........................................1

SUMMARY OF ARGUMENT.............................2

ARGUMENT...............................................5

I. Longstanding Limitations on Copyrightability Protect Software Innovation
by Start-up Companies. ......................................5
A. Start-up Software Companies Are Key Drivers of Innovation. ..................5

B. Start-up Innovation Depends on Interoperability Between Systems
and Programs................... ...........................6

C. Appropriate Limits on the Copyrightability of API Features Foster
Interoperability, Fueling Innovation.........................8

1. Start-up Software Development Relies on the Use of APIs. ....................8

2. Reversing the District Court's Ruling Would Introduce
Legal Uncertainty to the Use of APIs, Harming Start-ups' Ability
to Cumulatively Innovate...........................11

3. Reversing the District Court's Ruling Would Chill Investment
and Harm Start-ups' Ability to Obtain Funding........................12

II. Longstanding Limitations on Copyrightability Protect and Encourage
Competition in Software Innovation............................15
A. Appropriate Limitations on Copyrightability Are Essential
to Competitive Markets.....................................16
1. Clear and Reliable Copyrightability Limitations Allow Market
Entrants to Participate Effectively in Existing Networks and Innovate
on Top of Existing Platforms.................................16

2. Open Source Development and Open Standards Demonstrate
the Need for Clear Copyright Limitations to Support and Fuel Competitive
Market Alternatives............................17

3. Appropriate Limitations on Copyrightability Encourage Competition
by Preventing Consumer Lock-In..................................22

iii

B. Appropriate Limits on Copyrightability Are Necessary to Ensure
that Future Competitive Products and Services Can Develop. .........................23
III. The District Court Properly Applied Established Copyrightability
Limits and Correctly Separated Protectable Creative Expression from
Unprotectable Elements.................................25
A. Reversing the District Court's Ruling Would Upset a Longstanding
and Carefully Constructed Balance for Copyright Protection in Computer
Programs.................................26

B. The Elements of the Java APIs at Issue in this Case Are
Uncopyrightable Methods of Operation...........................27

C. The Elements of the Java APIs at Issue in this Case Are Uncopyrightable
Because They Are Dictated by Efficiency and Interoperability.................29

CONCLUSION..............................31

CERTIFICATE OF SERVICE & CM/ECF FILING...............................33

CERTIFICATE OF COMPLIANCE..................................38

iv

TABLE OF AUTHORITIES

Page(s)

CASES

Baker v. Selden
101 U.S. 99 (1879)......................................... 2, 31

Computer Assocs. Int'l, Inc. v. Altai, Inc.
982 F.2d 693 (2d Cir. 1992) ............................................. passim

Hutchins v. Zoll Medical Corp.
492 F.3d 1377 (Fed. Cir. 2007) ..................................... 23

Incredible Techs., Inc. v. Virtual Techs., Inc.
400 F.3d 1007 (7th Cir. 2005)..................... 23

Johnson Controls, Inc. v. Phoenix Control Sys., Inc.
886 F.2d 1173, 1175 (9th Cir. 1989) ................................ 25

Lexmark Int'l, Inc. v. Static Control Components, Inc.
387 F.3d 522 (6th Cir. 2004) ................................. . 23

Lotus Dev. Corp. v. Borland Int'l, Inc.
49 F.3d 807 (1st Cir. 1995) ...................................... passim

MiTek Holdings, Inc. v. Arce Engineering Co.
89 F.3d 1548 (11th Cir. 1996) .................................. 23

Oracle Am., Inc. v. Google Inc.
872 F. Supp. 2d 974 (N.D. Cal. 2012) ....................................... 6, 29, 30

SegaEnterprises Ltd. v. Accolade, Inc.
977 F.2d 1510 (9th Cir. 1992) ....................................... 17, 27, 30

Sony Computer Entm't, Inc., v. Connectix Corp.
203 F.3d 596 (9th Cir. 2000) .................................. 27, 30

v

STATUTES

17 U.S.C. § 102(b) ......................................... passim

OTHER AUTHORITIES

Legislative Materials:

Copyright Law Revision: Hearings on S. 597 Before the Subcomm. on Patents, Trademarks, and Copyrights of the S. Comm. on the Judiciary, 90th Cong. (1967).............................................. 26

H.R. Rep. No. 94-1476 (1976)......................... 26

Books, Treatises, and Reports:

Architecting the Internet of Things (Dieter Uckelmann, Mark Harrison and & Florian Michahelles eds. 2011)........................... 25

Ariel Katz, Copyright and Competition Policy , forthcoming in Handbook of the Digital Creative Economy (Christian Handke and Ruth Towse, eds. 2013).......... 15

Eric von Hippel, Democratizing Innovation (2006)...................................... 22

Fern Halper, Judith Hurwitz, & Marcia Kaufman, A Web API Study: The Benefits of APIs in the App Economy (2011)...................................... 8

James Gosling et al., The Java Application Programming Interface, Volume 1 (1996)................................................ 3

Jeffery Stylos & Brad Myers, Mapping the Space of API Design Decisions,
2007 IEEE Symposium on Visual Languages and Human-Centric
Computing (2007)...............................7

Jonathan Band, Interfaces on Trial 2.0 (2011)...............................16

National Venture Capital Association, Yearbook 2013 (2013) ..............................13

Paul Goldstein, Goldstein on Copyright (2005) ............................... 11

vi

RFID Working Group Of The European Technology Platform On Smart Systems
Integration, Internet of Things in 2020 (2008)............................... 24, 25

Tim Kane, Ewing Marion Kauffman Foundation, The Importance of Start-ups in Job Creation and Job Destruction (2010) ................................. 5

Tim O'Reilly, The Open Source Paradigm Shift, in Perspectives on Free
and Open Source Software
461 (J. Feller, B. Fitzgerald, S. Hissam, &
K. R. Lakhani, eds., 2007).....................................18

Urs Gasser & John Palfrey, Interop: The Promise and Perils of Highly
Connected Systems
(2012) .................................... 6, 7 World Economic Forum, Technology Pioneers 2013 (2013) ................... 5

News, Periodicals, and Journal Articles:

Adam DuVander, 7,000 APIs: Twice as Many as This Time Last Year,
ProgrammableWeb (Aug. 23, 2012) ............................ 10, 11

Darian M. Ibrahim, The (Not So) Puzzling Behavior of Angel Investors,
61 Vand. L. Rev. 1405 (2008).............................. 13

Doreen Bloch, 4 Reasons to Develop an API, Bootstrappist (April 9, 2012) ....... 10

Kevin Ashton, That 'Internet of Things' Thing, RFID Journal (June 22, 2009)...................................... 24

Michael A. Carrier, Copyright and Innovation: The Untold Story,
2012 Wis. L. Rev. 891 (2012) ............................. 14

Nicholas Carlson, Apple Has ~7,000 Fewer People Working On Maps Than Google, Business Insider (Sept. 21, 2012) ........................................... 10

Pamela Samuelson, Why Copyright Law Excludes Systems and Processes from the
Scope of Its Protection
, 85 Tex. L. Rev. 1921 (2007) ........................... 27, 31

Richard Rothwell, Creating Wealth With Free Software, Free Software Magazine
(Aug. 5, 2008)................... .............. 18

vii

Robert McMillan, Could an Oracle Win Against Google Blow Up the Cloud?, Wired (June 15, 2012) .................................... 24

Samuel Kortum & Josh Lerner, Assessing the Contribution of Venture Capital to Innovation, RAND Journal of Economics (2000) ................................ 13

Who Owns the Perk in Java?, The Economist Blog (May 8, 2012) ...................... 16

Web Pages:

Amazon services, Selling on Amazon Guide to XML ........................... 21

Basecamp home page........................... 9

Bump home page................................ 9

Copper home page.............................. 9

CoverPages.org, XML Applications and Initiatives .................... 20

Disqus home page..................................... 9

Last.fm home page..................................... 9

Microsoft Kinect ....................................... 9

Mozilla Products.................................... 19

Open Office home page.................................. 19

Open Source Initiative, The Open Source Definition ....................... 18

OpenSearch home page.................................. 9

ProgrammableWeb API Directory ..................... 11

Samba home page...................................... 18

Simple Finance Technology Corp................................... 9

viii

W3C Standards, XML Open Status............................ 20

WallIt home page................................. 10

WordPress home page............................... 19

ix

INTEREST OF AMICI 1

Amici are software innovators, start-ups, and investors. The signatories on this brief include innovators, and founders of software and Internet companies that actively innovate in and compete across a wide array of markets. Signatories also include investors who invest in, and are expert in assessing the risks of investing in, companies that rely on APIs and other interoperability tools. Amici have broad first-hand experience in the role of interoperability--and the balanced and stable copyright rules on which it depends--in driving innovation in the technology sector. A full list of amici with individual descriptions can be found at
http://www.law.berkeley.edu/amici.htm.

Amici's shared interest in this case is in preserving the deliberate balance Congress and the courts have established for software copyright, including longstanding limits on copyrightability that enable innovation by fostering interoperability and competition. Amici join to explain the importance to innovation and investment in innovation of upholding the District Court's careful application of these limitations to the Java API elements at issue in this case.

1

SUMMARY OF ARGUMENT

Interoperability between programs and systems is key to software innovation. It allows systems to connect and individuals to apply knowledge and skills from one environment to another. By easing the way for software developers to build upon existing platforms, interoperability allows efficient software ecosystems to grow, fueling the development of innovative new products and services and increasing competition to the benefit of consumers.

Copyright's foundational rules--including its carefully crafted limitations on copyrightability--are fundamental to the efficient development of interoperable systems. At least since Baker v. Selden was decided in 1879, it has been firmly established that copyright law extends only to creative expression and not to ideas. 101 U.S. 99 (1879). Similarly, copyright protection does not extend to methods of operation, procedures, processes, or systems. 17 U.S.C. § 102(b). Because they preserve the availability of the basic building blocks required to create communication between systems, these limitations are essential to ensuring that interoperability remains a reliable feature of software development. In turn, the resulting software ecosystems and platforms undergird rapid innovation in beneficial new products and services.

Regardless of the mix of intellectual property rights on which they choose to rely, innovators and their investors need certainty about how copyright applies to

2

computer programs. In this case, the district court properly ruled that the elements of the Java APIs at issue are not copyrightable. It correctly recognized that these elements instead constitute "methods of operation" that allow developers to access functions within the Java programming language itself. Under this ruling, computer programs remain covered by the same carefully crafted copyright protection that has been in place for the past thirty years. Oracle's preferred analysis, Opening Br. and Addendum of Pl.-Appellant 31-34 ("Appellant's Br."), if adopted whole or in part, would upset this stable regime and drastically expand copyrightability. This would not only limit innovators' ability to develop interoperable systems--it would also introduce uncertainty into longstanding software development practices and investment in software innovation.

Maintaining the conditions--including stable and balanced copyright rules--that enable software innovation also means maintaining strongly interoperable systems and competitive markets. The case at hand is a case in point. The number of start-up software companies has dramatically increased over the last decade as it has become comparatively easier to transform an idea into reality, in significant part because of the interoperability fueled by APIs. By creating a communicative interface between two software components,2 APIs allow start-ups to create programs that can communicate with and integrate the technology of

3

existing systems, powering development and increasing the programs' usefulness. APIs therefore support rapid innovation and afford start-ups a greater chance at success, enabling angel investors, venture capitalists, and other investors to readily fund innovative ideas and help bring them to market.

Relatedly, interoperability is essential to maintaining robust competition in software development. Because it allows individuals to efficiently build programs and services that can communicate with and complement existing products, interoperability supports market entrance by new competitors. This accelerates the development of new uses, products, and services in a wide variety of fields, including both traditional and open source development, fueling competition.

Reversing the district court's ruling would create uncertainty for software development that relies on APIs and development that feeds into interoperable systems more generally. This would harm what is presently a vital and robust industry, chilling both innovation and the investment that supports it. Amici therefore respectfully request that this Court affirm the district court's decision in order to ensure that copyright remains in proper balance, supporting interoperability instead of restricting it, and allowing innovation to flourish.

4

ARGUMENT

I. Longstanding Limitations on Copyrightability Protect Software
Innovation by Start-up Companies.

A. Start-up Software Companies Are Key Drivers of Innovation.

Start-up companies are vital to the American economy as a source of jobs, capital, and innovation. See Tim Kane, Ewing Marion Kauffman Foundation, The Importance of Startups in Job Creation and Job Destruction at 3 (2010) (describing the strong source of net job growth new companies provide).3 Indeed, American start-ups are the most innovative in the world, allowing them to fuel American markets both home and abroad. See World Economic Forum, Technology Pioneers 2013 at 9 (2013) (listing 13 American start-ups out of a total of 23 as the most innovative in the world).4

These companies are characterized by their ability to quickly turn an innovative idea into a product that benefits society. They have a storied history as a robust source of American innovation: economic powerhouses such as Apple, Microsoft, Google, Yahoo!, Intel, and Oracle itself all began as small start-ups. Today's start-ups, including companies funded by amici and amici start-ups themselves, continue to innovate new products and services that benefit every

5

sector of society. For example, amicus Copper has created a new way to compensate online content creators and amicus Bright Funds, simplified tools to donate to charities online. Amicus Foundry supports companies engaged in a wide array of sectors: Brightleaf offers automated legal documentation, MakerBot builds and sells 3D printers and scanners, PivotDesk connects start-ups with office space, and Sympoz provides an online learning community. Amicus Apiary helps other companies use APIs to provide a multitude of services.

Start-ups and their investors rely on copyright's default rules in order to innovate these new software products and services. As described further below, longstanding limitations on copyrightable subject matter, such as disallowing copyright protection for ideas, systems, and methods of operation, and limiting the protection of "functional elements essential for interoperability," provide foundational support for the innovation process. See Oracle Am., Inc. v. Google Inc., 872 F. Supp. 2d 974, 984 -- 998 (N.D. Cal. 2012).

B. Start-up Innovation Depends on Interoperability Between
Systems and Programs.

Importantly, copyright's traditional limitations support robust interoperability. Innovation in the software community flourishes because of interoperability. See Urs Gasser & John Palfrey, Interop: The Promise and Perils

6

of Highly Connected Systems 111-25 (2012) (finding that interoperability supports innovation in the context of information and communication technologies).

Indeed, interoperability--whether created through controlled or "open" ecosystems--is a foundational requirement of software innovation. To function, software programs must be able to interact with other computer software and hardware. Interoperability also allows customizations which connect to original software, expanding the software's usefulness and its competitive value. See id. at 118. APIs, specifically, create interoperability between programs and systems, giving start-up innovators the ability to connect to and build on what has come before. APIs facilitate this interaction between programs because they "provide access to functionality that is not easily achievable without the APIs . . . ." Jeffery Stylos & Brad Myers, Mapping the Space of API Design Decisions, 2007 IEEE Symposium on Visual Languages and Human-Centric Computing 51 (2007) (hereinafter "IEEE Report").5 In fact, programmers often "must use the provided APIs because the implementation details are intentionally hidden" to protect intellectual property rights in protectable elements of interacting programs. Id.

7

C. Appropriate Limits on the Copyrightability of API Features
Foster Interoperability, Fueling Innovation.

Software developers thus depend on APIs as a key method for achieving interoperability. The practice of creating via API-enabled platforms in turn depends on established limits to copyright protection. Indeed, start-ups, including many founded or funded by amici, can efficiently use APIs precisely because elements necessary to creating interoperability are not covered by copyright. The importance of these APIs to innovative software start-ups reflects the overall importance of preserving these limitations in copyright law.

1. Start-up Software Development Relies on the Use of APIs.

Start-ups depend on APIs to efficiently bring new ideas to the market. One study has found that software programs that implement APIs decrease the amount of time they take to bring products to market by 30%. See Fern Halper, Judith Hurwitz, & Marcia Kaufman, A Web API Study: The Benefits of APIs in the App Economy (2011).6 Indeed, there has been a rapid expansion of API service providers like amicus Apiary, which provides a platform, or "blueprint," for developers to quickly describe, document, test, and implement new APIs.

8

Start-ups7 depend on APIs in order to perform tasks that they otherwise would not be able to accomplish. For example, a start-up that integrates Twitter or Facebook services so that its users can communicate with their connections must use an API. Similarly, a start-up that allows its users to use a PayPal account to pay for goods and services must use an API. See IEEE Report at 51. Start-ups also use APIs because they contain the phrases and structures of code necessary to efficiently build innovative new products. In this vein, APIs increase efficiency by enabling programmers to build from existing code instead of "writing it from scratch." See IEEE Report at 53-54; see also Br. Amici Curiae Computer Scientists in Supp. of Def.-Cross Appellant and Affirmance.

APIs vary greatly in available features, allowing innovators to connect with existing systems to provide an enormous range of services. A very small sampling includes mobile payments,8 online discussion,9 web search,10 project management,11 banking,12 motion tracking,13 music,14 and information exchanges between mobile devices.15 By using APIs, start-ups can also provide valuable

9

enhancements that they otherwise could not offer consumers. For example, start-ups can use the Google Maps API to incorporate Google Maps into their applications. WallIt,16 for example, uses the Google Maps API to access location services and Google Street View. Without APIs like this one, most start-ups would likely be unable to include map features in their products, due to the complexity of the undertaking: Google needs over 7100 employees to build Google Maps. See Nicholas Carlson, Apple Has ~7,000 Fewer People Working On Maps Than Google, Business Insider (Sept. 21, 2012).17 The availability of APIs for labor-intensive products Google Maps thus fuels innovators' ability to complement the existing product and usefully enhance their own products.

Beyond these benefits, however, the availability of APIs is simply central to contemporary software innovation and program operation. See Doreen Bloch, 4 Reasons to Develop an API, Bootstrappist (April 9, 2012) ("No website, network or app is isolated . . . . Websites "talk" to one another through . . . APIs, sets of rules that developers use to facilitate communications among different platforms to share data structures, protocols, and more.")18; Adam DuVander, 7,000 APIs: Twice as Many as This Time Last Year , ProgrammableWeb (Aug. 23, 2012) ("If an

10

. . . app does anything interesting, it likely needs . . . an API.").19 The extent to which start-ups depend on APIs is exemplified by the fact that every start-up supported by amici Hattery and Foundry use at least one API.

Unsurprisingly, the number of available APIs is growing at a rapid pace, with hundreds of new APIs created every month. See DuVander, supra. One popular central listing currently indexes over 9100 APIs--a number that has grown from 7600 in just the seven months from October 2012 to May 2013. See ProgrammableWeb API Directory.20

2. Reversing the District Court's Ruling Would Introduce
Legal Uncertainty to the Use of APIs, Harming Start-ups'
Ability to Cumulatively Innovate.

Were Oracle's preferred rule adopted, API-fueled innovation--and indeed all software-based innovation--would be threatened. Start-ups depend on the fact that copyright is tailored to encourage cumulative innovation. The law "withholds copyright protection from creative building blocks . . . to stimulate the production of the most abundant possible array of . . . expression." Paul Goldstein, Goldstein on Copyright, § 2.3.1.1.

11

Start-ups following the API-supported model of development described above--and indeed all innovators--depend on the availability of these building blocks in their practice. Dramatically expanding copyright's scope, as Oracle seeks to do, would upend this balance. If the elements of the Java API at issue here were held to be copyrightable, this would create uncertainty regarding other API elements long understood to be free from copyright protection. New copyright protections--or uncertainty regarding the default rules of copyrightability--could be used as a weapon to block innovation. Further, companies that presently provide complementary services by connecting to existing systems would be required instead to undertake a development process fully duplicative of the existing system, limiting offerings to consumers.

Faced with such uncertainty, start-ups may hold off from developing and using APIs, resulting in a significant loss in innovation. As discussed further in the next section, this concern is heightened by the fact that start-ups are especially sensitive to the economic costs of such uncertainty and its effects on their ability to generate funding.

3. Reversing the District Court's Ruling Would Chill
Investment and Harm Start-ups' Ability to Obtain Funding.

Start-ups need money to turn ideas into reality. Angel, venture capital, and other investors are important sources of this funding and play a significant role in

12

bringing new innovations to society. See Samuel Kortum & Josh Lerner, Assessing the Contribution of Venture Capital to Innovation, RAND Journal of Economics (2000) (Finding that increases in venture capital funding in a sector are associated with statistically significant higher rates of innovation). In 2012 alone, venture capital firms made over $4 billion of initial investments in 1,174 companies, largely at the crucial "seed- and early-stage" of their development paths. National Venture Capital Association, Yearbook 2013 at 13-14 (2012) (out of a total of $26.7 billion invested in 3,143 companies)21; see also Darian M. Ibrahim, The (Not So) Puzzling Behavior of Angel Investors, 61 Vand. L. Rev. 1405, 1407 (2008) (discussing the boosts to employment and gross domestic product that investor-backed firms have provided in the 2000s).

Investors like amici are more likely to fund start-ups that can rely on APIs. An idea that can make use of already-developed features requires less initial footwork and thus stands a higher chance of coming to market. A start-up that uses APIs can come to market on as little as a few hundred dollars, compared to the millions of dollars required for conventional software development. Moreover, start-ups that use APIs benefit from a greater ability to connect with existing markets. By making it possible for new products to connect to existing software

13

ecosystems, APIs reduce the time it takes to bring an innovative new idea to the market. These efficiencies translate into lower business risk and make successful market entry more likely. Investors are thus more willing to fund software start-ups that can use APIs; this is especially true for early-stage investments.

Should the fundamental copyrightability rules related to APIs shift as Oracle requests, however, software developers and their investors would face a new source of uncertainty and litigation threats. This would harm investment in start- ups that use APIs: investors are much less likely to invest if they fear that their investments will go towards copyright litigation. See Michael A. Carrier, Copyright and Innovation: The Untold Story, 2012 Wis. L. Rev. 891, 916 (2012) (describing how past copyright infringement threats have created "wastelands" of technology fields due to lack of venture capital funding). For example, investors backed away from the entire field of technology involving online music downloading following a small but significant number of adverse copyright infringement cases. See id. Further, these negative effects would not be limited to investment in API-fueled software innovation. Because Oracle's preferred interpretations, Appellant's Br. at 31-34, would confuse well-settled law regarding protectable and unprotectable elements of computer programs more generally, see infra Section III, the uncertainty would also extend more generally into investment in computer software start-ups.

14

Destabilizing copyright limitations would thus also destabilize funding sources for software start-ups, disrupting their ability to bring innovative new products and services to market.

II. Longstanding Limitations on Copyrightability Protect and Encourage
Competition in Software Innovation.

Destabilizing copyright limitations would also undercut the competitive benefits software innovators bring to markets. Proper limitations on copyrightable subject matter are necessary for competition because they ensure that the facts, ideas, and other essential elements underlying copyrighted works are equally available to new market entrants and incumbents. See generally Ariel Katz, Copyright and Competition Policy, forthcoming in Handbook of the Digital Creative Economy (Christian Handke and Ruth Towse, eds. 2013). 22

The scope of copyright in computer programs has practical effects on competition because participation in these networks requires interoperability: certain elements of the communicated information must be the same on both sides of the exchange. The Java API aspects at issue here comprise such elements and functions. As discussed below, these elements have long been considered uncopyrightable. Expanding copyright as Oracle requests would dramatically increase incumbents' ability to use copyright to limit competition by preventing

15

newcomers from accessing established systems and from innovating on top of older ideas.

This poses a clear and recognized threat to open competition within markets. See, e.g., Who Owns the Perk in Java? , The Economist Blog (May 8, 2012) (noting that "many tech types are jittery about a verdict fully in favour of Oracle" because "[e]quivalent API functions based on distinct source code abound across all aspects of hardware, software and services, on the [I]nternet and offline" and cautioning that accepting Oracle's argument could "reshape the nature of technological development."). 23

A. Appropriate Limitations on Copyrightability Are Essential to
Competitive Markets.

1. Clear and Reliable Copyrightability Limitations
Allow Market Entrants to Participate Effectively in
Existing Networks and Innovate on Top of Existing
Platforms.

Were Oracle to succeed in its request to expand copyrightability, the ensuing damage to interoperability would represent a serious setback to market entrants’ ability to replace or compete alongside existing products. See Jonathan Band, Interfaces on Trial 2.0 1-5 (2011) (explaining that interoperability enables both communication between platforms and replacement of products by competitors).

16

To achieve a truly competitive market, software programs must be able to communicate effectively with other programs. Copyright law reflects this understanding in the limits to its protection for software. InComputer Assocs. Int'l, Inc. v. Altai, Inc., 982 F.2d 693, 709-10 (2d Cir. 1992), the Second Circuit stated that program elements dictated by factors such as "compatibility requirements of other programs with which a program is designed to operation in conjunction" are beyond copyright's scope of protection. The Ninth Circuit similarly held in Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992) that interface features required for interoperability were functional elements unprotectable under § 102(b). With these rules in place, innovators can take advantage of and further develop robustly interoperable systems, fueling competition. Without them, a few market incumbents could introduce "control points" to create barriers for market newcomers.

2. Open Source Development and Open Standards
Demonstrate the Need for Clear Copyright
Limitations to Support and Fuel Competitive Market
Alternatives.

Open source software (OSS) development and open technological standards each provide important examples of how innovation flourishes when interoperability is strong, and of how introducing "control points" can limit competition. OSS development follows a collaborative innovation model that

17

maximizes interoperability between programs by using open licenses. The licenses ensure developers can modify and redistribute the program's source code, maximizing interoperability and follow-on development. See Open Source Initiative, The Open Source Definition.24

Via this model, OSS innovation has transformed the technology industry by injecting highly innovative programs into the software market. Open source can be found at every level of systems, including operating systems (Linux), databases (MySQL), web server software (Apache), Internet browsers (Firefox), word processing programs (OpenOffice), and programming languages (Perl). OSS makes up virtually the entire backbone of the Internet. See, e.g., Tim O'Reilly, The Open Source Paradigm Shift, in Perspectives on Free and Open Source Software 461 (J. Feller, B. Fitzgerald, S. Hissam, & K. R. Lakhani, eds., 2007). By some estimates, OSS returns savings of $60 billion annually to software users. See Richard Rothwell, Creating Wealth With Free Software, Free Software Magazine (Aug. 5, 2008).25

Importantly, OSS represents strong competitive alternatives in the software market. Samba,26 an OSS project, presents users with an important alternative way to connect Linux and Windows-based computers. Amicus Mozilla provides a

18

variety of important OSS alternatives, including: the Firefox browser, Thunderbird e-mail client, the SeaMonkey Internet application suite, and the FileZilla FTP client.27 Word processing software OpenOffice28 competes with Microsoft's Word. Open source blogging platform WordPress29 is widely used; indeed, Microsoft now uses WordPress in place of its own Live Spaces offering.

In order to build a truly broad set of competitive alternatives, however, open source developers must be able to write code that interoperates with "proprietary" software--that is, software that is not licensed under open source terms. It is imperative that the methods of operation and other functional elements of the code remain available for use outside of proprietary licenses. Should this change, owners of market-dominant proprietary software would have more power to restrict the types of open source software that can communicate with their software. For example, OSS projects like the Firefox browser and OpenOffice rely on interacting with proprietary computer operating systems in order to compete with other programs. In the case of OpenOffice, this interaction directly allows competition with Microsoft's proprietary Word product.

Technologies provided as open standards similarly fuel innovation and competition by enhancing interoperability. For example, in retail markets,

19

companies historically communicated to each other via proprietary systems that were limited in the syntax of their messaging and undecipherable to outside parties. This added cost and complexity to placing products from new market entrants into stores. By using the extensible markup language (XML) to design a set of information components commonly used in business transaction documents (like "party", "item", "address", etc.) and specifying the rules for combining them, amicus Glushko and others created a set of documents that made business information exchanges more efficient. They called their XML language the Common Business Language, and today its successor, the Universal Business Language, contains scores of standard business documents used in many business systems all over the world.

Today, XML is an open standard that has been used to create thousands of such domain-specific languages. See W3C Standards, XML Open Status.30 It is the default format for Microsoft Office, Open Office, and Apple iWork, and for critical Web services systems such as RSS and XHTML. See CoverPages.org, XML Applications and Initiatives.31 Amazon has adopted XML for the Amazon Marketplace platform, which serves thousands of merchants and is the largest marketplace of its kind, to facilitate sales by individual merchants in the Amazon

20

online store. See Amazon Services, Selling on Amazon Guide to XML.32 This boosts competition and brings beneficial products to consumers.

In order for XML to continue to provide these benefits, however, users must be able to rely on the rules that dictate its use. This includes both its ongoing status as an open standard, and on the underlying rules that dictate which of its elements are copyrightable. Preserving limits on copyrightability allows this certainty and prevents centralizing control of XML after-the-fact--precisely what Oracle has attempted with the Java APIs at issue in this case. If users of XML had not been able to rely on the rules surrounding its use, it could not have enabled the broad interoperability--and the competition and innovation--that it supports today.

Open source and reliable open standards provide important examples of the stakes at issue for competition in this case, but these stakes apply more broadly. Expanding copyrightability beyond its traditional bounds to elements essential for communication between software -- such as the Java API elements at issue here -- could create the type of "control points" that allow market incumbents to limit entrance by competitors more generally, slowing innovation and harming consumers. Regardless of their business models, developers would be limited in their ability to connect competing products to existing networks, harming competition.

21

3. Appropriate Limitations on Copyrightability
Encourage Competition by Preventing Consumer
Lock-In.

For a competitive marketplace to function, consumers must be able to switch between products without substantial detriment. As described above, clear and stable limitations on copyrightability can help keep markets competitive, ensuring that consumers can choose among products.

Consumers should also be able to transfer time and skills they invest into commercial products without then being then locked into that particular product. Consumers commonly engage in their own innovation on top of existing products they own. See Eric von Hippel, Democratizing Innovation at 4 (2006) (cataloguing instances of end-user innovation and explaining that empirical studies show that as many as 40 percent of users engage in modifying products). End-user innovation makes products more useful and valuable to their owners. It also creates broader benefits by spurring product improvement, especially where features or uses do not present justifiable investments for corporations.

But valuable user investments become sunk costs -- and increase lock-in -- if user-innovators cannot then transfer their innovations to another product choice. For example, such a situation could have occurred with the spreadsheet macros at issue in Lotus Dev. Corp. v. Borland Int'l, Inc., 49 F.3d 807, 814 (1st Cir. 1995). Macros are sequences of stored commands created by a user to automatically

22

instruct a computer program. Lotus 1-2-3, one of the first spreadsheet programs, allowed users to create macros through its menu command hierarchy. Lotus 1-2-3 customers implemented their own innovations on the Lotus platform by creating macros.

For those who wanted to move to Borland's competing spreadsheet, these user innovations could have been thwarted by Lotus's attempt to expand copyrightability by claiming copyright in the 1-2-3 menu command hierarchy. However, as the court noted, "Original developers are not the only people entitled to build on the methods of operation they create; anyone can." Lotus, 49 F.3d at 818. Because the hierarchy was correctly recognized as an uncopyrightable method of operation, Lotus at 815, user-innovators could avoid lock-in and choose other spreadsheet programs on which to run their macros.33

B. Appropriate Limits on Copyrightability Are Necessary to Ensure
that Future Competitive Products and Services Can Develop.

One of the most important benefits copyright's traditional limitations provide is protecting technical innovations that are in the very early stages--or still beyond the horizon. For example, "cloud services" employ computing resources

23

that are delivered as a service over the Internet, allowing both business and individual users to expand computing power and storage capacity. Millions of users employ cloud services to store backups, access web-based applications, and provide services or content. Start-ups like those supported by the investor amici often leverage cloud platforms' services -- usually via APIs -- to achieve scalability that would not be possible using in-house systems.

Competition in the burgeoning cloud services market depends, in part, on copyright limitations. Cloud services rely heavily on interoperability--and specifically on APIs--to work. If the elements of the Java API at issue were held to be copyrightable, the ensuing uncertainty would seriously undermine the active innovation and robust competition that are current features of the cloud market. See Robert McMillan, Could an Oracle Win Against Google Blow Up the Cloud?, Wired (June 15, 2012).34

Another developing platform, this one still just over the horizon, is the so-called "Internet of things" -- the networking of devices and objects via the Internet. See Kevin Ashton, That 'Internet of Things' Thing, RFID Journal (June 22, 2009).35 Virtually any device or object -- from smartphones to supply-chain tags to automobiles to home appliances -- can provide and receive information through the Internet. See RFID Working Group Of The European Technology Platform On

24

Smart Systems Integration, Internet of Things in 2020 5-7 (2008).36 Commentators note that this promises numerous benefits to society, such as automated cars, "smart" supply chains, and consumer electronics that monitor power consumption and track and replace household items as they run low. See Architecting the Internet of Things (Dieter Uckelmann, Mark Harrison and & Florian Michahelles eds. 2011).37 Preserving the robust interoperability required to build such a diverse and expansive network--and the innovation and investment needed for that building--requires exactly the kind of certainty about copyright's parameters implicated by this case.

III. The District Court Properly Applied Established Copyrightability
Limits and Correctly Separated Protectable Creative Expression from
Unprotectable Elements.

The scope of copyright protection for computer programs has always been carefully and purposefully limited. As noted in Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989), "[w]hether a particular component of a program is protected by a copyright depends on whether it qualifies as an 'expression' of an idea, rather than the idea itself." And to be copyrightable, elements of a computer program must not fall under important

25

statutory categories, such as procedures, processes, systems, and methods of operation. 17 U.S.C. -- 102(b). Reversing the district court's ruling would represent a dramatic shift in copyright law, as it would extend protection beyond current limitations that were carefully crafted to protect innovation.

A. Reversing the District Court's Ruling Would Upset a
Longstanding and Carefully Constructed Balance for Copyright
Protection in Computer Programs.

Legislators and courts have consistently voiced grave concern that overly broad copyright protection for computer programs would hinder innovation. Section 102(b) was the result of strong witness opinions in Senate hearings advocating for careful statutory demarcation around the scope of copyright if it were to be extended to computer programs. See Copyright Law Revision: Hearings on S. 597 Before the Subcomm. on Patents, Trademarks, and Copyrights of the S. Comm. on the Judiciary, 90th Cong. 1059 (1967) (hereinafter Senate Copyright Hearings) (statement of W. Brown Morton, Jr.). The House Report accompanying -- 102(b) similarly noted the importance of properly delimiting the copyrightability of computer programs. See H.R. Rep. No. 94-1476 at 56 -- 57 (1976).

Section 102(b) was directly intended to address these concerns. See Senate Copyright Hearings at 969 -- 74 (testimony of Arthur A. Miller); H.R. Rep. No. 94-1476 at 56 -- 57 ("Section 102(b) is intended, among other things, to make clear that

26

the expression adopted by the programmer is the copyrightable element in a computer program, and that the actual processes or methods embodied in the program are not within the scope of the copyright law."); see also Pamela Samuelson, Why Copyright Law Excludes Systems and Processes from the Scope of Its Protection, 85 Tex. L. Rev. 1921, 1944 -- 55 (2007).

Courts have also addressed such concerns, by policing copyrightability limits for computer programs, including limitations that specifically support interoperability.38 See 17 U.S.C. § 102(b); Sony Computer Entm't, Inc., v. Connectix Corp., 203 F.3d 596, 602 (9th Cir. 2000); Lotus, 49 F.3d at 815; Altai, 982 F.2d at 707-08; Sega, 977 F.2d at 1522.

B. The Elements of the Java APIs at Issue in this Case Are
Uncopyrightable Methods of Operation.

Among other benefits, keeping copyrightability limitations stable preserves certainty for innovators and prevents elements essential to basic interoperability from becoming the "control points" described above in Section II.

Lotus v. Borland provides a particularly relevant application of this principle. See 49 F.3d at 815. In Lotus, the court found that the menu command hierarchy of the spreadsheet program Lotus 1-2-3 was an uncopyrightable method

27

of operation because it was essential to making use of the program's functional capabilities. See id. The hierarchy did not "merely explain and present Lotus 1-2-3's functional capabilities to the user;" instead, it "serv[ed] as the method by which the program is operated and controlled." Id. The court stated that "if specific words are essential to operating something, then they are part of a 'method of operation' and, as such, are unprotectable." Id. at 816 (emphasis added).

Methods of operation do not themselves become copyrightable because they relate to some creative expression. See id. ("The 'expressive' choices of what to name the command terms and how to arrange them do not magically change the uncopyrightable menu command hierarchy into copyrightable subject matter."). Nor do available alternative design choices affect whether a program feature is a method of operation. Id. ("The fact that Lotus developers could have designed the Lotus menu command hierarchy differently is immaterial to the question of whether it is a 'method of operation.'")

The Java API elements at issue here are comparable to the menu hierarchy in Lotus: uncopyrightable because they constitute the method of operation through which a user's program accesses, controls, and makes use of the functional capabilities of the Java API. A program that uses the Java API calls upon a method in the API through the method's header, which consists solely of the names of the

28

method, class, and package the method is classified under: uncopyrightable features that must be operated for a program to use a function within the API.

C. The Elements of the Java APIs at Issue in this Case Are
Uncopyrightable Because They Are Dictated by Efficiency
and Interoperability.

In addition to being uncopyrightable as a method of operation, the elements of the Java API at issue are uncopyrightable as elements that are "dictated by efficiency," causing them to merge with the ideas underlying them. See Altai, 982 F.2d at 707. The court in Altai reasoned that since "efficiency is akin to deriving the most concise logical proof or formulating the most succinct mathematical computation . . . the more efficient a set of modules are, the more closely they approximate the idea or process embodied in that particular aspect of the program's structure." Id. at 708.

Here, the structure, sequence, and organization of the 37 Java API packages copied by Google act in exactly this way. Indeed, they were developed to maximize efficiency and facilitate software programming on the Java platform. Oracle, 872 F. Supp. 2d at 1000. As the district court recognized, "millions of lines of code" had been written in Java before the arrival of Google's Android operating system. Id. As a result, a great number of developers are well versed in designing programs on the Java platform. In order for some of these programs to correctly function and for developers to seamlessly across platforms, "Google was required

29

to provide the same . . . command system using the same names with the same 'taxonomy' and with the same functional specifications." Id.

Similarly, Google replicated what was necessary to achieve a degree of interoperability. Id. In ruling that the command structure of the Java API at issue is an uncopyrightable method of operation, Judge Alsup properly noted the importance of the fact that "[d]uplication [of the structure] is necessary for interoperability." Oracle, 872 F. Supp. 2d at 977. In the Ninth Circuit, which controls here, Section 102(b) bars from copyright protection software interfaces necessary for interoperability. In Sega, elements of the Sega video game interface necessary for "compatibility" -- i.e., interoperability -- were functional aspects not copyrightable under Section 102(b). Id. at 1522 ("Accolade copied Sega's software solely in order to discover the functional requirements for compatibility with the Genesis console--aspects of Sega's programs that are not protected by copyright. 17 U.S.C. § 102(b)."). Likewise, in Connectix, functional elements that established interoperability with the Sony Playstation's operating software were unprotected. Connectix, 203 F.3d 596.39

30

No part of this legal framework is new. It has been well-established for over 130 years that the idea behind an original expression is uncopyrightable. Baker v. Selden, 101 U.S. at 103. Section 102(b) is a key feature of the 1976 Copyright Act. Altai provides the standard approach courts apply in determining the copyrightability of elements of computer programs and filtering out unprotectable procedures, processes, systems, and methods of operation. See Samuelson, supra at 1973 (stating that as of 2006 Altai has been followed in 49 subsequent cases). Oracle's attempts to characterize the district court decision as using unreliable precedent to develop a novel formulation of copyrightability limits for computer software, Appellant's Br. at 60-6, are simply incorrect. See also Br. Amici Curiae Intellectual Property Professors in Supp. of Def.-Cross Appellant and Affirmance.

It is the changes to well-settled limitations on copyright in computer programs that would disrupt the existing framework and create uncertainty for innovators and their investors alike.

CONCLUSION

A stable, properly balanced regime of copyright protections and limitations is required for innovation and investment in the software sector to continue to flourish. Oracle's attempt to redraw established boundaries around copyright protection for software programs would introduce chilling uncertainty into software development. It would call into question innovators' ability to use widely

31

available API elements necessary for interoperability, and would introduce further uncertainty regarding the scope of copyright protection for computer programs in general. The district court prevented this result by correctly applying copyright's clear, longstanding limits on copyrightability. This Court should affirm.

Respectfully Submitted,

May 30, 2013

/s/ Jennifer M. Urban
Jennifer M. Urban
Samuelson Law, Technology and Public Policy
Clinic U.C. Berkeley School of Law
[address, phone, fax]
Counsel of Record

____________
1 Pursuant to Fed. R. App. P. 29(a), all parties have consented to the filing of this brief. No party's counsel authored this brief in whole or in part. No person (or party) other than amici, their members, or their counsel contributed money that was intended to fund preparing or submitting this brief. University of California, Berkeley law students Christopher Civil and Michael Liu Su assisted in the preparation of this brief. Web sites cited in this brief were last visited in May 2013.

2 See James Gosling et al., The Java Application Programming Interface, Volume 1, xv-xx (1996).

3 Available at www.kauffman.org/uploadedFiles/ firm_formation_importance_of_startups.pdf.

4 Available at www3.weforum.org/docs/ WEF_TP_PushingNewFrontiers_Report_2013.pdf.

5 Available at repository.cmu.edu/cgi/viewcontent.cgi?article= 1168&context=hcii.

6 Available at www.hurwitz.com/index.php/recent-research/cloud- computing/doc_details/128-web-api-study-the-benefits-of-apis- in-the-app-economy.

7 This is true of all software developers. See IEEE Report at 51.

8 See Copper Inc., http://www.copper.is.

9 See Disqus, http://www.disqus.com.

10 See OpenSearch, http://www.opensearch.org.

11 See Basecamp (37signals, LLC), http://basecamp.com.

12 See Simple Finance Technology Corp., http://www.simple.com.

13 See Microsoft Kinect, http://www.microsoft.com/en-us/kinectforwindows/.

14 See Last.fm LTD, http://www.last.fm.

15 See Bump Technologies, Inc., >http://bu.mp.

16 See WallIt, http://launch.wallitapp.com.

17 Available at http://www.businessinsider.com/ apple-has-7000-fewer-people-working-on-maps-than-google-2012-9#ixzz2O8dTBdXy.

18 Available at http://www.bootstrappist.com/ archives/4-reasons-to-develop-an-api/.

19 Available at http://blog.programmableweb.com/ 2012/08/23/7000-apis-twice-as-many-as-this-time-last-year/.

20 Available at http://www.programmableweb.com/apis/directory. Because an API can be created by anyone, with no need to catalogue its existence, the actual number of APIs is likely much higher than what is tracked in such indexes.

21 Available at http://www.nvca.org/index.php%3f option=com_content&view=article&id=257&Itemid=103.

22 Available at http://papers.ssrn.com/ sol3/papers.cfm?abstract_id=2231811.

23 Available at www.economist.com/blogs/ babbage/2012/05/oracle-v-google.

24 Available at http://opensource.org/osd.

25 Available at http://www.freesoftwaremagazine.com/articles/ creating_wealth_free_software.

26 See Samba, http://www.samba.org.

27 See Mozilla Products, http://www.mozilla.org/en-US/products/#tools.

28 See Apache Software Foundation, Open Office, http://www.openoffice.org/

29 See WordPress, http://wordpress.org/

30 Available at http://www.w3.org/standards/techs/xml#w3c_all

31 Available at http://xml.coverpages.org/xmlApplications.html.

32 Available at https://images-na.ssl-images-amazon.com/images/ G/01/rainier/help/XML_Documentation_Intl.pdf.

33 Lotus has been cited with approval by numerous circuit courts. See Hutchins v. Zoll Medical Corp., 492 F.3d 1377 (Fed. Cir. 2007); Incredible Techs., Inc. v. Virtual Techs., Inc., 400 F.3d 1007 (7th Cir. 2005); Lexmark Int'l, Inc. v. Static Control Components, Inc., 387 F.3d 522 (6th Cir. 2004); MiTek Holdings, Inc. v. Arce Engineering Co., 89 F.3d 1548 (11th Cir. 1996).

34 Available at http://www.wired.com/ wiredenterprise/2012/05/oracle_clou/.

35 Available at http://www.rfidjournal.com/article/view/4986.

36 Available at http://www.smart-systems-integration.org /public/documents/publications/Internet-of- Things_in_2020_EC- EPoSS_Workshop_Report_2008_v3.pdf.

37 Available at http://www.cui-zy.cn/Recommended/ Linux/Architecting_the_Internet_of_Things.pdf.

38 In so doing, neither Congress nor courts have forced entities to choose between patent protection and copyright protection for software programs. Instead, courts have recognized that expressive elements of software are protected while functional elements are not (although they may be patentable).

39 Although the Ninth Circuit in Sega and Connectix discussed interoperability in the fair use section of their analysis, both cases addressed copyrightability as a threshold question, not as a fair use factor. Both cases stand for the same conclusion: elements of software code essential to interoperability are uncopyrightable as a matter of law. Thus, the rulings in Sega and Connectix are, contrary to Oracle's claims, directly relevant to consideration of the copyrightability of the APIs at issue in this case.

32

63 comments



http://groklawstatic.ibiblio.org/article.php%3fstory=20130531131600482