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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
App Developers File Amicus Brief in Support of Google ~pj
Tuesday, June 04 2013 @ 11:45 PM EDT

Here is the final amicus brief [PDF] in support of Google in the appeal at the Federal Circuit of Oracle v. Google, the API case. This one is from app developers, specifically the Application Developers Alliance, with Rackspace, TMSOFT, and Stack Exchange, and I've done it in text for you. They tell the court that Oracle is trying for something new in copyright law, contrary to the expectations of the industry:
Software is a mix of both functional and expressive components. For the past forty years, the common understanding in the industry has been that the “declaring code”—the code used to define interfaces and APIs—is functional and not copyrightable. In contrast, the “implementing code”—the code needed to provide the underlying functionality—is expressive and protected by copyright. Oracle’s position, that the declaring code used to define an API is protectable under copyright, is contrary to the current and historical practice and expectations in the software industry and would have a devastating impact on the software business as a whole. Thousands of businesses, developers, and even end users would be faced with legal uncertainty if declaring code were afforded copyright protections....

What’s more, similar attempts at aggregating control over APIs have been recognized by developers, the United States, and the European Union as dangerous to the app developer and cloud-computing industries. Copyright protection for declaring code would act as a tax on software development, leaving the public with lower-quality, less innovative software products....

Understanding the extent to which the software industry depends on the free exchange and use of API declaring code is necessary to comprehend the chilling effect that Oracle’s position would have on software innovation and development.

So they explain APIs and how they work in the industry -- and have worked for 40 years or so. APIs, they say, are the building blocks of software, like Lego® bricks. They can be all kinds, colors and shapes, but one thing they all have, and have to have to be able to put them together, are the bumps and holes that make them fit together, and those bumps and holes only work if they are all the same size. Software is like that too. They need a standard interface so they can fit together.

And your smartphone or other device communicates with the cloud entirely through APIs. APIs are that vital now. Developers have always felt legally free to use APIs, as long as the implementing code was their own. "For example," the brief states, "even Microsoft has re-implemented the UNIX APIs in the 'Interix' subsystem included with its server products." It did the same with WordPerfect, back when WordPerfect was more popular than Microsoft Word. Of course, Linux used UNIX APIs also, as did many other projects. And the Wine project has been re-implementing Microsoft's Windows APIs since 1993, the brief tells the court. This is an accepted business practice. Oracle is trying to extend the reach of copyright law.

This is the only amicus brief attempting to explain the Open Source viewpoint to the court, to help it understand exactly why it matters so much that APIs be available for the cloud. And it lets the court know that Open Source does not need copyright protection for APIs:

Rackspace’s involvement in both the open source and cloud computing markets lends the Court a unique perspective on the copyright issues raised in this appeal. Open source development is a driving force behind software innovation and fosters the creation of peer-reviewed, higher-quality code. The open source community is a perfect example of why copyright protection for APIs is unnecessary for continued innovation and why the monopoly Oracle seeks would in fact hamper that innovation. Further, the cloud computing market depends heavily on the use of APIs because all cloud functionality is delivered to the end user via APIs.
Of course, that may just be why Oracle -- along with Microsoft, EMC, and NetApp, who filed amicus briefs in support of Oracle -- wants to make them proprietary.

Jump To Comments

And the brief points out that Microsoft, here supporting Oracle, has some water under the anticompetitive bridge, not just in general but specifically in relation to APIs:
Microsoft, which filed an amicus brief supporting Oracle, has also tried to leverage API access to stifle competition only to ultimately have to back away from its position. In 1998, the United States brought a civil anti-trust suit against Microsoft, alleging that the software giant had improperly manipulated the internet browser market to favor its Internet Explorer program. Among the many allegations in that suit, the United States asserted that Microsoft had altered its Windows APIs to favor interoperability with its Internet Explorer web browser as a way to shut out competition from other browser manufacturers. As part of the settlement Microsoft reached with the United States, Microsoft was required to publicly release its APIs for the “purpose of interoperating with a Windows Operating System Product.” In other words, Microsoft was forced to make its APIs publicly available so that other developers could utilize the declaring code for products, including web browsers, that were fully compatible with the Windows operating system. In the judgment of the United States Department of Justice, free access to the declaring code of Windows APIs was necessary to maintain adequate competition in the software industry. Oracle seeks to achieve through the Copyright Act what the ... United States Department of Justice determined that ... Microsoft should not be permitted to achieve through ... anti-competitive business practices. The result that Oracle seeks in this case—the ability to control who can use the declaring code of the Java APIs and exact a tax from each developer who seeks to use the APIs—would create a similarly anti-competitive force in the software industry. The result would also jeopardize the livelihood of the millions of individuals employed as app developers or employed by publishers and platforms.

Do we really want a world where there can never be another Linux? Microsoft would love that, but what about the rest of us?

The brief doesn't mention it, but the Novell v. Microsoft litigation over WordPerfect is about APIs too. Interestingly, Microsoft didn't say their APIs were copyrighted when it didn't want Novell to use them. It *hid* them. That wouldn't have been necessary had Microsoft believed copyright covered their interfaces back then. David Boies argued Novell's appeal against Microsoft, and here he represents Oracle. You'd think he could add 2 plus 2 and get 4 on APIs and copyrightability.

Open Source is proof that APIs that are not copyright-protected do not destroy innovation, as Oracle would like the court to believe, the developers tell the court of appeals. On the contrary, they enable it:

Obviously, the software industry has been quite innovative so far. Despite Oracle’s protestations, the software industry has thrived for the last forty years without copyright protection for the declaring code of APIs.

In fact, open source development is increasingly being recognized as a driving force of software innovation.

And then the brief explains to the court why Oracle's suggestion that developers rely on fair use doesn't fly:
Oracle and its amici suggest that any balancing between the rights of an original author and those of a subsequent innovator should be done using the infringement prong of copyright analysis, particularly the doctrine of fair use. But the doctrine of fair use is a slippery one, once referred to as “the most troublesome in the whole law of copyright.” Universal City Studios v. Sony Corp. of Am., 659 F.2d 969 (9th Cir. 1981). The doctrine requires careful balancing of four nuanced, non-exclusive factors to determine whether an individual’s use—while technically within the scope of infringement—should be considered unlawful. See 17 U.S.C. § 107. The statute does not set forth how much weight a court should give to any of the four factors or whether any of the individual factors is sufficient for a finding of fair use.

Were this Court to accept Oracle’s position, almost every player in the industry would be susceptible to suits for copyright infringement when using declaring code. If liability for the entire market were determined based on a case-by-case determination of fair use (an already unpredictable doctrine), developers would be unable to adequately predict their exposure. This would significantly increase the transaction costs associated with creating interoperable software, including all uses of cloud computing, which is provided via APIs. This presents an untenable burden for Amici, the thousands of developers building on our platforms, and the hundreds of thousands of customers that use APIs to interact with our products.

And after all, they end by pointing out, "protection of innovation is the purpose the Copyright Act was meant to fulfill," so they ask the appeals court to affirm the district court's ruling.

For any wondering who these folks are, they explain their interest in this appeal this way:

Rackspace is a cloud-computing company that delivers enterprise-level hosting services to business of all sizes and kinds throughout the world. Since its founding in 1998, Rackspace has grown from a small company based in San Antonio, Texas to an industry pioneer serving more than 200,000 customers in over 120 countries. One of Rackspace’s greatest achievements is its collaboration with NASA to co-found OpenStack, the world’s fastest-growing open source cloud platform and developer community. OpenStack provides an alternative to the proprietary software that powers most other major cloud computing platforms by making its code freely available to developers.

Rackspace’s involvement in both the open source and cloud computing markets lends the Court a unique perspective on the copyright issues raised in this appeal. Open source development is a driving force behind software innovation and fosters the creation of peer-reviewed, higher-quality code. The open source community is a perfect example of why copyright protection for APIs is unnecessary for continued innovation and why the monopoly Oracle seeks would in fact hamper that innovation. Further, the cloud computing market depends heavily on the use of APIs because all cloud functionality is delivered to the end user via APIs.

