CCIA Files Amicus Brief in Support of Google in Oracle v. Google ~pj

Monday, June 03 2013 @ 04:52 PM EDT

Contributed by: PJ

The Computer & Communications Industry Association (CCIA) has now filed an amicus brief [PDF; also on CCIA's website here] in support of Google in the appeal of Oracle v. Google, and I have it for you as text. Once again, the court has not yet officially accepted it, and there could be corrections, which I'll let you know about if that happens, which it frequently does.

It's a more sophisticated level of argument than some of the others. Oracle, the brief says, is asking to overturn longstanding principles concerning the scope of copyright protection for computer programs, posing serious anticompetitive concerns for the tech industry. Oracle could, if successful, control who can interoperate with its products, leading to a broad monopoly. "The United States and over 40 other countries have recognized that permitting copyright law to impede interoperability would harm legitimate competition in the computer industry and impair the growth of the Internet economy." Amen to that.

"Free trade agreements mandate protections for interoperability," CCIA uniquely points out. "In addition to the reverse engineering exceptions adopted pursuant to the FTAs, legislation favoring interoperability has been adopted in over 40 countries, including many major U.S. trading partners," including the EU, the Pacific Rim, Canada, India, Israel, Kenya, and many others. Trading partners rely on a type of interoperability too, only in the law, not in computer code. If the US makes a sudden 180 turn in its view of copyright protections on interoperability, what happens to that trading partnership? To those free trade agreements? "CCIA, its members, and several litigants and amici here played a major role in creating this global legal environment that fosters interoperability and innovation. This case should not provide a basis for relitigating or legislating against more than two decades of established international law and jurisprudence," the brief concludes.

And the CCIA brief responds to some of the amici supporting Oracle, including Eugene Spafford [PDF] and the the BSA [PDF]. I'd like to do the same, and I'll show you a connection I see between Oracle and SCO Group's theories of copyright, and why I think they are pretty much the same and equally toxic.

Jump To Comments

First, CCIA explains who it is and why it cares:
For more than twenty-five years, CCIA has supported interpreting the intellectual property laws to permit the development of interoperable products. For example, CCIA filed an amicus brief with this Court in Chamberlain Group v. Skylink Techs., 381 F.3d 1178 (Fed. Cir. 2004), arguing that the Digital Millennium Copyright Act’s interoperability exception, 17 U.S.C. 1201(f), provided an alternative ground for affirmance. CCIA also filed amicus briefs with the U.S. Court of Appeals for the Ninth Circuit in Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) (holding that the reverse engineering technique known as disassembly is a fair use as a matter of law when it is the only way to obtain functional elements such as the information necessary for achieving interoperability) and in Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir.), cert. denied, 531 U.S. 831 (2000) (affirming Sega).

In this appeal, Oracle America (“Oracle”) asks this Court to overturn longstanding principles concerning the scope of copyright protection for computer programs and follow instead discredited thirty year old dicta from the Third Circuit in Apple Computer v. Franklin Computer, 714 F.2d 1240, 1253 (3d Cir. 1983), cert. denied, 464 U.S. 1033 (1984) (stating that compatibility is “a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and expression have merged”). Adopting the position that copyright protects the elements of computer programs necessary to achieve interoperability poses serious anticompetitive consequences for CCIA members and the technology industry as a whole.

In other words, CCIA didn't just start caring about these issues last week or when Google became a member. In fact, for most of those 20 years, when CCIA was making these arguments, Sun Microsystem was a member, until bought by Oracle, and for that matter Oracle was a member for a while too.

Its position, then, is because it believes in it. It's who they are and always have been. And here's its principal concern regarding anticompetitive consequences:

If a company could exercise proprietary control over the interface specifications implemented by its products, that company could determine which products made by other firms – if any – could interoperate with its software. And should that company have a dominant position in a particular market, it could use its control over interoperability to expand its dominant position into adjacent markets. Moreover, such authority would extend the rights under copyright beyond what is necessary to protect the original expressive elements that have traditionally been offered protection under American copyright law, and it would override limitations on copyright crafted to protect the public good.

Such a broad monopoly would have serious implications for consumer welfare. In the absence of competition during the effective lifespan of the product, the first developer would have little incentive to develop more innovative and less costly products. These negative consequences would be compounded by the fact that the personal computer revolution and the emergence of the Internet have produced an overwhelming need for interconnection between different elements of computer systems. Prohibiting competitors from accessing de facto standard interface specifications would lock users into a particular operating system or network software environment, and would inhibit the transfer of data between users with different computing environments.

Like Oracle wouldn't want to do a thing like that.

The CCIA brief takes the court on a detailed tour of the world's copyright laws, showing how the laws protect interoperability.

Responding to the Spafford and BSA Briefs

The CCIA brief responds to Professor Eugene Spafford and the BSA amicus briefs like this:

Even Oracle’s amici largely acknowledge as a matter of law and policy what jurisdictions around the world have concluded: copyright does not and should not apply to program elements necessary to achieve interoperability.

Oracle amicus BSA

recognizes that interoperability between computer programs is in many instances desirable both from the perspective of developers and their customers. Operating systems work harmoniously with microprocessors; applications work harmoniously with operating systems; and different types of computers work harmoniously when interacting over the Internet.
BSA Br. at 32. For this reason, courts allow “limited copying of computer programs to make new programs interoperable with existing software or hardware.” Id. at 32-33.

Computer scientists Eugene Spafford, et al., similarly acknowledge the “practical concern … that a developer could leverage its copyright primarily to prevent interoperable products from being developed.” Spafford Br. at 21. Spafford asserts that “the creator of a word processor who wants to be able to open Microsoft Word files in the .doc file format so that they can be used in that creator’s word processing program (i.e., so that the programs are interoperable) must be able to copy the .doc file format.” Id. at 22. Spafford adds that “we do not advocate restraining copying that is required for purposes of interoperability….” Id. at 21.

Notwithstanding the strong support expressed by Oracle’s amici for the principle that copyright should not impede interoperability, they seek reversal of the district court’s decision. BSA punctiliously faults the district court for finding that Oracle’s APIs were not copyrightable, rather than that they were not infringed when Google copied them; see BSA Br. at 27. However, the district court quoted and followed Sega’s explicit holding that functional aspects “are not protected.” See Oracle Am., Inc. v. Google, Inc., 872 F. Supp. 2d 974, 994 (N.D. Cal. 2012) (quoting Sega, 977 F.2d at 1522). Moreover, the district court did not hold that no API received copyright protection, only that these particular APIs did not. See id. at 1002. And it certainly did not hold that the source code implementing the API did not receive copyright protection. Thus, the vast majority of the software created by Sun and acquired by Oracle remains protected.

Oracle’s amici also contradict the facts of the case, suggesting that Google’s copying was not motivated by the imperative of interoperability, but by a desire to appeal to programmers skilled in Java. BSA Br. at 33; Spafford Br. at 20. The district court, however, found that “in order for at least some [preexisting] code to run on Android… Google replicated what was necessary to achieve a degree of interoperability.” Oracle v. Google, 872 F. Supp. 2d at 1000.

In the previous article, the amicus brief by the group of intellectual property law professors, written by Pamela Samuelson, also responded to Spafford, citing Sony Computer Entertainment, Inc. v. Connectix, Inc., where Connectix emulated the Sony functionality of Sony's Playstation, and the court ruled that the Sony interface procedures were unprotected elements, even though the Connectix software "aimed to be a substitute for the plaintiff's product" and was not fully compatible with the Playstation games.

Now, I'd like to take a bit of a detour now myself to respond a bit. Mr. Spafford joined with Prof. Lee Hollaar, who longtimers at Groklaw will remember from his amicus brief in In Re Bilski, which demeaned FOSS, inaccurately, and argued, also inaccurately, that software isn't mathematics ("But in most instances, the correspondence between computer programs and mathematics is merely cosmetic.") Actually, it is mathematics, and he was wrong about FOSS as well, so what Mr. Spafford is doing joining forces with him in support of Oracle is a mystery to me. I'll have to put it in the same pile of mysteries where I put the oddity that Oracle and Microsoft are now on the same side.

Who saw that coming?

Hollaar was also quoted and referenced ad nauseum by some antiGPL trolls, like Daniel Wallace, and they used to come to Groklaw to annoy everybody with their attacks on the GPL and me for years and years, so the name is well-known here. He also appeared in the Caldera v. Microsoft case as an expert for Caldera, later calling itself the SCO Group. He's a professor in Utah, so that's probably not a surprise. And he appeared as an expert witness in a defamation case back in 2007, where he minimized Gary Kildall's contributions to computer science. His expert report [PDF] is germane, because here is what it argued, on page 9:

40. Extending copyright protection to cover any implementation of a particular API would be an impermissible protection of the idea expressed in the API and the process or system used to perform the function of the API.

41. Had Digital Research wanted to protect the procedures used by CP/M, the proper route would have been through patent rather than copyright.... Attempting to claim copyright for the API of CP/M would essentially give patent-like protection without having to meet the patent requirements of novelty and nonobviousness, and is clearly against public policy.

