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).
|