Accordingly, Rackspace has extensive experience with APIs and their inherently functional nature.

The Application Developers Alliance (“Alliance”) is a global association of more than 25,000 individual software developers and more than 125 companies who design and build applications (“apps”) for consumers to use on mobile devices like smartphones and tablets. TMSOFT is one of the Alliance’s corporate members and is a small app publisher of several popular apps including sleep aids, music visualization, and games. Apps run on software platforms, including Google’s Android, Apple’s iOS, and Facebook, and are sold or distributed through virtual stores like Google’s Play Store, Apple’s App Store, Amazon.com, and Handango. TMSOFT’s White Noise app has been widely downloaded on all major app platforms, and was the most popular app in the Apple App Store after its debut in 2008.

The Alliance was formed to promote continued growth and innovation in the rapidly-growing app industry and routinely speaks as the industry’s voice to legislators and policy-makers. Millions of Americans and tens of millions of individuals world-wide earn their livelihood through app development. App development is one of the fastest growing industries in America and has transformed the software industry.

As described in more detail below, app development requires programmers to use API declaring code associated with individual operating system platforms. The ability to freely exchange and use the API declaring code is vital to Alliance members’ and TMSOFT’s ability to develop the innovative applications that serve sectors as diverse as healthcare, fashion, fitness, and public services.

Accordingly, the Alliance, TMSOFT, and the Alliance’s other members have wide-ranging experience with APIs and can attest to the use of APIs in the app and mobile device industry and in the programming community at large. Stack Exchange is a network of technical communities, each dedicated to serving experts in a specific field. As part of its support for developer and creator communities, Stack Exchange builds and maintains libraries of high-quality questions and answers, focused on each community’s area of expertise. It is the most-frequented developer site on the Internet, with over 100 separate sites and over 64 million monthly unique visitors.

Stack Exchange has a close relationship with APIs. From programmers sharing answers on parsing HTML, to researchers seeking solutions to combinatorial problems, Stack Exchange’s communities are focused on helping each other explore, describe, and implement APIs. Just as photographers compare their favorite cameras and gardeners discuss seeds, APIs are the tools of the trade for the majority of Stack Exchange’s visitors, including APIs for mobile development. As a company focused on the nuances of API construction and use, Stack Exchange has a unique perspective informed by the thousands of software development experts that participate every day on its sites

Taking Stock Now That All The Amicus Briefs Are In For Both Sides:

On Google's side, we have seen amicus support from a long list of computer scientists -- 32 of them, people like Dave Farber, Bjarne Stroustrup, Brian Behlendorf and Andrew Tridgell -- and including significant Java developers like Doug Lea, a list of 18 innovators and entrepreneurs like Esther Dyson, Dan Bricklin, Ray Ozzie and Mitch Kapor, including two hedge funds, startups, software companies, and 39 law professors. The Application Developers Alliance alone is a global association of more than 25,000 individual software developers and more than 125 companies who design and build applications. Rackspace is a cloud company.

On Oracle's side, we see two law professors, two professors of computer science, Microsoft, EMC, BSA (which, to me, is the same as Microsoft), NetApp (who once sued Sun Microsystems for patent infringement, now owned by Oracle, and settled with Oracle after prior art -- some of which Groklaw turned up -- invalidated some of its patents), the Graphic Artists Guild and Picture Archive Council of America, and two individuals Scott McNealy and Brian Sutphin (no axe to grind there, snort).

In short, Oracle has more lawyers on this appeal than it has supporters. The world en masse is standing with Google.

Here are the lists of amici, in detail:

For Oracle:

Microsoft
Eugene H. Spafford, Zhi Ding and Lee A. Hollaar
Ralph Oman
Graphic Artists Guild and Picture Archive Council of American Inc.
BSA
EMC Corporation and NetApp
Scott McNealy and Brian Sutphin
For Google:
Application Developers Alliance (with Rackspace, TMSoft and Stack Exchange), meaning more than 25,000 individual software developers and more than 125 companies who design and build applications (“apps”).

The Computer & Communications Industry Association (CCIA), which represents over twenty companies of all sizes providing high technology products and services, including computer hardware and software, electronic commerce, telecommunications, and Internet products and services – companies that collectively generate more than $250 billion in annual revenues.

Intellectual Property Law Professors

1. Jonas Anderson, Assistant Professor American University, Washington College of Law
2. Timothy K. Armstrong, Professor University of Cincinnati College of Law
3. Dan Burk, Professor University of California, Irvine, School of Law
4. Michael A. Carrier, Professor Rutgers Law School – Camden
5. Michael Carroll, Professor American University, Washington College of Law
6. Brian Carver, Assistant Professor University of California, Berkeley, School of Information
7. Margaret Chon, Professor Seattle University School of Law
8. Julie E. Cohen, Professor Georgetown University Law Center
9. Ralph Clifford, Professor University of Massachusetts School of Law
10. Stacey L. Dogan, Professor Boston University School of Law
11. Shubha Ghosh, Professor University of Wisconsin Law School
12. James Grimmelmann, Professor New York Law School
13. Paul Heald, Professor University of Illinois College of Law
14. Peter Jaszi, Professor American University, Washington College of Law
15. Dennis S. Karjala, Professor Sandra Day O’Connor College of Law, Arizona State University
16. Marshall Leaffer, Distinguished Scholar in IP Law and University Fellow Indiana University Maurer School of Law
17. Mark Lemley, Professor Stanford Law School
18. Yvette Joy Liebesman, Assistant Professor Saint Louis University School of Law
19. Jessica Litman, Professor University of Michigan Law School
20. Lydia Pallas Loren, Professor Lewis & Clark Law School
21. Brian J. Love, Assistant Professor Santa Clara University School of Law
22. Glynn S. Lunney, Jr., Professor Tulane University School of Law
23. Michael J. Madison, Professor University of Pittsburgh School of Law
24. Stephen McJohn, Professor Suffolk University Law School
25. Charles R. McManis, Professor Washington University School of Law
26. Lateef Mtima, Professor Howard University School of Law
27. Mark Patterson, Professor Fordham University School of Law
28. Aaron Perzanowski, Associate Professor Case Western Reserve University School of Law
29. Victoria Phillips, Professor American University, Washington College of Law
30. Malla Pollack, co-author, CALLMANN ON UNFAIR COMPETITION, TRADEMARKS & MONOPOLIES (Thomson-Reuters 4th ed.)
31. Jerome Reichman, Professor Duke University School of Law
32. Michael Risch, Associate Professor Villanova University School of Law
33. Michael Rustad, Professor Suffolk University Law School
34. Matthew Sag, Professor Loyola University Chicago School of Law
35. Pamela Samuelson, Professor University of California, Berkeley, School of Law
36. Joshua D. Sarnoff, Professor DePaul University College of Law
37. Christopher Sprigman, Professor University of Virginia School of Law
38. Katherine Strandburg, Professor New York University School of Law
39. Rebecca Tushnet, Professor Georgetown University Law Center
Computer Scientists
1. John Perry Barlow
2. Brian Behlendorf
3. Richard A. Belgard
4. Jon Bentley
5. Matthew Bishop
6. Frederick Brooks
7. David Dill
8. Les Earnest
9. Brendan Eich
10. Dave Farber
11. Jeremiah Flerchinger
12. Martin Fowler
13. Allan Gottlieb
14. David Klausner
15. Kin Lane
16. Doug Lea
17. Paul Menchini
18. Martin Odersky
19. Tim Paterson
20. Tim Peierls
21. Simon Phipps
22. Bill Pugh
23. Larry Roberts
24. Bruce Schneier
25. Curtis Schroeder
26. Dave Snigier
27. Bjarne Stroustrup
28. Paul Sutter
29. Michael Tiemann
30. Andrew Tridgell
31. Josh Triplett
32. Phil Wadler
Software Innovators (another long list)
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
If you put all the amici on a seesaw, Google's side would hit the ground immediately, and Oracle's side would be stuck up in the air, dangling their feet helplessly until Google decided to let them come down again. That's how remarkable the difference in support is. You could truthfully say that there are law professors on both sides, but that's not the real story. The story is Oracle has a couple, but Google has 39, including pretty much all the famous IP lawyers you've ever heard of, and a few more.