Yup. Clearly. "Clearly against public policy" to extend "copyright protection to cover any implementation of a particular API." Just a note for historians: Tim Paterson, who wrote QDOS, for whom Hollaar was an expert in that litigation and for whom he wrote those words, signed EFF's amicus brief on behalf of Google. It's Hollaar singing a different song now! His latest brief describes Java APIs as marvelously creative expressions of design, like a blueprint. Blech. So many ways to design them:
As a consequence of this great design flexibility, the expression of an API reflects the author’s imagination and creativity rather than rigid dictates of pre-determined functions. For a complex API, authoring the design may require greater creativity, talent, experience, and subjective judgment than authoring the underlying source code.
If the code is functional, as Google points out, under Copyright Law, it doesn't matter if it's creative. Java APIs, Google concedes, meet the low bar of creativity required under the law in Section 102(a) for some "thin" copyright protection, except that then they fall under the functional code exception of Section 102(b).

I'd like to focus on one sentence in the Spafford/Hollaar brief in addition, because I believe it is misleading in part and wrong, or maybe just too casually written, in another.

I know. Who am *I*?

Nobody, but I checked with tech folk who *do* know, and I believe this is correct information. Mr. Spafford writes (or maybe Mr. Hollaar contributed this part):

An API thus consists of two different types of source code: a design that prescribes the expected behavior and structure of the API; and an implementation that performs the design.
In the latter part of the sentence, I think he's conflating an API with an SDK.

An API is a specification of the interface used to integrate with or make use of libraries or services. The API is usually expressed as source code, but only in the sense of header files, not in the sense of implementation.

The SDK is a bunch of source and/or binary code that make using the API easier.

Example: To write programs that run on Windows, they have to make use of the Windows API. Now, MS provides a convenient windows SDK (and compilers) that make it easy for you to target that API. But you don't have to. You could use the definition of the API, and hand-write machine code that targeted it. It would take ages, but it would be possible. More sensibly, you could write your own SDK that targeted the same API - this is exactly what the Mingwin tools do. They have a Windows port of GCC, the Windows API headers, and a clean-roomed set of SDK libraries. Thus, you can write Windows programs using only the Windows API header files as MS's IP.

Now Android is not compatible with Java only in the sense that Oracle specifies as being necessary for their grant of license. But that simply puts the question back to can you copyright an API? If not, that Oracle license is void. You can't offer a copyright license on something you are not allowed by law to copyright. So far the court has held that an API is just a bunch of headers and thus not worthy of copyright protection, functional code. Oracle can pick any bunch of files they want and call it "the API", but that doesn't matter. What matters is what files Google used. If they only used the header files, necessary for a level of interoperability, then they didn't use the implementation and they didn't cross a legal line. And that is what the judge ruled.

If I take a photo and put it in a frame and give it to you, you can't copy the photo, but you can take the photo out of the frame and do what you want with it. The fact that I choose only to give you the frame with a photo in it doesn't magically extend my copyright in the photo to the frame.

Or a possibly better analogy: if I write a book, and the book contains facts, you can't copy the whole book or great chunks of it, but you can take the raw facts from that book and do what you want with them. The fact I've put the facts in my book doesn't give me ownership of those facts, even if that is the only way you found out those facts. Because they are facts, and not expression.

However Oracle chooses to deliver the facts of its Java API, the fact remains that the API definition is *a set of facts*, not an expression. The API does not -- because it cannot -- tell you how to implement it: an API is a sort of black-box contract saying "if you call this, this this will happen and no more."

In a full implementation you need both the working code and the interface required to use the code. But the interface exists as an individual component which is separable from the full implementation. The acronym API stands for Application Programming Interface. It refers only to the interface component.

Oracle is not claiming Google infringed on their full implementation of Java libraries. They are claiming copyright on the interface components, the header files, and argue Google infringes on that.

The SCO Connection

Years ago, we at Groklaw did an article on APIs and ABIs, and Groklaw member Frank Sorenson wrote very thoroughly on ABIs and why SCO was all wet, because SCO Group was trying for the same thing Oracle is trying for, to get copyright protection for header files, only in SCO's case it was on ABIs, not APIs, so we did an explanation of the difference. API stands for Application Programming Interface and ABI stands for Application Binary Interface.

Anyway, the difference, casually phrasing it, is that ABIs are what the computer can read and APIs are human readable. You can see that in the names. And our article explained that APIs are interfaces. Kind of like a light switch is an interface.

An interface is just a means or mechanism that allows two parties to connect or communicate with each other. When you flip on a light switch, you are using that particular interface (the light switch) to connect with the wiring of your home. The switch allows an abstraction of what is actually going on in your walls.

Another example is the way you communicate with a computer. How do you connect to a computer? You give it a command. How do you accomplish that? You have to use the mouse to click on a program, and then use the keyboard to type some parameters. Your desktop setup, the way the screen is painted, the way the mouse interacts with icons, the way the keyboard allows input, all of that is an interface, commonly called a graphical user interface, or GUI, since there are icons and the like. If you are using the Linux command line, your user interface leaves out the graphics part and the interface is primarily the keyboard alone. So an interface allows one party or entity to connect or communicate with another party or entity.

The same thing happens behind the scenes with your computer. Programs have to connect and communicate with each other, and the way they do that is by means of interfaces. A typical API will list all the functions the programmer can use, along with all the types of data the functions can be used to manipulate. It is an interface, a list of facts, you could say.

This needs to be made clear, because the court ruled that Google did not use the Java implementation code and that these particular APIs were not copyrightable because they were necessary for the degree of interoperability desired.

Incidentally, since SCO is trying to resuscitate its litigation against IBM, I'll just mention that Warren Toomey of the Unix Heritage Society also wrote about SCO's header claims, and in that article you can read a section from SCO's interrogatories responses about what it thought it owned, based on a wrong reading of the BSDi settlement agreement. It was Groklaw that arranged to make public that previously private settlement agreement, which is when SCO's claims about the agreement went poof. Then it turned out SCO didn't own the copyrights it was threatening Linux with, it didn't own the copyrights on anything Unix prior to 1995, so double poof.

But they are a clever bunch, the SCOfolk, or more accurately their lawyers are, and so I'm staying tuned to see if they try to introduce at least some of their claims as contract issues or related to post-1995 code, and one of their pending motions is a request to be allowed to pursue a claim about methods and concepts as opposed to direct copyright infringement. Methods and concepts are kind of the same thing as SSOs, which is what Oracle is claiming, and SCO Group and Oracle share one lawyer -- David Boies. It wouldn't amaze me if he's trying to use Oracle to get a ruling that can come in handy in the IBM case, should it get going again.

I think the methods and concepts claim is bunk anyway, for more than one reason, but that doesn't mean SCO won't try to use it if it can get the court to let it. Bunk is SCO's middle name, if you followed their flame out in the courts. Here's an article on Groklaw by Peter Salus and Mr. Toomey on just exactly why SCO's methods and concepts theory was hilariously off-base, given the history of Unix.

I'm going through all this history because I think it's important to notice the parallels between what SCO Group was trying for in copyright law and what now Oracle is trying for. It's the same theory, and it was horrible when SCO did it, and it's horrible now that Oracle is following in SCO's footsteps. And here's SCO Group's theory on methods and concepts from 2004, an interview Steven J. Vaughan-Nichols did with then-SCO executives Darl McBride and Chris Sontag, where they used an illustration about Vanilla Ice riffs and Harry Potter:

McBride: A lot of code that you'll be seeing coming on in these copyright cases is not going to be line-by-line code. It will be more along the lines of nonliteral copying, which has more to do with infringement. This has more to do with sequence, organization, which is copyright-protectable. It's interesting when you go down this path that everyone wants to go to the exact lines of code, but most copyright cases…

Sontag: 90 to 95 percent

McBride: …are not line-by-line, exact copies. It's too obvious. Most copyright infringement cases come from these nonliteral implementations of the same code or literary work.

Sontag: My favorite example is the Russian author [Dmitry Yemets], who lost in a copyright case [after being sued by] J.K. Rowling, author of the 'Harry Potter' books, in a Dutch court. He had written a book: It was a girl, not a boy, with magical powers who rides a magical fiddle and not a broom, goes to a boarding school to learn witchcraft and wizardry, plays a game of throwing balls through hoops. All these things were very similar to Harry Potter. Could someone else ever write a book about wizards and witches? Sure. But when the structure and sequence is the same…maybe the words, the code, isn't exactly the same, but Linux is trying to be just like Unix System V. The question is whether Linux was trying to be like Unix System V by doing it in ways that were illegal.

McBride: Before all of this is said and done, you'll see people saying that SCO already published a lot of this stuff in books but that these books contained copyright-protected materials.

What book are you talking about? Lions' book?

Editor's Note: "Lions' Commentary on UNIX 6th Edition with Source Code" by Tom Lions is a book for Unix developers that, decades after it was published, is still regarded as one of the best guides on a Unix-style operating system.

McBride: No, that's ancient stuff. We're talking about recent stuff posted as a result of the BSD [Berkeley Software Design Inc.] settlement. There are things out there that help people understand how to program to System V application binary interfaces [ABIs], to help them hook up to the OS. It was out there to help people write applications. It wasn't published to help someone knock off the OS and create a free version of System V.

Sontag: If I can get my hands on it, it's mine.

McBride: I saw it, it was published, so the cows are out of the barn. The analogy I like to use is Vanilla Ice's "Ice Ice Baby" versus David Bowie and Queen's "Under Pressure." If you just look at the words, I don't see a copyright violation, but if you listen to the riffs, you can hear where they're the same.

Editor's Note: Vanilla Ice settled out of court presumably because his song included riffs that had been taken from Bowie and Queen's work. See Copyright Website LLC for more on the issue.

McBride: When everything is said and done, when everything is on the table in the court case, there will be an argument when the Linux guys come in and say, 'Guys, the words are entirely different, how can you say that's a copyright violation?'

But there are two parts to this. There are the words that are in the source code, and there's the music underneath. The actual code that drives these ABI files is structurally and sequentially the same.

What about the argument that, given the nature of the language and the design goals, that of course you'd end up with similar structures. I mean, how many efficient ways are there to write 'hello world' [the canonical beginner's program]?

McBride: We'll give them 'hello world.'

Sontag: Sure, there may be some of that, but look at dynamic shared libraries; different operating systems implement these very differently. But in Linux and System V, they're implemented in exactly the same way. They could have been done very differently and still accomplish the same thing.

McBride: That's the kind of stuff that we think that, when everything is on the table, will win for us.

Dream on. But now do you see why Oracle's appeal brief begins by talking about "Ann Droid" misusing Harry Potter? Isn't that eerily the same?
Ann Droid wants to publish a bestseller. So she sits down with an advance copy of Harry Potter and the Order of the Phoenix—the fifth book—and proceeds to transcribe. She verbatim copies all the chapter titles—from Chapter 1 (“Dudley Demented”) to Chapter 38 (“The Second War Begins”). She copies verbatim the topic sentences of each paragraph, starting from the first (highly descriptive) one and continuing, in order, to the last, simple one (“Harry nodded.”). She then paraphrases the rest of each paragraph. She rushes the competing version to press before the original under the title: Ann Droid’s Harry Potter 5.0. The knockoff flies off the shelves. J.K. Rowling sues for copyright infringement. Ann’s defenses: “But I wrote most of the words from scratch. Besides, this was fair use, because I copied only the portions necessary to tap into the Harry Potter fan base.”

Obviously, the defenses would fail.

Defendant Google Inc. has copied a blockbuster literary work just as surely, and as improperly, as Ann Droid—and has offered the same defenses.

It's the same theory, as far as I can see, and the same lawyer, trying to make computer copyright law the same as copyright law for works of fiction. It's not the same, because computer software *does* stuff. You don't just sit down and read it. It has a function. And if it ever becomes the same for software as for novels, it will destroy software development.

Not that SCO cared. It wanted a complete monopoly on all software, everybody's, so it could rake in the dough. Anybody know if Oracle has a reputation for loving money?

: )

David Boies is not a geek, so he may not even grasp the damage he seems to be trying to orchestrate. But I can't make the same excuse for Oracle (or SCO), both tech companies. They know. And may I just ask, like a child noticing the emperor has no clothes on, why, oh why, is Oracle wanting to act like SCO? Anyway, I just wanted to point out the sameness of the two plots, because I think it's important to understand the undertow strategies I see, threatening to pull us all under the water's surface. Software is written incrementally, building on what went before. The cloud depends on open APIs. If you put copyright on functional code, it really is a monopolist's dream, where you can't do a thing without permission from the monopoly. Here we are in a world where mobile phones and tablets are making PCs like trucks are to cars. Some people use trucks, and they always will, because they are good for certain tasks, but most people just use a car. It's the cloud that makes that work.

When Microsoft ruled the PC world, did you enjoy that monopoly? Would you like to go back to that type of monopoly control in mobiles? In the cloud? You can see from the amicus briefs pouring into the court that folks that understand the threat are absolutely appalled, just as the world was by SCO's toxic antics.

Actually, Oracle's history shows there are things it cares about more than money. It was Larry Ellison who had the guts to stand up to Microsoft back when others were afraid to do so publicly. He stood up first, and because he did others followed, and the US v. Microsoft case changed that world. I guess you could say he left a dent in the universe. I know he comprehends that some things are more important than 37 Java APIs, but what I'm not sure of is whether he understands what the copyright theory his lawyers are adopting means for the industry. When he took his position against Microsoft back then, he said he did it in the public service. He can do the same again. That's why I took the time to really explain the copyright legal theory the best I can, in hopes that he'll read it, and force the lawyers to tack. Lawyers have to do what the client tells them to do, you know. It's not the other way around.

Of course, that means that responsibility for what the lawyers do rests squarely on the shoulders of the client.

And one more connection, speaking of monopoly. Microsoft gave financial support to SCO. And it has filed an amicus brief in support of Oracle. It opens like this:

This case tests the copyrightability of computer programs, specifically packages of source code that are part of the Java software platform used by third-party software developers to write applications for computers, tablets, smartphones, and other devices running Java.
Not so. It's about is about 37 Java APIs, or more precisely their structure, sequence and order, not about software "programs" or "source code" as most people understand those words.

Guess what Microsoft tells the court copyright law covers? Yup. The same Vanilla Ice riffs argument SCO used appears:

Congress has determined that computer software is eligible for copyright protection. 17 U.S.C. § 101. Copyright protects computer software in several important respects. It covers the literal lines of code that comprise software, generally preventing their reproduction or distribution without permission from the rightsholder. But copyright also covers certain non-literal elements of the software as well. For example, the "structure, sequence, and organization" of a software product -- above and beyond the 1s and 0s that make up the program at its literal level or the exact words of the human-readable source code -- can, in some instances, be protected by the copyright in the work. As a result, copyright infringement in a software case can occur even when the defendant did not copy the underlying developers' code, where the defendant has copied some other, non-literal element of the software subject to copyright protection.
Sun Microsystems paid SCO off too, not just Microsoft.

Getting the picture?

Here's is the CCIA 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.

_________________

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

_______________

BRIEF OF AMICUS CURIAE OF THE COMPUTER &
COMMUNICATIONS INDUSTRY ASSOCIATION
IN SUPPORT OF CROSS-APPELLANT GOOGLE
URGING AFFIRMANCE

______________

Matthew Schruers
Vice President, Law & Policy
Computer & Communications
Industry Association
[address, phone, email ]

Jonathan Band
Jonathan Band PLLC
[address, phone, email]

Counsel of Record

May 30, 2013

CERTIFICATE OF INTEREST

Pursuant to Rule 26.1 of the Federal Rules of Appellate Procedure and Federal Circuit Rule 47.4, Jonathan Band, counsel for amicus curiae the Computer & Communications Industry Association certifies the following:

1. The full name of the party represented by me is the Computer & Communications Industry Association.

2. The name of the real party in interest represented by me is the Computer & Communications Industry Association.

3. The Computer & Communications Industry Association is not a subsidiary of any corporation and has issued no stock.

4. The names of all law firms and attorneys that appeared for the party now represented by me in this proceeding are Jonathan Band PLLC, Jonathan Band, and Matthew Schruers.

May 30, 2013

/s/ Jonathan Band
Jonathan Band
Jonathan Band PLLC
[address, phone, email]
Counsel of Record

ii

TABLE OF CONTENTS

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

TABLE OF CONTENTS ........................ iii

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

INTEREST OF AMICUS CURIAE .............. 1

INTRODUCTION AND SUMMARY OF ARGUMENT ...............3

ARGUMENT .................... 9

I. COURTS AND LEGISLATURES AROUND THE WORLD
RECOGNIZE THAT COPYRIGHT MUST NOT INTERFERE
WITH INTEROPERABILITY .................. 9
A. The Two Principles Fostering Interoperability ............... 9

B. The Global Debate Over Interoperability ................ 12

1. Advocacy in Interoperability Cases ................. 13

2. The Interoperability Exception in the DMCA ................. 16

3. Free Trade Agreements Mandate Protections for
Interoperability ...................19

C. Copyright Laws Around the World Protect Interoperability .............20
1. European Union Law Mirrors the U.S.
Pro-Interoperability Approach..............20
a. The Software Directive .................. 20

b. SAS Institute v. World Programming Ltd. ...............21

2. Pacific Rim Policy Aligns with U.S. and European
Pro-Interoperability Law ........................... 23

3. Other Regions Also Embrace Interoperability .................... 28

iii

II. ORACLE’S AMICI AGREE THAT ELEMENTS NECESSARY
FOR INTEROPERABILITY DO NOT RECEIVE COPYRIGHT
PROTECTION ................... 29
CONCLUSION .........................31

CERTIFICATE OF COMPLIANCE ...................... 33

CERTIFICATE OF SERVICE ....................... 34

iv

TABLE OF AUTHORITIES

Cases

Page(s)

Alcatel U.S.A. v. DGI Techs., 166 F.3d 772 (5th Cir. 1999) .............11

Apple Computer v. Franklin Computer,
714 F.2d 1240 (3d Cir. 1983) ................2

Apple Computer v. Microsoft, 35 F.3d 1435 (9th Cir. 1994) ..............14

Atari Games v. Nintendo of America,
975 F.2d 832 (Fed. Cir. 1992) .............11

Bateman v. Mnemonics, Inc.,
79 F.3d 1532 (11th Cir. 1996) ............11, 14

Bonito Boats v. Thunder Craft Boats, 489 U.S. 141 (1989)10