If lawsuits were decided by numbers, Google would be a shoo-in. The support has been overwhelming. But lawsuits are not decided that way, although it does carry weight when a court sees so many expressing deep concerns, but the court will base their decision on the legal arguments and to some extent on public policy concerns.

And here is the brief, as text:

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

Nos. 2013-1021, -1022

______________

UNITED STATES COURT OF APPEALS
FOR THE FEDERAL CIRCUIT

______________

ORACLE AMERICA, INC.,
Plaintiff-Appellant,

v.

GOOGLE INC.,
Defendant-Cross Appellant.

_________________

BRIEF OF AMICI CURIAE
RACKSPACE US, INC., APPLICATION DEVELOPERS
ALLIANCE, TMSOFT, LLC, AND STACK EXCHANGE INC.

______________

Appeal from the United States District Court for the
Northern District of California
Case No. 10-CV-3561, Hon. William H. Alsup.

_______________

Chad Ruback
The Ruback Law Firm
[address, phone, fax]

Attorney for Amici Curiae, Rackspace US, Inc.,
Application Developers Alliance, TMSOFT, LLC, and Stack Exchange Inc.

CERTIFICATE OF INTEREST

Pursuant to Federal Circuit Rules 21(a)(2) and 47.4(a)(1), counsel for the Amici Curiae Rackspace US, Inc., Application Developers Alliance, TMSOFT, LLC, and Stack Exchange Inc. certifies the following:

1. The full name of every party represented by me: Rackspace US, Inc. Application Developers Alliance TMSOFT, LLC Stack Exchange Inc.

2. The names of the real parties in interest I represent are: Rackspace US, Inc. Application Developers Alliance TMSOFT, LLC Stack Exchange Inc.

3. All parent corporations, and any publicly held companies that own 10 percent or more of the stock of the parties I represent are:

Rackspace Hosting, Inc. is a parent corporation of Rackspace US, Inc. No publicly held companies own 10 percent or more of Rackspace US, Inc.’s stock. Application Developers Alliance does not have a parent corporation, and no publicly held companies own 10 percent or more of the Alliance’s stock. TMSOFT, LLC does not have a parent corporation, and no publicly held companies own 10 percent or more of TMSOFT, LLC’s stock.

Stack Exchange Inc. does not have a parent corporation, and no publicly held companies own 10 percent or more of Stack Exchange Inc.’s stock.

ii

4. The names of all law firms and the partners or associates that appeared in the trial court or are expected to appear in this court for the parties I now represent are:

Chad Ruback
The Ruback Law Firm
May 30, 2013

/s/ Chad Ruback
Chad Ruback
Attorney for Amici Curiae
Rackspace US, Inc., Application Developers Alliance, TMSOFT, LLC, and Stack Exchange, Inc.

iii

TABLE OF CONTENTS

CERTIFICATE OF INTEREST .................................. ii

TABLE OF CONTENTS...................................... iv

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

INTERESTS OF AMICI CURIAE ............................. 1

SUMMARY OF ARGUMENT .................................. 4

ARGUMENT........................................... 6

I. APIs and their re-implementation are integral to continued
innovation in the software industry. ............................ 6

A. API re-implementation is common in the industry and
considered a legal way to obtain similar functionality and
interoperability................................. 9

B. Aggregated control over APIs is a dangerous
anti-competitive force. ............................13

C. Copyright protection of declaring code is not necessary to
incentivize software innovation...................16

II. Long-standing doctrines of copyrightability are already
calibrated to balance industry needs................19

CONCLUSION .............................22

ECF CERTIFICATION ..............................24

CERTIFICATE OF COMPLIANCE..................25

iv

TABLE OF AUTHORITIES

Page(s)

CASES

Gates Rubber Co. v. Bando Chem. Indus., Ltd.,
9 F.3d 823 (10th Cir. 1993)......................21

Lexmark Int’l, Inc. v. Static Control Components, Inc.,
387 F.3d 522 (6th Cir. 2004) (Feikens, J. dissenting)................20

Sega Enters. Ltd. v. Accolade, Inc.,
977 F.2d 1510 (9th Cir. 1993)....................21

United States v. Microsoft,
Case No. 98-1232 (Dist. D.C.), available at
http://www.justice.gov/atr/cases/f1700/1763.htm.....................15

Universal City Studios v. Sony Corp. of Am.,
659 F.2d 969 (9th Cir. 1981)........................19

STATUTES AND RULES

17 U.S.C. § 107 ........................19

Fed. R. App. P. 29(a) ..................................1

Fed. R. App. P. 29(c)(5)..................................1

OTHER AUTHORITIES

ANDROID, http://www.android.com/about/ (last visited May 29, 2013)........18

Matt Asay, Open Source Gains While Proprietary Software Declines, CNET
(Apr. 20, 2007, 10:07 a.m. PDT),
http://news.cnet.com/8301-13505_3-10223005-16.html ..........................16

CloudAve, PaaS is the Future of Cloud Services: APIs are the Key
http://www.cloudave.com/282/paas-is-the-future-of- cloud-services-apis-a
re-the-key/ (last visited May 29, 2013) ...................17

CodeWeavers, Inc., CodeWeavers and Microsoft Licensing Questions,
http://www.codeweavers.com/products/faq/licensing/
(last visited May 29, 2013)..................12

v

Google, Google Buzz Has Gone Away, But Your Posts Are Yours to Keep,
https://support.google.com/mail/answer/1698228?hl=en (last visited May 29,
2013).................................18

Andrew B. Hebl, Note, A Heavy Burden: Proper Application of Copyright’s
Merger and
Scenes A Faire Doctrines,
8 Wake Forest Intell. Prop. L.J. 128 (2007) ........................21

Jacqueline D. Lipton, IP’s Problem Child: Shifting the Paradigms for
Software Protection
, 58 Hastings L.J. 205 (2006)....................20

Open Handset Alliance, Android FAQ,
http://www.openhandsetalliance.com/android_overview.html
(last visited May 29, 2013).................................18

OPEN SOURCE INITIATIVE, http://opensource.org/osd (last visited May 29,
2013) ..............12

Openstack Cloud Software, What is OpenStack?, http://www.openstack.org/
(last visited May 29, 2013)...............................17

Press Release, Europa, Mergers: Commission Opens In-Depth Investigation
Into Proposed Takeover of Sun Microsystems by Oracle (Sept. 3, 2009),
http://europa.eu/rapid/press-release_IP09-1271_en.htm?locale=en.............14

Press Release, Oracle Makes Commitments to Customers, Developers and
Users of MySQL (Dec. 14, 2009),
http://www.oracle.com/us/corporate/press/042364..................14

SERVICES FOR UNIX—INTEROPERABILITY BLOG,
http://blogs.msdn.com/b/sfu/ (last visited May 29, 2013)................11

Andrew S. Tanenbaum, Some Notes on the “Who wrote Linux” Kerfuffle,
Release 1.5 (May 20, 2004) http://www.cs.vu.nl/~ast/brown/ .........11

Timothy S. Teter, Note, Merger and the Machines: An Analysis of the
Pro-Compatibility Trend in Computer Software Copyright Cases
, 45
Stanford L. Rev. 1061 (1993).......................16, 21

Stephen R. Walli, INTERIX: UNIX: Application Portability to Windows NT
via an Alternative Environment Subsystem
,
http://stephesblog.blogs.com/papers/usenix-interix.pdf....................................11

vi

Wine HQ, Explaining the Wine Project, http://www.winehq.org/about/ (last visited
May 29, 2013) .......................12 Wine HQ, Wine User Guide,
http://www.winehq.org/docs/wineusr-guide/what-is-wine (last visited
May 29, 2013)..................................12

vii

INTERESTS OF AMICI CURIAE1