Bowers v. Baystate, 320 F.3d 1317 (Fed. Cir. 2003)3, 14

Chamberlain Group v. Skylink Techs,,
381 F.3d 1178 (Fed. Cir. 2004) .................1, 3, 14

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

Davidson v. Jung, 422 F.3d 630 (8th Cir. 2005) ................4, 14

DSC Commc’ns Corp. v. DGI Techs.,
898 F. Supp. 1183 (N.D. Tex. 1995) ....................11

DSC Commc’ns Corp. v. DGI Techs.,
81 F.3d 597 (5th Cir. 1996) .................11

DSC Commc’ns Corp. v. Pulse Commc’ns, Inc., 976 F. Supp.
359 (E.D. Va. 1997), aff’d in part, rev’d in part, and vacated
in part
, 170 F.3d 1354 (Fed. Cir. 1999) ......................11

DVD Copy Control Assoc. v. Brunner,
113 Cal. Rptr. 2d 388 (Cal. Ct. App. 2001) ......................... 3, 14

v

eBay v. MercExchange, 547 U.S. 388 (2006) .................. 7

Engineering Dynamics v. Structural Sys.,
26 F.3d 1335 (5th Cir. 1994) ..................... 14

Gates v. Bando, 9 F.3d 823 (10th Cir. 1993) ...................14

Hybritech Inc. v. Monoclonal Antibodies, Inc.,
802 F.2d 1367 (Fed. Cir. 1986) ...................... 31

Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470 (1974) .................10

Lexmark v. Static Control, 387 F.3d 522 (6th Cir. 2004) ..............4, 14

Lotus Dev. Corp. v. Borland Int’l,
49 F.3d 807 (1st Cir. 1995) ................ 5, 14

Lotus Dev. Corp. v. Borland Int’l, 516 U.S. 233 (1996) ............ 3, 5, 14

Mitel v. Iqtel, 124 F.3d 1366 (10th Cir. 1997) ..................15

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

ProCD v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996) .................. 14

Pulse Commc’ns v. DSC Commc’ns, 528 U.S. 923 (1999) ...............3, 14

SAS Inst. v. World Programming Ltd., Case C‑406/10,
May 2, 2012, ¶ 71 ...................... 22, 23

Saltarelli v. Bob Baker Group Med. Trust,
35 F.3d 382 (9th Cir. 1994) ................... 31

Sega Enters., Ltd. v. Accolade, Inc.,
785 F. Supp. 1392 (N.D. Cal. 1992) .................... 14

Sega Enters., Ltd. v. Accolade, Inc.,
977 F.2d 1510 (9th Cir. 1992) ................... 2, 11, 14, 30

Sony Computer Entm’t v. Connectix Corp.,
203 F.3d 596 (9th Cir. 2000) ................... 2, 3, 11, 14

vi

Unix Sys. v. Berkeley Software, 832 F. Supp. 790 (D.N.J. 1993) ..........14

Whelan Assocs., Inc. v. Jaslow Dental Lab., Inc.,
797 F.2d 1222 (3d Cir. 1986) ...................... 5

STATUTES

17 U.S.C. § 101 ..................... 6

17 U.S.C. § 1201 ................. 2, 16, 17, 18

MISCELLANEOUS

American Committee for Interoperable Systems, Statement of
Principles (1991) ....................13

Jonathan Band & Masanobu Katoh,
Interfaces on Trial: Intellectual Property and Interoperability
in the Global Software Industry
(1995).........passim

Jonathan Band & Masanobu Katoh,
Interfaces on Trial 2.0 (2011) ....................passim

Dan L. Burk, Anticircumvention Misuse,
50 UCLA L. Rev. 1095 (2003) .................. 4

Copyright Act, No. 14 of 1957; India Code (1999), § 52(1)(ab),
at http://www.wipo.int/wipolex/en/ text.jsp?file_id=128098...............28

Copyright Act, 5767-2007, LSI 2199 (2007) (Israel), § 24(c)(3),
at http://www.wipo.int/wipolex/en/ text.jsp?file_id=132095....................28

Copyright Act, (2009) Cap. 130 § 26(5) (Kenya),
at http://www.wipo.int/wipolex/en/text.jsp? file_id=202207.................28

Copyright (Amendment) Act 2012, Laws of Malaysia, Act
A1420, § 36A(2)(a), at http://malaysianlaw.my/attachments/
Act-A1420-Copyright-A-Act_81389.pdf....................27

vii

Copyright Modernization Act (Bill C-11),
S.C. 2012, c. 20 (Can.), s. 30.61 ...............................29

Copyright (New Technologies) Amendment Act 2008, § 43 (N.Z.)
(2008 No. 27) at http://www.legislation.govt.nz/act/public/2008/
0027/latest/DLM1122604.html ...................27

Council of Ministers Directive 91/250/EEC of 14 May 1991 on
the Legal Protection of Computer Programs, 1991 O.J. (L 122)
................................20, 21

Karen Gullo & Cornelius Rahn, “SAP to Pay Oracle $306
Million for Copyright Breach,” Bloomberg.com, Aug. 3, 2012,
available at http://www.bloomberg.com/news/2012-08-02/
oracle-says-sap-to-pay-306-million-in-copyright-deal.html ...............7

U.S.-Korea Free Trade Agreement,
June 30, 2007, 8 U.S.T. 2217 .....................19

Peter S. Menell, An Analysis of the Scope of Copyright
Protection for Application Programs
, 41 Stan. L. Rev. 1045 (1989) ................4

Press Release, Sun Microsystems, House IP Subcommittee Action
Threatens Internet Competition (Mar. 1, 1998) ......................16

Recommendation of the Register of Copyrights, Rulemaking on
Exemptions from Prohibition on Circumvention of Copyright
Protection Systems for Access Control Technologies
(Docket No. RM 2002-4, Oct. 27, 2003) .................. 18

Response of the United States to Microsoft’s Motion for
Summary Judgment, U.S. v. Microsoft,
1998 U.S. Dist. LEXIS 14231 (D.D.C. Sept. 14, 1998) ..............15

S. Rep. No. 105-190 (1998) ......................17

U.S. Congress, Office of Technology Assessment, Finding a
Balance: Computer Software, Intellectual Property, and the
Challenge of Technological Change
, OTA-TCT-527
(Washington, DC: U.S. Government Printing Office, May
1992) ........................3, 6

viii

INTEREST OF AMICUS CURIAE 1

The Computer & Communications Industry Association (“CCIA”) 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. 2

Effective intellectual property protection gives developers incentive to create new applications. At the same time, improper extension of copyright law to functional elements will impede innovation and inhibit competition in the computer industry.

For more than twenty-five years, CCIA has supported interpreting the intellectual property laws to permit the development of interoperable products. For example, CCIA filed an amicus brief with this Court in Chamberlain Group v. Skylink Techs., 381 F.3d 1178 (Fed. Cir. 2004), arguing that the Digital Millennium Copyright Act’s interoperability

1

exception, 17 U.S.C. 1201(f), provided an alternative ground for affirmance. CCIA also filed amicus briefs with the U.S. Court of Appeals for the Ninth Circuit in Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) (holding that the reverse engineering technique known as disassembly is a fair use as a matter of law when it is the only way to obtain functional elements such as the information necessary for achieving interoperability) and in Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir.), cert. denied, 531 U.S. 831 (2000) (affirming Sega).

In this appeal, Oracle America (“Oracle”) asks this Court to overturn longstanding principles concerning the scope of copyright protection for computer programs and follow instead discredited thirty year old dicta from the Third Circuit in Apple Computer v. Franklin Computer, 714 F.2d 1240, 1253 (3d Cir. 1983), cert. denied, 464 U.S. 1033 (1984) (stating that compatibility is “a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and expression have merged”). Adopting the position that copyright protects the elements of computer programs necessary to achieve interoperability poses serious anticompetitive consequences for CCIA members and the technology industry as a whole.

2

INTRODUCTION AND SUMMARY OF ARGUMENT

Oracle and its amici repeatedly compare the Java Application Program Interface (“API”) to novels. Computer applications, however, are different from artistic works. A novel stands by itself. A computer application, however, can function only in conjunction with hardware and other software. For example, a word processor requires an operating system in order to perform its task; otherwise, it is a useless set of magnetic impulses. This requirement is “interoperability” – a term “used to describe a situation in which a program from one vendor is able to exchange information with a program from a different vendor.” 3 Two applications can interoperate only by conforming to the same set of rules, or interface specifications. 4 The APIs at issue here are an example of such specifications.

3

If a company could exercise proprietary control over the interface specifications implemented by its products, that company could determine which products made by other firms – if any – could interoperate with its software. And should that company have a dominant position in a particular market, it could use its control over interoperability to expand its dominant position into adjacent markets. 5 Moreover, such authority would extend the rights under copyright beyond what is necessary to protect the original expressive elements that have traditionally been offered protection under American copyright law, and it would override limitations on copyright crafted to protect the public good.

Such a broad monopoly would have serious implications for consumer welfare. 6 In the absence of competition during the effective lifespan of the product, the first developer would have little incentive to develop more innovative and less costly products. These negative consequences would be compounded by the fact that the personal computer revolution and the

4

emergence of the Internet have produced an overwhelming need for interconnection between different elements of computer systems. Prohibiting competitors from accessing de facto standard interface specifications would lock users into a particular operating system or network software environment, and would inhibit the transfer of data between users with different computing environments. See Lotus Dev. Corp. v. Borland Int’l, 49 F.3d 807, 821 (1st Cir. 1995) (Boudin, J., concurring), aff’d by an equally divided Court, 516 U.S. 233 (1996).

In short, in the computer industry, overly broad intellectual property protection directly restricts competition and innovation. This was the status quo in the computing environment in the 1970s. Once a buyer purchased a computer system, the buyer was essentially locked-in to that system: the system was incompatible with products manufactured by other companies, and conversion costs were high. Although “locking in” was extremely profitable for dominant vendors such as IBM, competitors and users suffered from high prices, indifferent service, limited choice, and slow innovation. Jonathan Band & Masanobu Katoh, Interfaces on Trial 2.0 (2011), at 1.

Fortunately, as the district court explained in detail, U.S. courts rejected the approach embodied by the Third Circuit’s dicta in Franklin and holding in Whelan Assocs., Inc. v. Jaslow Dental Lab., Inc., 797 F.2d 1222

5

(3d Cir. 1986), cert. denied, 479 U.S. 1031 (1987), and found instead that interface specifications fall on the idea (or unprotected) side of copyright’s idea/expression dichotomy. These more recent rulings have enabled the transition from the locked-in computer environments of the 1970s to today’s interoperable Internet. These courts, including the district court, have not created software-specific copyright doctrines. Rather, they have applied traditional copyright principles to software, concluding that “[t]o give one creator a monopoly over these basic elements would effectively stunt the efforts of other creators to elaborate on these elements in the production of their own works.” See Office of Tech. Assessment at 143. As courts have become more familiar with software, they have understood that although computer programs are classified under the Copyright Act as literary works, an application has little in common with actual works of literature other than that both are expressed in symbols. An application is more like an appliance than a Harry Potter novel in that, while both the appliance and the application manifest aspects of design and creativity, both are fundamentally used to “bring about a certain result.” 17 U.S.C. § 101 (defining “computer program”). Accordingly, the copyright protection in computer programs is “thin,” protecting lines of code, detailed structure, and graphical user interfaces, but leaving unprotected the elements necessary to achieve

6

interoperability and other systems and methods of operation. This is neither a value judgment nor a suggestion that engineers are less creative than novelists. Rather, it recognizes the basic fact that an applied work of engineering functions differently from a work of art or entertainment, and as a consequence, works of engineering receive a different scope of copyright protection. To say that interface specifications necessary for interoperability are not protected, and that software copyright is thin, is not to withhold copyright protection from software platforms. Title 17 still provides ample protection, without going through the effort of a patent prosecution, and offers robust remedies for copyright infringement in appropriate cases. 7

This brief will not repeat the parties’ substantive arguments. Instead, following Chief Justice Roberts’ teaching that “a page of history is worth a volume of logic,” eBay v. MercExchange, 547 U.S. 388, 394 (2006) (Roberts, J., concurring) (citations omitted), it provides an overview of how U.S. courts, Congress, and jurisdictions around the world have, over the past 25 years, arrived at a consensus interpretation of the copyright question of

7

interoperability. 8 This pro-interoperability approach has two related principles. First, copyright protection does not extend to program elements necessary for interoperability, such as interface specifications. Second, the copying incidental to the reverse engineering necessary to identify these interface specifications does not infringe copyright.

At the outset of the “interoperability debate,” CCIA and another organization with overlapping membership, the American Committee for Interoperable Systems (“ACIS”), along with leading members of both organizations, 9encouraged a pro-interoperability interpretation of copyright law in amicus briefs in at least sixteen different cases. CCIA and ACIS also lobbied vigorously, and successfully, for an interoperability exception in the Digital Millennium Copyright Act (“DMCA”), a provision now mandated by eleven free trade agreements to which the United States is a party. A sister organization to ACIS, the European Committee for Interoperable

8

Systems (“ECIS”), also supported interoperability principles in the European Union Software Directive. In fact, industry advocacy for interoperability extended to the Pacific Rim and the Middle East.

After reviewing the history of the adoption of a global copyright framework supportive of software interoperability, this brief turns to arguments by Oracle’s amici. While professing to support the principle that copyright should not prevent the reproduction of program elements necessary for interoperability, these amici nevertheless invite this Court to turn back the clock on a quarter century of established domestic and international software copyright jurisprudence. CCIA urges the Court to decline that invitation.

ARGUMENT

I. COURTS AND LEGISLATURES AROUND THE WORLD
RECOGNIZE THAT COPYRIGHT MUST NOT INTERFERE
WITH INTEROPERABILITY.

A. The Two Principles Fostering Interoperability

Over the past twenty-five years, U.S. courts, Congress, and foreign jurisdictions have repeatedly applied copyright law in a manner that supports interoperability. Decision-makers around the world have adopted two related principles to this end. First, they have determined that copyright does not protect interface specifications and other program elements

9

necessary for interoperability. Second, they have refused to treat as copyright infringement any reproductions performed in the course of the reverse engineering necessary to discern these interface specifications.

The first principle – the non-protectability of interface specifications – was correctly decided by the district court, and has been briefed extensively in this appeal. The second principle – the permissibility of reverse engineering – is not directly at issue in this case, but its treatment reflects how decision-makers view the first principle. Because a program’s interface specifications usually are not readily apparent, and may not be available, developers seeking to interoperate often must research the interface specifications of the original program. This research, known as reverse engineering, is a basic tool of software product development. Without it, interoperability can be difficult or impossible to achieve. 10

10

Copyright law, however, has the potential of raising obstacles to software reverse engineering. Because of the nature of computer technology, software reverse engineering almost always requires the making of a reproduction or derivative work. Since this Court’s 1992 decision in Atari Games Corp. v. Nintendo of America, 975 F.2d 832 (Fed. Cir. 1992), however, no less than five U.S. courts have permitted reproduction during the course of software reverse engineering under the fair use doctrine. 11 Other courts have prevented enforcement under a copyright misuse theory. 12

The permissibility of reverse engineering is relevant to this case in that courts and legislatures logically would allow reverse engineering only if the reverse engineer could use the information he learned by the reverse engineering. The cases cited above all involved reverse engineering for purposes of interoperability. Likewise, as will be discussed below, Congress and foreign legislatures have adopted copyright exceptions that permit reverse engineering for purposes of achieving interoperability. Such

11

exceptions make sense only if the information necessary to achieve interoperability (here, APIs) are not covered by copyright.

B. The Global Debate Over Interoperability

The courts and legislatures did not adopt interoperability principles in a vacuum. Two competing industry constituencies, one representing the dominant software and hardware companies, the other representing new entrants, engaged in a fierce “two-decade global debate” that included litigation advocacy and lobbying on all continents except for Antarctica. See Interfaces 1.0, at 14.

Oracle amicus Business Software Alliance (“BSA”) was one association advocating the perspective that copyright could be used to restrict access to interface specifications and prohibit reverse engineering. These positions concerned leaders from new entrants in the hardware and software industry. Troubled by the competitive implications of copyright-restricted interface specifications, they first convened in Silicon Valley at Sun’s corporate headquarters on December 5, 1991, to organize a response to this threat. Chaired by Sun’s Deputy General Counsel Peter Choy, this group – ACIS – agreed upon a Statement of Principles, chiefly, that “[t]he rules or specifications according to which data must be organized in order to communicate with another program or computer, i.e. , interfaces and access

12

protocols, are not protectable expression under copyright law”, and that copyright does not “restrict the ability of others to reproduce all or part of a lawfully obtained program as a step in the development of competing products….” American Committee for Interoperable Systems, Statement of Principles (1991), available at http://www.ccianet.org/interop.

Subsequently joining CCIA and ACIS in the global interoperability debate were ECIS, the Canadian Association for Interoperable Systems (“CAIS”) and the Supporters of Interoperable Systems in Australia (“SISA”), all of whom subscribed to the position that copyright should not extend to interface specifications, nor restrict reverse engineering. 13

1. Advocacy in Interoperability Cases

The district court has extensively recounted prior case law concerning the non-protectability of interface specifications. In many of these disputes, CCIA or ACIS participated as amici in support of copyright principles favorable to interoperability. 14 These included cases on non-protectability of

13

interface specifications, 15 permissibility of software reverse engineering, 16 and the interoperability exception of the DMCA. 17 U.S. copyright law ultimately settled on a rule now internationally recognized: that copyright protection does not extend to interface specifications necessary for interoperability.

The resolution of the interoperability debate in the courts precipitated a change in U.S. domestic and foreign policy. In 1994, it was reflected in competition policy, as Assistant Attorney General Anne K. Bingaman noted in a speech that

14