Rackspace is a cloud-computing company that delivers enterprise-level hosting services to business of all sizes and kinds throughout the world. Since its founding in 1998, Rackspace has grown from a small company based in San Antonio, Texas to an industry pioneer serving more than 200,000 customers in over 120 countries. One of Rackspace’s greatest achievements is its collaboration with NASA to co-found OpenStack, the world’s fastest-growing open source cloud platform and developer community. OpenStack provides an alternative to the proprietary software that powers most other major cloud computing platforms by making its code freely available to developers.

Rackspace’s involvement in both the open source and cloud computing markets lends the Court a unique perspective on the copyright issues raised in this appeal. Open source development is a driving force behind software innovation and fosters the creation of peer-reviewed, higher-quality code. The open source community is a perfect example of why copyright protection for APIs is unnecessary for continued innovation and why the monopoly Oracle seeks would in fact hamper that innovation. Further, the cloud computing market depends heavily on the use of APIs because all cloud functionality is delivered to the end user via APIs.

1

Accordingly, Rackspace has extensive experience with APIs and their inherently functional nature.

The Application Developers Alliance (“Alliance”) is a global association of more than 25,000 individual software developers and more than 125 companies who design and build applications (“apps”) for consumers to use on mobile devices like smartphones and tablets.2 TMSOFT is one of the Alliance’s corporate members and is a small app publisher of several popular apps including sleep aids, music visualization, and games. Apps run on software platforms, including Google’s Android, Apple’s iOS, and Facebook, and are sold or distributed through virtual stores like Google’s Play Store, Apple’s App Store, Amazon.com, and Handango. TMSOFT’s White Noise app has been widely downloaded on all major app platforms, and was the most popular app in the Apple App Store after its debut in 2008.

The Alliance was formed to promote continued growth and innovation in the rapidly-growing app industry and routinely speaks as the industry’s voice to legislators and policy-makers. Millions of Americans and tens of millions of individuals world-wide earn their livelihood through app development. App

2

development is one of the fastest growing industries in America and has transformed the software industry.

As described in more detail below, app development requires programmers to use API declaring code associated with individual operating system platforms. The ability to freely exchange and use the API declaring code is vital to Alliance members’ and TMSOFT’s ability to develop the innovative applications that serve sectors as diverse as healthcare, fashion, fitness, and public services. Accordingly, the Alliance, TMSOFT, and the Alliance’s other members have wide-ranging experience with APIs and can attest to the use of APIs in the app and mobile device industry and in the programming community at large.

Stack Exchange is a network of technical communities, each dedicated to serving experts in a specific field. As part of its support for developer and creator communities, Stack Exchange builds and maintains libraries of high-quality questions and answers, focused on each community’s area of expertise. It is the most-frequented developer site on the Internet, with over 100 separate sites and over 64 million monthly unique visitors.

Stack Exchange has a close relationship with APIs. From programmers sharing answers on parsing HTML, to researchers seeking solutions to combinatorial problems, Stack Exchange’s communities are focused on helping each other explore, describe, and implement APIs. Just as photographers compare

3

their favorite cameras and gardeners discuss seeds, APIs are the tools of the trade for the majority of Stack Exchange’s visitors, including APIs for mobile development. As a company focused on the nuances of API construction and use, Stack Exchange has a unique perspective informed by the thousands of software development experts that participate every day on its sites.

SUMMARY OF ARGUMENT

Software is a mix of both functional and expressive components. For the past forty years, the common understanding in the industry has been that the “declaring code”—the code used to define interfaces and APIs—is functional and not copyrightable. In contrast, the “implementing code”—the code needed to provide the underlying functionality—is expressive and protected by copyright.3 Oracle’s position, that the declaring code used to define an API is protectable under copyright, is contrary to the current and historical practice and expectations in the software industry and would have a devastating impact on the software business as a whole. Thousands of businesses, developers, and even end users would be faced with legal uncertainty if declaring code were afforded copyright protections.

4

The continued development of software, particularly in the cloud computing and mobile device markets, depends on the free use of APIs. In fact, developers have relied on the ability to use APIs and provide re-implementations as a source of innovation for over three decades. Oracle uses discredited “sweat of the brow”-type reasoning to argue that it should be entitled to monopolize the functional bits of code necessary for interoperability, contrary to the sound principles or policies of copyright law. What’s more, similar attempts at aggregating control over APIs have been recognized by developers, the United States, and the European Union as dangerous to the app developer and cloud-computing industries. Copyright protection for declaring code would act as a tax on software development, leaving the public with lower-quality, less innovative software products.

As the district court’s decision points out, the merger, short phrases, and method of operation doctrines all exclude the declaratory portions of APIs from copyright protection. The scenes a faire doctrine similarly precludes copyright protection for the declaratory elements of APIs that are dictated by practical realities like interoperability and file format compatibility.

Amici urge the Court to uphold the district court’s decision and preserve the software community’s ability to continue developing innovative, interoperable, open source, and cloud computing software through re-implementation of APIs.

5

ARGUMENT

Oracle and its amici want this Court to believe that, in the absence of copyright protection for API declaring code, the software industry will grind to a halt. What Oracle neglects to say is that for the past forty years, the software industry has experienced vibrant innovation despite the longstanding and universally-held belief among developers that declaring code was not protected by copyrights. In fact, many in the industry (in addition to the United States and European Union) see aggregation of control over APIs as a dangerous anti-competitive force. Permitting companies like Oracle to exercise near-total control over declaring code would severely limit Amici’s ability to continue innovating, particularly in the API-dense industry niches of cloud computing and mobile devices.

I. APIs and their re-implementation are integral to continued innovation in
the software industry.

This Court has been presented with several different iterations of what application programming interfaces, or APIs, mean in the specific context of this case. Oracle and some of its amici have defined APIs as “the vast array of Java programs to perform often-needed functions.” (Oracle Br. 8; BSA Br. at 5). Another amicus brief defines APIs as software that “provides an interface that allows a user, computer, or piece of software to communicate with another piece of software.” (Spafford, et al. Br. 8). It is true that, as their name suggests, application programming interfaces provide an interface between the inputs of one application

6

and the outputs of another. But, as Microsoft acknowledges, most of the amici briefing the Court has received fails to address APIs “beyond the computer programs at issue here.” (Microsoft Br. 7). Understanding the extent to which the software industry depends on the free exchange and use of API declaring code is necessary to comprehend the chilling effect that Oracle’s position would have on software innovation and development.

APIs are the fundamental building blocks of software programs, used in every software interaction. APIs can be somewhat abstract, so it can help to think of a physical analogue—the Lego® brick. There are many different shapes and colors of Lego® bricks, but they all share one thing in common: the bumps on the top of each brick and the matching holes on the underside. These bumps and holes are the “interface” that allow different bricks to be joined together. A person building with Lego® bricks can join the bricks together in almost unlimited ways, using different colors and different shapes, but the interfaces must be all be compatible or the bricks simply won’t work together.

Software is similar. The “declaring” code in APIs is like the bumps on the Lego® bricks. This declaring code has various constraints due to the underlying nature of the system and the desire for compatibility. The “implementing” code is like the color and the shape of the brick—almost infinitely variable, the product of individual work and creativity.

7

APIs are the interfaces that allow hardware and software components to exchange information, to pass control, and to communicate with each other. They are ubiquitous and tend to be almost mechanical in nature. For example, the on-board computer system in a car contains APIs to interface between the input of a gas pedal and the output of a speedometer. When a driver puts pressure on a gas pedal to accelerate, the data from the gas pedal sensors is sent through an API to the speedometer, which generates an output in the form of a display of the miles per hour at which the car is traveling.4

APIs are vital to the entire software industry, including developers building apps for mobile devices, smartphones, and tablets. Companies wishing to attract developers frequently provide APIs that allow developers to share often-used functions without re-inventing the wheel. This explains why the most popular app development platforms—Google’s Android platform and Facebook—are those that provide developers free access to robust APIs.

But APIs also make users’ lives easier, allowing for file format compatibility and interoperability between devices and programs. An application is only able to function on a smartphone device if the application and smartphone operating

8

systems share identical API declaring code. Identity of implementing code is not necessary to achieve interoperability.5

Likewise, APIs are integral to the cloud computing industry that Rackspace is pioneering. Every interaction over the Internet takes place using commonly-accepted standards for sending commands back and forth, returning responses, and sharing information—an API. Because cloud computing necessarily occurs without physical interaction between the cloud and the customer’s computer system, all of the cloud computing software functionality is delivered to the customer via APIs. In other words, a user’s mobile device communicates with the cloud entirely through APIs. As mobile devices and cloud computing become ever-larger parts of the software industry, APIs will continue to grow in importance to software developers.

A. API re-implementation is common in the industry and considered
a legal way to obtain similar functionality and interoperability.

Oracle and its amici go to great lengths to portray their legal theory regarding declaring code’s copyrightability as one deeply rooted in thirty years of copyright jurisprudence. But Oracle’s position is completely contrary to well-established

9

industry practice. Before this case, no one in the software industry considered re-implementation of an API—that is, using the same declaring code but devising new implementing code—a violation of copyright law. In fact, long before Google re-implemented the Java APIs, programmers had re-implemented APIs to achieve similar functionality or interoperability. Software designers have long abided by Judge Alsup’s conclusion that “so long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used” in an API. (A132).

Since the earliest days of software development, programmers have exercised their freedom to re-implement APIs to improve or compete with existing programs. For example, in the 1970s, developers at Bell Laboratories created the proprietary UNIX operating system. Because UNIX was so expensive, other programmers began re-implementing the UNIX APIs to develop less costly (or, in some cases, free) operating systems with similar functionality. The most famous and widely used of these clones, Linux, was developed in 1991. Linux borrowed heavily from the MINIX system, an earlier UNIX clone. When asked whether Linux had improperly copied MINIX APIs, the MINIX developer replied that while Linux copied the “layout of the file system” and “the names in the source tree,” it had re-implemented

10

the APIs.6 In his eyes, and the eyes of most software developers, the Linux developer had committed no copyright violations. In fact, Linux is only one of a number of operating systems that have re-implemented the UNIX APIs, creating compatible operating systems that vary in their implementation and underlying functionality, but use the same interfaces to communicate between the different parts of the system. For example, even Microsoft has re-implemented the UNIX APIs in the “Interix” subsystem included with its server products.7 This was done to provide application-level interoperability and allow Microsoft to better compete with UNIX-based systems.8

11

Another free, open source9 project called Wine has been re-implementing Microsoft’s Windows APIs since 1993.10 The project translates the declaring code of the Windows APIs so that Windows-based applications can run on other operating systems like Mac OSX and Linux.11 Wine developers go to great lengths to ensure that the implementing code of their APIs is developed without reverse engineering or access to any Microsoft implementing code in an effort to avoid copyright infringement.12

Re-implementing APIs for the purpose of competing with an existing product is a regular and accepted business practice. In the early days of word processing, WordPerfect was the dominant word processing program, even ahead of Microsoft Word. Within each WordPerfect document were a series of codes—instructions to the word processing program that described the layout and formatting of the document. In order to compete, Microsoft wrote its own implementing code that

12

allowed Microsoft Word to open and modify WordPerfect files. In order for Word to open a WordPerfect document containing a bolded word and maintain WordPerfect’s original bolded formatting, Word must ‘understand’ the code WordPerfect uses to designate bolded text. Word does this by utilizing WordPerfect’s pre-set definitions (analogous to declaring code) for bolded words and translating them into Word implementing code. In this example, Microsoft has used WordPerfect code only to the extent necessary to allow users to open different file formats in Microsoft Word and therefore achieve some level of file format compatibility.

These examples demonstrate the universal understanding of the unprotected status of declaring code and the complete lack of historical support for Oracle’s argument. Almost any time a software product advertises that it is “compatible” with a competitor, developers have written new implementing code and kept the external interfaces—the APIs—the same. Reversing the district court would disrupt these businesses, prejudice the large community of app and app platform developers that rely on compatibility between competitors, and put an end to innovative open source projects like Linux and Wine.

B. Aggregated control over APIs is a dangerous anti-competitive
force.

Allowing Oracle, or any party, exclusive copyright-based controls over APIs would have a significant anti-competitive effect on the industry. In fact, as part of

13

Oracle’s purchase of Sun Microsystems (the acquisition that led to Oracle’s ownership of the Java APIs at issue here),13 Oracle also acquired an open source database management system called MySQL. Upon investigating the proposed merger between Oracle and MySQL, the European Commission on Competition expressed concerns that Oracle would discontinue or privatize the open source database, thereby eliminating some of its competition.14 The Commission was particularly worried that permitting Oracle to control the MySQL APIs would reduce the choices available to consumers and increase prices of database software. In order to quell the European Commission’s worries about the anti-competitive potential of the merger, Oracle released a public statement promising that the MySQL APIs would remain publicly available for use.15 Based in part on these promises, the European Commission approved the merger.

Microsoft, which filed an amicus brief supporting Oracle, has also tried to leverage API access to stifle competition only to ultimately have to back away from its position. In 1998, the United States brought a civil anti-trust suit against Microsoft, alleging that the software giant had improperly manipulated the internet

14

browser market to favor its Internet Explorer program.16 Among the many allegations in that suit, the United States asserted that Microsoft had altered its Windows APIs to favor interoperability with its Internet Explorer web browser as a way to shut out competition from other browser manufacturers. As part of the settlement Microsoft reached with the United States, Microsoft was required to publicly release its APIs for the “purpose of interoperating with a Windows Operating System Product.” In other words, Microsoft was forced to make its APIs publicly available so that other developers could utilize the declaring code for products, including web browsers, that were fully compatible with the Windows operating system. In the judgment of the United States Department of Justice, free access to the declaring code of Windows APIs was necessary to maintain adequate competition in the software industry.

Oracle seeks to achieve through the Copyright Act what the European Commission and United States Department of Justice determined that Oracle and Microsoft should not be permitted to achieve through mergers and anti-competitive business practices. The result that Oracle seeks in this case—the ability to control who can use the declaring code of the Java APIs and exact a tax from each developer who seeks to use the APIs—would create a similarly anti-competitive force in the

15

software industry.17 The result would also jeopardize the livelihood of the millions of individuals employed as app developers or employed by publishers and platforms.

C. Copyright protection of declaring code is not necessary to
incentivize software innovation.

Activity in areas like cloud computing, open source software development, and the mobile device market demonstrates that robust protection for the declaring code of APIs is unnecessary to spur software innovation. As described above, software developers have always operated on the assumption that re-implementation of APIs, and therefore the use of declaring code, was not a violation of copyright law. Obviously, the software industry has been quite innovative so far. Despite Oracle’s protestations, the software industry has thrived for the last forty years without copyright protection for the declaring code of APIs.

In fact, open source development is increasingly being recognized as a driving force of software innovation.18 The philosophy behind open source software is that

16

open access to APIs fosters more creative development and more peer review of code, yielding higher quality, more innovative software. Rackspace’s open source OpenStack project, founded with help from NASA, is on the cutting edge of cloud technology. According to the OpenStack website, the “open development model is the only way to foster badly-needed cloud standards, remove the fear of proprietary lock-in for cloud customers, and create a large ecosystem that spans cloud providers.”19 The popularity of open source development—and the fact that for-profit companies are investing in open source projects—alone demonstrates that the ability to control who re-implements APIs is not necessary to incentivize software innovation.

But a recent example serves to underscore the point. In early 2010, Google released a microblogging program called Google Buzz but did not immediately make the underlying APIs available to developers.20 Because developers were not able to immediately make compatible software or to integrate Google Buzz into their existing sites and platforms, the program failed. Google discontinued Buzz in late

17

2011.21 In contrast, Google made the Android APIs open and available, and innovation for the operating system exploded.22 Android now claims to be the most popular mobile device operating system world-wide.23 Facebook similarly permits developers unlimited access to its APIs and is also one of the largest and most robust app development platforms. Google’s experience demonstrates that the ability to withhold developers’ use of APIs is not only unnecessary for innovation, it may actually hamper innovation.