[t]he substantive reach of the exclusive rights granted under the intellectual property laws has been a matter of particular concern and ferment in the software industry.... The scope of copyright protection for computer software has, we believe, important competitive implications, as well as important implications for incentives to innovate. 18
The U.S. Government eventually took the position that interface specifications should not receive copyright protection in its antitrust case against Microsoft. The Justice Department had objected to certain restrictions in licensing agreements, and, citing Computer Associates v. Altai, argued that copyright is not an unbounded property right, but rather a limited power designed to incentivize creation. The Government stated, “it is by now well established that the copyright in a computer program cannot extend to the functional aspects of that computer program; to design choices dictated by necessity, cost, convenience or consumer demand.” 19 To support this statement, it summarized Mitel v. Iqtel, 124 F.3d 1366 (10th Cir. 1997), as follows: “interface specifications of a communications protocol are freely copiable because they are functional rather than expressive.” 20

Interoperability also found support elsewhere in the U.S. Government, as the Federal Trade Commission also expressed concern in relation to

15

Article 2B of the Uniform Commercial Code, insofar as it could limit the reverse engineering permitted under Sega, and thereby dampen competition in the software industry. See Interfaces 2.0, at 67-70.

2. The Interoperability Exception in the DMCA

Section 1201 of the Digital Millennium Copyright Act, enacted by Congress in 1998, restricts the development, distribution, and use of technologies that circumvent other technologies that protect an author’s copyrights. While the DMCA was pending before Congress, CCIA and ACIS explained that the act of reverse engineering could require the circumvention of a technological protection measure. 21 Moreover, the incorporation of these specifications in competitive products could run afoul of the DMCA’s prohibition on the manufacture and distribution of circumvention technologies. This would particularly be the case when a company placed a software “lock” on a program that prevented access to the program, and the competitor circumvented that software lock to achieve interoperability. Thus, Section 1201 could prevent a developer of

16

interoperable products from exercising his fair use privileges recognized in Sega and its progeny.

Notwithstanding opposition from BSA, CCIA and ACIS’s pro-interoperability advocacy ultimately prevailed, and Congress included in the DMCA an exception explicitly directed at software reverse engineering and interoperability. Section 1201(f) specifically allows software developers to circumvent technological protection measures in a lawfully obtained computer program in order to identify the elements necessary to achieve interoperability of an independently created computer program with other programs. 22 Furthermore, a person may develop, distribute, and employ the means to circumvent technological protection measures for the purpose of achieving interoperability.

The Senate Judiciary Committee report on the DMCA explained the policy underlying Section 1201(f) as being “intended to allow legitimate software developers to continue engaging in certain activities for the purpose of achieving interoperability to the extent permitted by law prior to the enactment of this chapter.” S. Rep. No. 105-190 (1998), at 29. The Committee evidently understood that if a company placed on its program a

17

technological measure that prevented interoperability, a legal prohibition on circumventing that technological protection could preclude other companies from developing products capable of operating in that company’s computing environment. Citing Sega, the Committee stated that “[t]he objective is to ensure that the effect of current case law interpreting the Copyright Act is not changed by enactment of this legislation for certain acts of identification and analysis done in respect of computer programs.” Id. The Committee concluded by noting that “[t]he purpose of this section is to foster competition and innovation in the computer and software industry.” Id.

In a 2003 rulemaking adopting exemptions to the DMCA, the U.S. Copyright Office affirmed that Section 1201(f) has the effect of “enabling competitive choices in the marketplace.” Recommendation of the Register of Copyrights, Rulemaking on Exemptions from Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies, at 172 (Docket No. RM 2002-4, Oct. 27, 2003), available at http://www.copyright.gov/1201/docs/registers-recommendation.pdf. In particular, the Office found that Section 1201(f)(3) permitted the

18

incorporation of interface information in products for the purpose of achieving interoperability. 23 Id.

3. Free Trade Agreements Mandate Protections for
Interoperability

Pro-interoperability principles also influenced the contours of U.S. trade agreements. Since 2002, the United States has negotiated a series of free trade agreements (“FTAs”), which, inter alia, include provisions modeled on DMCA section 1201. In addition to requiring parties to adopt prohibitions on the circumvention of technological protection measures, these provisions permit countries to adopt exceptions for reverse engineering for the purpose of achieving interoperability. Thus, each party may permit
[n]oninfringing reverse engineering activities with regard to a lawfully obtained copy of a computer program, carried out in good faith with respect to particular elements of that computer program that have not been readily available to the person engaged in those activities, for the sole purpose of achieving interoperability of an independently created computer program with other programs.
U.S.-Korea Free Trade Agreement, art. 18.4.7(d)(i), June 30, 2007, 8 U.S.T. 2217. 24 The FTAs with the following countries include similar language

19

permitting the adoption of exceptions for reverse engineering for purposes of interoperability: Australia, Bahrain, Chile, Colombia, Costa Rica, Dominican Republic, El Salvador, Guatemala, Honduras, Morocco, Nicaragua, Oman, Panama, Peru, and Singapore. As in the United States, many of these countries have adopted reverse engineering exceptions in their domestic law. 25

C. Copyright Laws Around the World Protect Interoperability

In addition to the reverse engineering exceptions adopted pursuant to the FTAs, legislation favoring interoperability has been adopted in over 40 countries, including many major U.S. trading partners.

1. European Union Law Mirrors the U.S. Pro-
Interoperability Approach

a. The Software Directive

In 1991, after a vigorous three-year lobbying battle between BSA and ECIS, the European Union adopted the Software Directive. 26 Council of Ministers Directive 91/250/EEC of 14 May 1991 on the Legal Protection of Computer Programs, 1991 O.J. (L 122). The Directive that emerged from

20

this political process reflects a policy judgment that copyright should not interfere with interoperability. The Software Directive has been implemented by all member states of the EU, as well as Croatia, Norway, Russia, Switzerland, and Turkey. Interfaces 2.0, at 6.

Article 5(3) of the Directive provides a broad exception from liability for “black box reverse engineering” – activities such observing the behavior of a program as it runs, input/output tests, and line traces. Article 6 provides a narrower exception for decompilation – what Atari and other U.S. courts have called “disassembly.” Decompilation or disassembly involves translating machine-readable object code into a higher level, human readable form. Article 6 permits decompilation for purposes of achieving interoperability when the information has not previously been made available; the decompilation is limited to those parts of the program necessary for interoperability; and the final product created by the reverse engineer does not infringe on the copyright of the original product.

b. SAS Institute v. World Programming Ltd.

The Software Directive does not directly address the protectability of interface specifications. Rather, Article 1(2) provides that “[i]deas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright….”

21

Commentators interpreted this to mean that interface information necessary to achieve interoperability must fall on the idea side of the idea/expression dichotomy; otherwise, the detailed decompilation provision in Article 6 would be of little utility. However, this issue received scant attention from European courts for 20 years, until May 2012, when the European Union’s highest court, the Court of Justice of the European Union (“CJEU”), ruled in SAS Institute v. World Programming Limited 27 that program functionality, programming languages, and data formats were not protectable under the Software Directive.

The case concerned SAS Institute’s computer program for statistical analysis. SAS users typically create “scripts” or programs that run on top of the SAS System through a programming language known as the SAS Language. World Programming Limited (“WPL”) sought to compete with SAS by creating “middleware” software that could run users’ scripts written in the SAS Language just like the SAS System did To do so, WPL created a program that emulated SAS. SAS sued, claiming that even though WPL did not copy SAS’s source code, WPL’s program nonetheless infringed on SAS’s copyrights, inter alia, by replicating (i) the SAS programming language, (ii) the data and programming interfaces used in the SAS system

22

and (iii) the functionality offered by the SAS System.

The CJEU ruled that Article 1(2) of the Software Directive “must be interpreted as meaning that neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for purposes of that directive.” Id. The CJEU explained that “to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.” Id., ¶ 40. The CJEU observed that “the main advantage of protecting computer programs by copyright” as opposed, presumably, to patents, “is that such protection covers only the individual expression of the work and thus leaves other authors the desired latitude to create similar or even identical programs,” id., ¶ 41, provided that they refrain from copying protected expression. In other words, the CJEU reached precisely the same conclusion as the district court here.

2. Pacific Rim Policy Aligns with U.S. and European
Pro-Interoperability Law

The policy battles described above between the members of BSA and the members of CCIA and ACIS repeated themselves throughout the Pacific

23

Rim, where policymakers have also arrived at a view consistent with that of U.S. and Europe. During a decade-long copyright law review in Australia, SISA filed numerous submissions in support of an exception for reverse engineering for purposes of interoperability. 28 SISA was opposed by dominant companies organized in the Computer and Business Equipment Manufacturers Association. In the end, SISA prevailed; Australia adopted reverse engineering exceptions modeled on articles 5(3) and 6 of the EU Software Directive.

The Attorney-General of Australia, the Hon. Daryl Williams QC, explained the government’s rationale for introducing these exceptions. With the advent of the Internet, “there is an obvious need for computers and the programs which drive them to communicate, connect, or ‘interoperate’ with each other.” Speech on Copyright Amendment (Computer Program) Bill 1999, Second Reading (Aug. 11, 1999) (quoted in Interfaces 2.0, at 152). The Attorney-General then explained the need for interface information in order to achieve interoperability, and how this information as a technical matter can often be obtained only through reverse engineering. The Attorney-General noted that “the law of the leading software producing country in the world, the United States, allows makers of new programs to

24

use decompilation to find out the interface information of existing programs for achieving interoperability. The countries of the European Union, and other countries, also allow this to be done.” Id.