Oracle and its amici claim that, without copyright protection for declaring code, the software industry will collapse. This claim is not supported either by historical industry practice or current trends in software development. In fact, the opposite is true. Permitting Oracle and others to determine who can use APIs and for what purpose would undermine innovative software development programs and stifle developers’ ability to create compatible and interoperable software applications.

18

II. Long-standing doctrines of copyrightability are already calibrated to
balance industry needs.

Oracle and its amici suggest that any balancing between the rights of an original author and those of a subsequent innovator should be done using the infringement prong of copyright analysis, particularly the doctrine of fair use. But the doctrine of fair use is a slippery one, once referred to as “the most troublesome in the whole law of copyright.” Universal City Studios v. Sony Corp. of Am., 659 F.2d 969 (9th Cir. 1981). The doctrine requires careful balancing of four nuanced, non-exclusive factors to determine whether an individual’s use—while technically within the scope of infringement—should be considered unlawful. See 17 U.S.C. § 107. The statute does not set forth how much weight a court should give to any of the four factors or whether any of the individual factors is sufficient for a finding of fair use.

Were this Court to accept Oracle’s position, almost every player in the industry would be susceptible to suits for copyright infringement when using declaring code. If liability for the entire market were determined based on a case-by-case determination of fair use (an already unpredictable doctrine), developers would be unable to adequately predict their exposure. This would significantly increase the transaction costs associated with creating interoperable

19

software, including all uses of cloud computing, which is provided via APIs.24 This presents an untenable burden for Amici, the thousands of developers building on our platforms, and the hundreds of thousands of customers that use APIs to interact with our products.

It is possible, as evidenced by the district court’s decision in this case, to adequately balance the rights of copyright holders, developers, and competitors through the existing doctrines regarding merger, short phrases, and methods of operation. It is also possible to adequately balance these rights through the scenes a faire doctrine.25 All of these doctrines would provide more predictable results for those in the industry and therefore achieve more cost-efficient innovation than the fair use doctrine.

The scenes a faire doctrine prohibits copyright protection “when external factors constrain the choice of expressive vehicle.” Lexmark Int’l, Inc. v. Static Control Components, Inc., 387 F.3d 522 (6th Cir. 2004). While more traditionally applied to the literary context, scenes a faire in the software context prohibits

20

copyright protection on those elements of a program “dictated by practical realities”—like the interoperability and file format compatibility concerns associated with the copying of API declaring code. Id. Commentators have long suggested the use of scenes a faire and the related doctrine of merger to remove code necessary for compatibility from the scope of copyright protection.26 Courts have also indicated that scenes a faire could be a useful tool in trimming copyright protection for elements of code dictated by compatibility concerns.27 The district court in this case observed that scenes a faire likely barred protection on the method header and names Oracle sought to protect. (A165-66, n.9).

Case law, commentary, and common sense all demonstrate that copyright protection for declaring code is unnecessary and potentially harmful to the software industry. While fair use analysis may ultimately reach the same result on a case-by-case basis, the scenes a faire doctrine, in addition to those invoked by the

21

district court, can serve as a more cost-efficient method for balancing the rights of follow-on innovators.

CONCLUSION

For the above reasons, Amici urge the Court to affirm the district court’s decision and refuse Oracle the ability to expand copyright into anti-competitive, over-broad protection on API declaring code so fundamental to continued innovation in the software industry. By finding that code necessary for functional compatibility—like the declaring code of APIs—is an unprotectable idea, either under the district court’s analysis or the doctrine of scenes a faire, this Court can protect the open source and interoperability projects that are vital to continued progress in the industry. At its core, protection of innovation is the purpose the Copyright Act was meant to fulfill.

22

Dated: May 30, 2013

Respectfully submitted,

Chad Ruback
The Ruback Law Firm
[address, phone, fax]

/s/ Chad Ruback
Chad Ruback

Attorney for Amici Curiae Rackspace
US, Inc., Application Developers
Alliance, TMSOFT, LLC, and Stack
Exchange Inc.

________
1 The parties have consented to the filing of this brief pursuant to Fed. R. App. P.
29(a). No party’s counsel authored this brief in whole or in part. No party, party’s
counsel, or any person other than amici or their counsel contributed money intended
to fund preparing or submitting this brief. See Fed. R. App. P. 29(c)(5).

2 The views expressed in this brief are the Alliance’s own and may or may not
represent the views of each individual member.

3 Amici use the term “declaring code” as that term has been defined by Oracle and is
distinguished from the term “implementing code.” (Oracle Br. 10). As defined by
the district court, the term implementing code refers to the code which carries out the
function defined by
the API. (A163). The district court found that “[t]o carry out any
given function, the method specification as set forth in the declaration must be
identical
under the Java rules.” (A164, emphasis in original). The district court’s
finding applies with equal force to all programming languages.

4 For purposes of clarity, this example is slightly oversimplified. For example, when
the car is in neutral, the speedometer will not change in response to pressure on the
gas pedal. Nevertheless, the example is useful for understanding the functional
nature of APIs.

5 This point is an important one for two reasons. In the context of this case, Google
copied the declaring code from the Java APIs at issue, but not the implementing
code. In the broader context of the software industry, it is common practice to
“re-implement” or “alternatively implement” APIs. This involves copying the
declaring code of an API to maintain compatibility, but writing re-implementing
code to achieve similar functionality and avoid copyright infringement.

6 Andrew S. Tanenbaum, Some Notes on the “Who wrote Linux” Kerfuffle, Release
1.5, (May 20, 2004), http://www.cs.vu.nl/~ast/brown/.

7 Interix is an optional, POSIX-conformant Unix subsystem for Windows NT
operating systems. Interix is a component of Windows Services for UNIX and a
superset of the Microsoft POSIX subsystem. Like the POSIX subsystem, Interix is
an environment subsystem for the NT kernel. It includes numerous open source
utility software programs and libraries. See Stephen R. Walli, INTERIX: UNIX:
Application Portability to Windows NT via an Alternative Environment Subsystem
,
http://stephesblog.blogs.com/papers/usenix-interix.pdf. Interix versions 5.2 and 6.0
are respective components of Microsoft Windows Server 2003 R2, Windows Vista
Enterprise, Windows Vista Ultimate, and Windows Server 2008 as Subsystem for
Unix-based Applications (SUA). Version 6.1 is included in Windows 7 (Enterprise
and Ultimate editions) and in Windows Server 2008 R2 (all editions). See SERVICES
FOR UNIX—INTEROPERABILITY BLOG, http://blogs.msdn.com/b/sfu/ (last visited
May 29, 2013).

8 “Application source code portability is one of the cornerstones of most open
systems definitions. The intention is that if an application is written to a particular
model of source-code portability, it can port relatively easily to any platform that
supports the portability model.” Walli, supra note 6 at 1.

9 Open source software is, generally speaking, software in which the source code is
made publicly available. OPEN SOURCE INITIATIVE, http://opensource.org/osd (last
visited May 29, 2013). The open source movement rests on the theory that
freely-available code harnesses the development skills of more programmers and
increases peer review of code, leading to better quality and lower-cost software.

10 Wine HQ, Explaining the Wine Project http://www.winehq.org/about/ (May 29,
2013).

11 Wine HQ, Wine User Guide, Chapter 1, http://www.winehq.org/docs/
wineusr-guide/what-is-wine (last visited May 29, 2013).

12CodeWeavers, Inc., CodeWeavers and Microsoft Licensing Questions,
http://www.codeweavers.com/products/faq/licensing/ (last visited May 29, 2013).

13 Oracle Br. 2, n1.

14 Press Release, Europa, Mergers: Commission Opens In-Depth Investigation Into
Proposed Takeover of Sun Microsystems by Oracle (Sept. 3, 2009),
http://europa.eu/rapid/press-release_IP-09-1271_en.htm?locale=en.

15 Press Release, Oracle Makes Commitments to Customers, Developers and Users
of MySQL (Dec. 14, 2009), http://www.oracle.com /us/corporate/press/042364.

16 See Complaint, United States v. Microsoft, Case No. 98-1232 (Dist. D.C.),
available at http://www.justice.gov/atr/cases/f1700/1763.htm.

17 For further commentary on the relationship between compatibility, competition,
and innovation in the marketplace, see Timothy S. Teter, Note, Merger and the
Machines: An Analysis of the Pro-Compatibility Trend in Computer Software
Copyright Cases
, 45 Stan. L. Rev. 1061, 1066-1070 (1993).

18 Matt Asay, Open Source Gains While Proprietary Software Declines, CNET
(Apr. 20, 2009, 10:07 a.m. PDT), http://news.
cnet.com/8301-13505_3-10223005-16.html (data indicating that the percentage of
organizations using proprietary software was expected to dip, while the percentage
using open source software was expected to rise).

19 Openstack Cloud Software, What is OpenStack?, http://www.openstack.org/ (last
visited May 29, 2013).

20 CloudAve, PaaS is the Future of Cloud Services: APIs are the Key,
http://www.cloudave.com/282/paas-is-the-future-of-cloud-services-apis-are-the-key/
(last visited May 29, 2013) (“They launched Google Buzz and Google Latitude
with much fanfare but they didn’t release the API for these services. This resulted in
lack of interest among the developers and, hence, failed to gain traction among the
users.”).

21 Google, Google Buzz Has Gone Away, But Your Posts Are Yours to Keep,
https://support.google.com/mail/answer/1698228?hl=en (last visited May 29,
2013).

22 Open Handset Alliance, Android FAQ, http://www.openhandsetalliance
.com/android_overview.html (last visited May 29, 2013).

23 ANDROID, http://www.android.com/about/ (last visited May 29, 2013).

24 See also Jacqueline D. Lipton, IP’s Problem Child: Shifting the Paradigms for
Software Protection
, 58 Hastings L.J. 205, 233 (2006) (“It might be much more
useful for the continued development of the software industry if there were some ex
ante test for copyrightability of code. . .”).

25 Some circuits consider both merger and scenes a faire to be doctrines of
infringement which should be applied to the substantial similarity analysis. Others
consider the doctrine one of copyrightability. See Lexmark Int’l, Inc. v. Static
Control Components, Inc
., 387 F.3d 522, 559 (6th Cir. 2004) (Feikens, J. dissenting)
(cataloging circuit split).

26 See Teter, supra note 17 at 1062-63, 1097 (explaining how copyright protection
on code required for compatibility “may enable a software producer to achieve a
far-reaching monopoly” and “affect[] innovation” and acknowledging that while
“elements necessary for compatibility warrant some form of intellectual property
protection, one must acknowledge that copyright is unsuited for the task”); Andrew
B. Hebl, Note, A Heavy Burden: Proper Application of Copyright’s Merger and
Scenes A Faire Doctrines, 8 Wake Forest Intell. Prop. L.J. 128 (2007).

27 See Gates Rubber Co. v. Bando Chem. Indus., Ltd., 9 F.3d 823 (10th Cir. 1993)
(noting that the application of scenes a faire to ‘interfacing’ “has the potential to
effect widely the law of computer copyright”) (citing several other cases which
apply scenes a faire); Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1525-27
(9th Cir. 1993).

23

[PJ: For ECF Certification, Certificate of Compliance, and Certificate of Service, please see the PDF.]

24-26


  


App Developers File Amicus Brief in Support of Google ~pj | 287 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
App Developers File Amicus Brief in Support of Google ~pj
Authored by: Anonymous on Tuesday, June 04 2013 @ 11:52 PM EDT
amicus briefpdf is missing