A similar discussion occurred in Hong Kong, in the months before the turnover to China, where the Legislative Council worked on revising its copyright laws. 29 The Bills Committee in April 1997 held a public hearing on software reverse engineering. For ACIS, Sun’s counsel Peter Choy testified in favor of a reverse engineering exception; a BSA representative testified against it. The Legislative Council decided to broaden Hong Kong’s fair dealing provision to more closely resemble the fair use provision of the U.S. Copyright Act. The Secretary of Trade and Industry explained that this amendment was intended “to encourage competition in the information technology industry by facilitating timely access to information and ideas underlying computer programs.” Speech by Secretary of Trade and Industry on Resumption of Second Reading, Debate at 10 (June 24, 1997) (quoted in Interfaces 2.0, at 175). She added that “the object is to allow decompilation to be deemed a fair use….” Id.

25

Singapore also amended its fair dealing provision to more closely track fair use. 30 In introducing the amendment, the Attorney-General of Law stated that it “will bring us in line with the United States, the United Kingdom, other European Union countries, Hong Kong, and Australia, which do not bar the use of copyright materials for commercial research.” 31 Id. at 166. Professor Chin Tet Yung, in the brief debate of the amendment in Parliament, said that it “is very important to ensure that there is a fair balance in any Copyright Bill between the interests of holders of rights in ‘cutting edge’ software and the interest of competitors who want to design and market non-infringing competing programmes which interface or are inter-operable with the basic programmes.” Id. In 2004, Singapore further amended its copyright law to include provisions modeled on the black box reverse engineering and the decompilation provisions of the Software Directive.

The copyright laws of other Pacific Rim countries have been amended to encourage interoperability. In the Philippines, the legislature in 1997 inserted the following sentence in the fair use provision: “Decompilation, which is the reproduction of code and translation of the form of the

26

computer program indispensable to obtain the information necessary to achieve the inter-operability of an independently created computer program with other programs may also constitute fair use.” 32 Taiwan in 2007 added a fair use provision similar to section 107, as well as a reverse engineering exception to its circumvention prohibition. In 2008, the Parliament in New Zealand adopted reverse engineering exceptions based on the EU Software Directive, permitting decompilation “necessary to obtain information necessary for the objective of creating an independent program that can be operated with the program decompiled or with another program….” 33 In 2012, Malaysia added a circumvention prohibition, with an exception for “the sole purpose of achieving interoperability of an independently created computer program with the original program or any other programs.” 34

27

3. Other Regions Also Embrace Interoperability

India permits “the doing of any act necessary to obtain information essential for operating interoperability of an independently created computer programme with other programmes….” 35 Kenya provides that authorization “shall not be required to decompile [a] program, convert the program into a version expressed in different programming language, code, notation for the purpose of obtaining information needed to enable the program to operate with other programs.” 36 Likewise, Israel allows the copying of a computer program to “obtain[] information which is needed to adapt a different and independently developed computer system or program, in such a way that it will be interoperable with the computer program.” 37 Canada last year amended its copyright law to permit the owner or licensee of a copy of a computer program “to reproduce the copy for the sole purpose of obtaining information that would allow the person to make the program and any other

28

computer program interoperable.” Copyright Modernization Act (Bill C-11), S.C. 2012, c. 20 (Can.), s. 30.61. 38

II. ORACLE’S AMICI AGREE THAT ELEMENTS NECESSARY
FOR INTEROPERABILITY DO NOT RECEIVE COPYRIGHT
PROTECTION.

Even Oracle’s amici largely acknowledge as a matter of law and policy what jurisdictions around the world have concluded: copyright does not and should not apply to program elements necessary to achieve interoperability.

Oracle amicus BSA

recognizes that interoperability between computer programs is in many instances desirable both from the perspective of developers and their customers. Operating systems work harmoniously with microprocessors; applications work harmoniously with operating systems; and different types of computers work harmoniously when interacting over the Internet.
BSA Br. at 32. For this reason, courts allow “limited copying of computer programs to make new programs interoperable with existing software or hardware.” Id. at 32-33.

29

Computer scientists Eugene Spafford, et al., similarly acknowledge the “practical concern … that a developer could leverage its copyright primarily to prevent interoperable products from being developed.” Spafford Br. at 21. Spafford asserts that “the creator of a word processor who wants to be able to open Microsoft Word files in the .doc file format so that they can be used in that creator’s word processing program (i.e., so that the programs are interoperable) must be able to copy the .doc file format.” Id. at 22. Spafford adds that “we do not advocate restraining copying that is required for purposes of interoperability….” Id. at 21.

Notwithstanding the strong support expressed by Oracle’s amici for the principle that copyright should not impede interoperability, they seek reversal of the district court’s decision. BSA punctiliously faults the district court for finding that Oracle’s APIs were not copyrightable, rather than that they were not infringed when Google copied them; see BSA Br. at 27. However, the district court quoted and followed Sega’s explicit holding that functional aspects “are not protected.” See Oracle Am., Inc. v. Google, Inc., 872 F. Supp. 2d 974, 994 (N.D. Cal. 2012) (quoting Sega, 977 F.2d at 1522). Moreover, the district court did not hold that no API received copyright protection, only that these particular APIs did not. See id. at 1002. And it certainly did not hold that the source code implementing the API did not

30

receive copyright protection. Thus, the vast majority of the software created by Sun and acquired by Oracle remains protected.

Oracle’s amici also contradict the facts of the case, suggesting that Google’s copying was not motivated by the imperative of interoperability, but by a desire to appeal to programmers skilled in Java. BSA Br. at 33; Spafford Br. at 20. The district court, however, found that “in order for at least some [preexisting] code to run on Android… Google replicated what was necessary to achieve a degree of interoperability.” 39 Oracle v. Google, 872 F. Supp. 2d at 1000.

CONCLUSION

The United States and over 40 other countries have recognized that permitting copyright law to impede interoperability would harm legitimate competition in the computer industry and impair the growth of the Internet economy. CCIA, its members, and several litigants and amici here played a major role in creating this global legal environment that fosters interoperability and innovation. This case should not provide a basis for relitigating or legislating against more than two decades of established

31

international law and jurisprudence. Even now, Congress is undertaking a comprehensive review of copyright law; if litigants or amici wish to undo a quarter century of copyright jurisprudence, that debate should be had before Congress.

Respectfully submitted,

Matthew Schruers
Vice President, Law & Policy
Computer & Communications
Industry Association
[address, phone, email]

/s/ Jonathan Band
Jonathan Band
Jonathan Band PLLC
[address, phone, email]
Counsel of Record

May 30th, 2013

32

CERTIFICATE OF COMPLIANCE

1. This brief complies with the type-volume limitations of Fed. R. App. P. 32(a)(7)(B) because it contains 6,726 words, excluding the parts of the brief exempted by Fed. R. App. P. 32(a)(7)(B)(iii) and Federal Circuit Rule 32(b).

2. This brief complies with the typeface requirements of Fed. R. App. P. 32(a)(5) and the types style requirements of Fed. R. App. P. 32(a)(6) because it has been prepared in a proportionally spaced typeface using Microsoft Word in 14 point Times New Roman.

/s/ Jonathan Band
Jonathan Band
Jonathan Band PLLC
[address, phone, email]
Counsel of Record

May 30th, 2013

33

CERTIFICATE OF SERVICE

I hereby certify, that on this 30th day of March 2013, a true and correct copy of the foregoing Brief of Amicus Curiae the Computer & Communications Industry Association was timely filed electronically with the Clerk of the Court using CM/ECF, which will send notification to all counsel registered to receive electronic notices.

/s/ Jonathan Band
Jonathan Band
Jonathan Band PLLC
[address, phone, email]
Counsel of Record

34

1 No counsel for any party authored this brief in whole or part; no such party or counsel made a monetary contribution intended to fund its preparation or submission; and no person other than amicus made such a contribution. All parties have consented to the filing of this brief.

2 A list of CCIA members is available at http://www.ccianet.org/members. Google is a CCIA member, and Oracle and Sun were formerly members of CCIA, but none of these parties took any part in the preparation of this brief.

3 U.S. Congress, Office of Technology Assessment, Finding a Balance: Computer Software, Intellectual Property, and the Challenge of Technological Change, at 127, OTA-TCT-527 (Washington, DC: U.S. Government Printing Office, May 1992), available at http://ota.fas.org/reports/9215.pdf.

4 See amicus brief filed by CCIA and the American Committee for Interoperable Systems (ACIS) in Lotus Dev. Corp. v. Borland Int’l, 516 U.S. 233 (1996). CCIA has advanced similar arguments in numerous other amicus briefs, including Lotus; Pulse Commc’ns v. DSC Commc’ns Corp., 528 U.S. 923 (1999); Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir.), cert. denied, 531 U.S. 831 (2000); DVD Copy Control Assoc. v. Brunner, 113 Cal. Rptr. 2d 388 (Cal. Ct. App. 2001); Bowers v. Baystate, 320 F.3d 1317 (Fed. Cir. 2003); Chamberlain Group v. Skylink Techs., 381 F.3d 1178 (Fed. Cir. 2004); Lexmark v. Static Control, 387 F.3d 522 (6th Cir. 2004); and Davidson v. Jung, 422 F.3d 630 (8th Cir. 2005). CCIA’s reverse engineering arguments in section I.A., infra , and the DMCA in section I.C.3., infra , have also been advanced in many of these cases.