[ Reply to This | # ]

Corrections
Authored by: Kilz on Tuesday, June 04 2013 @ 11:59 PM EDT
Please list the mistake in the title of your post.

[ Reply to This | # ]

Off Topic
Authored by: Kilz on Wednesday, June 05 2013 @ 12:00 AM EDT
For all posts that are not on topic. Please make links
clickable with HTML.

[ Reply to This | # ]

Newspicks
Authored by: Kilz on Wednesday, June 05 2013 @ 12:02 AM EDT
Please mention the name of the news story in the title of the
top post. A link to the story is also helpful so others can
read the story when the link falls off the home page.

[ Reply to This | # ]

Comes
Authored by: Kilz on Wednesday, June 05 2013 @ 12:03 AM EDT
Please leave all transcriptions of Comes exhibits here for
PJ. Please post the html in Plain Old Text mode so she can
easily copy it.

[ Reply to This | # ]

Trying to explain APIs to non-geeks
Authored by: PolR on Wednesday, June 05 2013 @ 12:28 AM EDT
There is something more than compatibility involved. There is also reuse of
code.

Let's take the C standard library for example. The whole point of the library is
to implement frequently used functionality once so programmers don't have to
write the print function from scratch every time they want to print for example.
There is one standard print function, written once for all in a library, and
everyone uses that.

You can reuse code in all sorts of settings. You don't need to target an
operating system. Any functionality you want to reuse across multiple programs
may go in a library. You may have a library for file compression and
decompression. You may have another library for telephony over the Internet. You
may have a library to access a database. You may put anything you want in a
library as long as it makes sense to reuse the code.

In this setup there are two pieces of code that need to communicate. There is
the code I write, and there is the library I use. The APIs is how we get them to
talk together. Without the APIs I can't reuse the code in the library. This is
where the Logo analogy comes into play. The libraries are a bit like the Logo
bricks that may be reused and assembled. The APIs plays the role of the bumps
and holes that makes everything fit together.

Compatibility is needed when we want many libraries to be interchangeable. If
they all have the same APIs then the libraries may be swapped without rewriting
the existing programs. There are good reasons for doing that. Someone may
discover a better faster or less buggy algorithm. Then a new improved library
with the same APIs will be compatible with all the existing programs. Or the
license may not be GPL compatible so a new library may be written under a
different license.

Then there is the question of how much must be reused. If the Java libraries are
bloated with more functionality than what is needed, then another smaller more
efficient library maybe written. And if some functionality is missing in Java,
the new libraries may implement it. This new library is not compatible in the
sense that the unneeded functionality of Java is missing and new functions are
not in Java. But the functionality that is available on both libraries is
compatible. The advantage is for the programmers. They don't have to learn a new
series of APIs. And some of their code that use the common APIs can use both
libraries. I didn't check but I think the Android vs Java compatibility issues
are of that kind.

A copyright on APIs is a monopoly on the communication and on the knowledge. You
can't swap the libraries because you can't write an alternative library that
uses the same APIs without permission of the monopolist. If someone proposes an
alternative with different APIs, the coders must learn another set of APIs and
then rewrite all the code using the old APIs. This is a big burden. Then the
monopolists can control the advances in technology because no compatible
advances will occur unless they give permission. Anyone using a proprietary API
becomes locked-in.

I think this is what these lawsuits are about, getting control over the
technology. Oracle says "Android is not compatible" but this is an
excuse to get the court to give them the control they want.

[ Reply to This | # ]

Graphics Artists and APIs?
Authored by: Anonymous on Wednesday, June 05 2013 @ 01:47 AM EDT
What exactly is their stake in this game? Can someone please explain?

[ Reply to This | # ]

Why do the amici briefs focus so much on business models?
Authored by: Anonymous on Wednesday, June 05 2013 @ 05:21 AM EDT
Not coming from a common-law jurisdiction, I have some problems understanding
the focus of the amici briefs:
All the amici briefs published here include very detailed descriptions on how a
decision in favour of Oracle would affect the software industry as a whole and
some business models in particular.
But isn't this something important only during legislation?
Court decisions on the other hand shouldn't be concerned with how they affect
certain business models.
Given the importance of precedents in common-law jurisdictions I've expected to
see many court decisions supporting Oracle's or Google's case. But so far I
failed to see any decision, that hasn't been cited before.
What am I missing here?

[ Reply to This | # ]

App Developers File Amicus Brief in Support of Google ~pj
Authored by: JamesK on Wednesday, June 05 2013 @ 08:22 AM EDT
{
And here is the brief, as text:
}

Why are briefs so long? ;-)


---
The following program contains immature subject matter.
Viewer discretion is advised.

[ Reply to This | # ]

Lego bricks
Authored by: Anonymous on Wednesday, June 05 2013 @ 09:01 AM EDT
Isn't that a worryingly terrible analogy?

The bumps and holes of the lego brick, their sizes and spacing and depth,
_were_ protected by copyright, surely?

[ Reply to This | # ]

Our Voices: A Power
Authored by: Anonymous on Wednesday, June 05 2013 @ 01:07 PM EDT

We're (most of us I think) laymen as far as the Law is concerned.

Early in the discussion on software patents, I think Lawyers like Gene Quinn were actually laughing at us. I can just imagine them having done so.

The legal voices have been influencing Patent Law for a long time. The legal discussions with the USPTO members. The legal arguments presented to the Federal Circuit. The legal voices have been quite a strong power in molding Patent Law below the Supremes.

And then along come us mathematicians, software developers, philosophers.....

... and we start speaking of why software shouldn't be patented.

Initially we (the general we of course, not any specific individual) spoke from emotion. And they laughed at us because they knew they had the power and thought our voices weak.

And we learned.... P.J. taught us about the Law. And they still laughed at us because they believed that we wouldn't be heard unless we, ourselves, became Lawyers.

And while we learned, our emotions cooled and our logic took over. And we started painting pictures which mapped how we viewed the situation over how the Law viewed the situation. Merging them into a clear picture. And they still laughed.

All the while, the pro-patent-everything (even patent math) lawyers kept coming here to hone their arguments to take to the Federal Circuit... and to the eventual goal: convince The Supremes! Laughing.

And they failed to see that we were honing our arguments all the while as well. That while their greatest tool was to increase complexity and obfuscation of the situation ("look at the flowchart, there must be something patentable there") - our greatest weapon was to simplify. And they still laughed.

And then They came. When They began to come is unknown. How often They came is unknown. How frequently They still come is unknown.

But They started speaking. They spoke in Their authorings and Their authorings started quoting the information found in blogs.

And then the lawyers started to understand:

    Our voices are being heard by the Supremes!
And now they are no longer honing their argument skills against so much as they are trying to convince us that patenting our work - even software, even math - is in our best interest. And they must be frustrated because we refuse to give in to what we view as their faulty reasoning.

Now the lawyers speak from emotion while we speak from logic. We quote from the Supremes authorings while they attempt to argue around those same authorings. Our opinions as to how existing Law applies to our field of expertise are based on citations while their opinions are becoming less and less backed.

The lawyers are no longer laughing.

And worse - they are recognizing that not only could they lose the patent wars.... they could also lose the copyright wars due to a simple factor:

    Functionality!

I wonder if in 20/50/100 years, history will paint the picture outlined above :)

RAS

[ Reply to This | # ]

Microsoft Antitrus does not help
Authored by: argee on Wednesday, June 05 2013 @ 09:26 PM EDT
In the US vs Microsoft, they were ordered to open up their
API's. This was because MS is a monopoly.

It stands to reason that in the absence of a Monopoly
question, or ordered to do so, they would *not* have to
open up their API's.

Oracle is not a monopoly, and they have not been ordered
to open their API's; ergo, by implication, the US vs MS
decision not only does not hinder Oracle, it seems to
support their version.

You could argue (1) Oracle is a monopoly. I doubt this
would fly, but in any case it is not the case at bar;
and (2) They had already released the API's, where in the
case of MS the API's were secret, and the matter was not
a case of Copyright but of releasing them to the public.


---
--
argee

[ Reply to This | # ]

Functionalities
Authored by: Anonymous on Wednesday, June 05 2013 @ 11:58 PM EDT

Functionalities

APIs are functionalities
They're simple functionalities
Forget about your lawsuit and your fight
You know they're functionalities
They're just a bunch of recipes
APIs are free from copyright

Look at the functionality
The basic functionality
Forget about your lawsuit and your strife
Please Oracle eschew the sleaze
You'll save yourself a ton in fees
You've used others' APIs all your life

(With absolutely no apologies to Disney or anyone else who clings to 45 year old copyrights like the great worm Smaug atop his golden hoard. My deepest apologizes to anyone who tries to make it scan or, Heaven forbid, tries to sing it.)

[ Reply to This | # ]

App developers, precision, APIs, blueprints, and non-lawyer amicus briefs
Authored by: bugstomper on Thursday, June 06 2013 @ 08:47 PM EDT
I have been starting typing this comment since the article that mentioned Eugene
Spafford's amicus brief, but it keeps getting too long and I have to put it
aside. So now I will go just for a summary of points and let this lay unnoticed
at the bottom of 256 other comments, probably moments before PJ posts a new
article and nobody will ever see this :)

1. I noticed that the amicus brief from the app developers had some very precise
language that is a better way of expressing things than what led to the
back-and-forth when PJ referred to "SDK" as opposed to
"API". The app developers were very careful to talk about the
"declaring code" of the APIs as opposed to the implementing code. That
is absolutely the correct terminology to include what in C and C++ you find in
headers, and what in Java is extracted from the full source files to generate
the JavaDoc that is used to document the API. We should adopt that language and
say that the argument with Oracle is whether the declaring code of APIs is
copyrightable.

2. Eugene Spafford et al bases much of his argument on a conflation between the
declaring code of an API and the rest of it. Not all of his arguments disappear
if you replace the term "API" with "declaring code of the
API", but I leave it as an exercise for the reader to go through his amicus
brief making that substitution to see where he is really arguing for the
copyrightability of the implementing code.

3. The most fascinating thing I encountered with the Spafford amicus was when I
realized that my argument with his analogy of API as blueprint was based on
deficiencies with the analogy, but there is something much deeper. To clarify,
my initial reaction was along the lines of

"Blueprints have to specify every detail to allow one to build the plans in
a way that satisfy the building codes and the engineering calculations.
Blueprints tell you what material to use with what precise dimensions, and how
they are attached. An API just tells you that you can find the storeroom by
taking a left down that hallway and then three doors to the right, not how to
build the hallway. APIs are not blueprints!"

Then I realized that not being a lawyer I don't know anything about blueprints
and copyrights. Maybe Spafford doesn't know either. So I googled for the
information. I am still not a lawyer, and so still don't know anything, but here
are some interesting details that I found. For the sake of brevity I will not
include links, but all I had to do was a Google search for

is a blueprint protected by copyright?

It turns out that until a law was passed in 1990 expressly to provide better
protection for architectural design, not much about a blueprint was protected by
US copyright law other than the actual drawing on a piece of paper.

From wikipedia:
"As a result, under the 1976 Act, most courts held that even this grant of
coverage to an architect's plans and drawings did not protect an architect's
right to build structures depicted in the drawings. Courts generally held that
both the utilitarian doctrine prohibiting copyright in useful articles and the
idea-expression dichotomy prohibiting copyright in ideas barred protection of
buildings designed from architectural plans."

The extra protections added to architecture under the 1990 law are limited in
certain ways. Again from Wikipedia, talking about the current state of the law
since 1990:

"In order to obtain protection as an 'architectural work' under 17 U.S.C. §
102(a)(8), as opposed to a 'pictorial, graphic, or sculptural work' under 17
U.S.C. § 102(a)(5), the work must include a design of a building. 'Buildings'
are defined in the Copyright Office as 'humanly habitable structures that are
intended to be both permanent and stationary, such as houses and office
buildings, and other permanent and stationary structures designed for human
occupancy, including but not limited to churches, museums, gazebos, and garden
pavilions'. Specifically prohibited from protection are 'structures other than
buildings, such as bridges, cloverleafs, dams, walkways, tents, recreational
vehicles, mobile homes, and boats'."

There's a lot more detail in other links amongst the first page of Google search
results. But you can see that even if the Spafford, et al amicus brief is
correct that APIs are like blueprints, given that an API does not describe a
"humanly habitable structure" which comes under the special provision
of the 1990 act, that analogy does not help Oracle's claim that the declaring
code of an API is or even should be copyrightable.

[ Reply to This | # ]

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 )