5 Dan L. Burk, Anticircumvention Misuse, 50 UCLA L. Rev. 1095, 1113, 1133 (2003).

6 See, e.g., Peter S. Menell, An Analysis of the Scope of Copyright Protection for Application Programs, 41 Stan. L. Rev. 1045, 1082, 1097 n.281 (1989).

7 See, e.g., Karen Gullo & Cornelius Rahn, “SAP to Pay Oracle $306 Million for Copyright Breach,” Bloomberg.com, Aug. 3, 2012, available at http://www.bloomberg.com/news/2012-08-02/oracle-says-sap-to-pay-306
-million -in-copyright-deal.html.

8 This history is discussed in detail in two books co-authored by counsel of record on this brief. Jonathan Band & Masanobu Katoh, Interfaces on Trial: Intellectual Property and Interoperability in the Global Software Industry (1995), available at http://www.policybandwidth.com/interfaces-2-0 (hereinafter “Interfaces 1.0”); and Band & Katoh, Interfaces on Trial 2.0 (2011), available at http://mitpress.mit.edu/books/interfaces-trial-20 (hereinafter “Interfaces 2.0”).

9 Companies from across industry, ranging from Amdahl to Zenith, and including Oracle and Sun Microsystems (which developed the Java APIs prior to its 2010 acquisition by Oracle), were active CCIA and/or ACIS members. Sun’s Deputy General Counsel chaired ACIS for much of its existence.

10 The U.S. Supreme Court has long recognized that there is nothing inherently wrong with studying a competitor’s product to understand how it works and to figure out how to make a better product. Thus, in Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470, 476 (1974), the Court stated that “trade secret law … does not offer protection against discovery by fair and honest means, such as … by so-called reverse engineering, that is by starting with a known product and working backward to divine the process which aided in its development or manufacture.” The Court has also recognized the benefits of reverse engineering: “Reverse engineering … often leads to significant advances in technology.” Bonito Boats, Inc. v. Thunder Craft Boats, Inc., 489 U.S. 141, 160 (1989).

11 Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); DSC Commc’ns Corp. v. DGI Techs., 898 F. Supp. 1183 (N.D. Tex. 1995), aff’d, 81 F.3d 597 (5th Cir. 1996); Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); DSC Commc’ns Corp. v. Pulse Commc’ns, Inc., 976 F. Supp. 359 (E.D. Va. 1997), aff’d in part, rev’d in part, and vacated in part, 170 F.3d 1354 (Fed. Cir. 1999); Sony Computer Entm’t v. Connectix Corp., supra n.4.

12 DSC Commc’ns Corp. v. DGI Techs., id.; Alcatel U.S.A. v. DGI Techs., 166 F.3d 772 (5th Cir. 1999).

13 See Interfaces 1.0, supra . Both Oracle and Sun were CCIA members at this time, as well as members of ACIS, ECIS, and SISA. Interfaces 1.0, id. at 308. Sun joined CCIA in 1993 and remained a member until its 2010 acquisition by Oracle. Oracle was a member of CCIA from 1993 until 2011. Google only joined CCIA in 2006, decades after CCIA’s pro-interoperability advocacy began.

14 See http://www.ccianet.org/interop. BSA and other associations, such as the Computer and Business Equipment Manufacturers Association, filed briefs in various cases opposing this view. See generally Interfaces 1.0, 99-101 (recounting parties’ general arguments).

15 See Computer Assocs. Int’l v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992) (brief by ACIS); Gates v. Bando, 9 F.3d 823 (10th Cir. 1993) (brief by ACIS); Unix Systems v. Berkeley Software, 832 F. Supp. 790 (D.N.J. 1993) (brief by ACIS); Apple Computer v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994) (brief by ACIS); Engineering Dynamics v. Structural Sys., 26 F.3d 1335 (5th Cir. 1994); (brief by ACIS); Lotus Dev. Corp. v. Borland Int’l, 49 F.3d 807 (1st Cir. 1995) (brief by ACIS); aff’d by an equally divided Court, 516 U.S. 233 (1996) (briefs by ACIS and CCIA).

16 See Sega v. Accolade, 785 F. Supp. 1392 (N.D. Cal. 1992) (brief by ACIS), rev’d, 977 F.2d 1510 (9th Cir. 1992) (briefs by ACIS and CCIA); Bateman v. Mnemonics, Inc., supra n.11 (brief by ACIS); ProCD v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996) (brief by ACIS); Pulse Commc’ns v. DSC Commc’ns Corp., supra n. 4 (brief by CCIA); Sony Computer Entm’t v. Connectix Corp., supra n. 4 (briefs by ACIS and CCIA); DVD Copy Control Assoc. v. Brunner, supra n. 4 (briefs by ACIS and CCIA); Bowers v. Baystate, supra n. 4 (brief by CCIA).

17 See Chamberlain v. Skylink, supra n. 4 (brief by CCIA); Lexmark Int’l v. Static Control, supra n. 4 (brief by CCIA); Davidson v. Jung, supra n. 4 (brief by CCIA).

18 Quoted in Interfaces 1.0, at 64.

19 Response of the United States to Microsoft’s Motion for Summary Judgment, U.S. v. Microsoft, 1998 U.S. Dist. LEXIS 14231 (D.D.C. Sept. 14, 1998), at 77.

20 U.S. Response, supra , at 79.

21 In a 1998 press release, Michael Morris, then Vice President and General Counsel of Sun Microsystems, argued that the legislation would “impose[] a new and unnecessary layer of restraint on lawful access to those unprotected elements of computer programs that are necessary to achieve interoperability, thus placing developers of interoperable products at the mercy of proprietary vendors.” Press Release, Sun Microsystems, House IP Subcommittee Action Threatens Internet Competition (Mar. 1, 1998).

22 Section 1201(f)(4) defines interoperability “as the ability of computer programs to exchange information, and of such programs mutually to use the information which has been exchanged.”

23 CCIA and ACIS lobbied Congress and the Administration against other proposals that may have threatened interoperability, including legislation regarding criminal penalties for infringement of software (S. 893 in the 102nd Congress), industrial design protection (H.R. 1790 in the 102nd Congress), database protection, and software patents. Additionally, these groups sought a reverse engineering exception to the proposed Article 2B of the Uniform Commercial Code. See Interfaces 2.0, at 68.

24 CCIA assisted the Office of the United States Trade Representative in the drafting of this language.

25 CCIA and ACIS advocated pro-interoperability positions in connection to other international agreements such as TRIPS and the World Intellectual Property Organization Copyright Treaty.

26 This legislative battle between BSA, ECIS, including ECIS members Oracle and Sun, is discussed in detail in Interfaces 1.0, at 227-41.

27 Case C‑406/10, May 2, 2012, ¶ 71, available at
http://curia.europa.eu/juris/liste.jsf?num=C-406/10.

28 See Interfaces 2.0, at 136-58.

29 See Interfaces 2.0, at 168-75.

30 See Interfaces 2.0, at 158-68.

31 See Second Reading of Copyright (Amendment) Bill of 1998 (Sing.)
(February 19, 1998) (quoted in Interfaces 2.0, at 166-67).

32 ACIS submitted comments to the Philippine government arguing in favor of an interoperability exception. ACIS also argued in favor of interoperability exceptions in Japan and Korea. See Interfaces 1.0, at 297-316; Interfaces 2.0, at 178-80.

33 Copyright (New Technologies) Amendment Act 2008, § 43 (N.Z.) (2008 No. 27) at http://www.legislation.govt.nz/act/public/2008/0027/latest/ DLM1122604.html (amending Copyright Act 1994, § 80A(2)). CCIA submitted comments to the New Zealand government in support of interoperability.

34 Copyright (Amendment) Act 2012, Laws of Malaysia, Act A1420, § 36A(2)(a), available at http://malaysianlaw.my/attachments/Act-
A1420-Copyright-A-Act_81389.pdf.

35 Copyright Act, No. 14 of 1957; India Code (1999), § 52(1)(ab), available at http://www.wipo.int/wipolex/en/text.jsp?file_id=128098.

36 Copyright Act, (2009) Cap. 130 § 26(5) (Kenya), available at http://www.wipo.int/wipolex/en/text.jsp?file_id=202207.

37 Copyright Act, 5767-2007, 2007 LSI 2199 (Israel), § 24(c)(3), available at http://www.wipo.int/wipolex/en/text.jsp?file_id=132095. For ACIS, Sun’s Choy submitted comments to the Israeli Knesset arguing in favor of an interoperability exception.

38 Further, the amendment permits circumvention “for the sole purpose of obtaining information that would allow the person to make the program and any other computer program interoperable.” See id., 41.12(1). CAIS, whose members included Sun, submitted comments in favor of interoperability exceptions in the Canadian copyright law.

39 Whether the district court correctly found that Google was attempting “to achieve a degree of interoperability” is a finding of fact reversible only if it is clearly erroneous. Hybritech Inc. v. Monoclonal Antibodies, Inc., 802 F.2d 1367, 1375 (Fed. Cir. 1986); see also Saltarelli v. Bob Baker Group Med. Trust, 35 F.3d 382, 384 (9th Cir. 1994).

183 comments



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