Source: https://www.thefreelibrary.com/Let+the+hackers+hack%3A+allowing+the+reverse+engineering+of+copyrighted+...-a012477328
Timestamp: 2019-04-20 14:48:40+00:00

Document:
Let the hackers hack: allowing the reverse engineering of copyrighted computer programs to achieve compatibility.
Imagine that you are a computer programmer, and you have come up with a great idea. You would like to develop an ingenious program that will take any English document and translate it into Basque. You realize, however, that virtually everyone in the United States uses a program called WriteIt for their word processing. Unless your translator can accept documents created with WriteIt, it will be virtually unmarketable. Making your program compatible will likely be extremely difficult, and you will need to know a great deal of information about WriteIt in order to succeed. To make matters worse, the makers of WriteIt, fearing even the remotest possibility of competition, have refused to extend any support.
Will it be possible to develop your Basque translator? The necesary information cannot be obtained by examining the copies of WriteIt that are sold in stores--they are completely unreadable, consisting entirely of millions of zeros and ones that only the computer can understand.(3) It is possible to reverse engineer(4) the WriteIt program, transforming the ones and zeros to a form that is readable by humans. Your lawyers inform you, however, that this reverse engineering would be a very costly copywritht infringement. Your dreams of a Basque translator have been unceremonously dashed, and the world has lost a potentially great and innovative computer program.
While a Basque translator may not be a "must have" program for most users, many other innovative and useful programs are kept from the market because of their inability to achieve compatibility with existing software. The illegality of reverse engineering under current copyright law is a serious obstacle to developers who legitimately desire to create compatible software. This Comment addresses the problem of reverse engineering under current copyright law, and proposes that a "compatibility exemption" be added, allowing reverse engineering for the development of innovative, compatible programs.
Section I briefly describes the technology of computer software and the copyright laws under which it is protected. It then describes the basic dilemma which this Comment attempts to solve: a computer program cannot legally be analyzed because (1) programs cannot be understood by humans unless they are reverse engineered; and (2) reverse engineering is itself a violation of copyright law. Section II examines the scope of protection available for computer software and compares it to the protection available for other copyrighted works and other technologies. It concludes that the current protection of computer software is too strict, because it inadvertently allows the ideas of a program to be hidden. The subsequent effect is a restriction on development in the software industry, particularly in the development of compatible software. Section III discusses the costs and benefits of compatibility, and concludes that the development of compatible programs is essential to innovation in the computer industry. Section IV examines the problem of piracy, which is the primary fear of most software developers. It describes how the current ban on reverse engineering has been used to protect against piracy and suggests that a total ban causes more problems that it solves. Instead of banning all reverse engineering efforts, the law should instead focus on separating the legitimate development of software from unwanted pircy. Finally, Section V contains a proposal for a solution to the reverse engineering dilemma--a compatibility exemption, derived from copyright's fair use doctrine, which distinguishes between piracy and desirable efforts to create compatible software.
A computer program, as defined by copyright law, is "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result."(5) These programs, also known as software, operate as a link between computers and the people using them, allowing users to perform very complex tasks without concern about circuits, chips, and the other mysteries hidden inside the machine. When stored within the memory of a computer, a program is kept as a long string of "ones" and "zeros," with each number represented as a high or low voltage. Each group of these binary digits is an instruction that causes the computer to perform a very basic task, such as "add" or "move." Programs in this format are said to be written in "machine language" or "object code."(6) Although it is possible for engineers to write software in machine language, the process is extraordinarily difficult and tedious, and virtually never done.(7) Instead, programs are written in easily understood, higher-level languages,(8) which are later translated into the object code that will operate the computer.(9) Software written in this format is known as source code.
For each of these layers to work together, the programs in a computer must be compatible. Generally defined, programs are compatible when they can work together or work in place of each other. There are, however, many different types of compatibility, and the refusal to distinguish between these types has been a major stumbling block in the understanding of compatible software.(14) In order to achieve any form of compatibility, programs generally must share the same "interface"--the order and system by which data is stored, retrieved, and output.(15) Some programs will use another program's interface so that their program may "link up" to the other, usually to facilitate the exchange of information. Other programs will use the interface so that the compatible program and the original program will act identically--sending the two programs identical input will produce identical output. Knowledge of a program's interface is essential to the development of any compatible program, regardless of which form of compatibility is sought.
These definitions of idea and expression completely changed the scope of software protection, extending protection "beyond the programs' literal code to their structure, sequence, and organization."(30) A program may therefore infringe a prior work even though its object and source code are completely different from the prior work.
Copyright law, while protecting the rights of authors, allows others freely to study and analyze their works, so that further advances can be made in their field. For example, a director of suspense films can study the works of past masters in order to perfect her ability. She may replay Alfred Hitchcock's films frame-by-frame, analyzing his ideas and his expression of those ideas. Although she cannot duplicate any of Hitchcock's works, she may use his ideas without infringing his copyrights. Similarly, a science fiction writer could peruse the copyrighted works of Isaac Asimov and Arthur C. Clarke, observing their writing styles and using their ideas to create new stories. The same right to analyze and extract ideas is currently extended to all copyrighted works, with the exception of computer software.
Despite the necessity of reverse engineering in discovering a program's ideas, current copyright law treats reverse engineering as an infringement. This dilemma arises from the particular process of decompiling software. In order to reverse engineer most technologies, there is no need to actually copy the product; one only needs to purchase a number of examples of the product and then take them apart.(50) When a computer program is reverse engineered, however, a number of copyright violations occur in the process. Generally, a copy of the program must first be made in the computer's memory.(51) The copy must then be translated into a source code, a process which may involve the creation of several additional copies of the program.(52) The final source code version will itself constitute an unauthorized derivative work of the original object code,(53) and merely printing the results on paper will result in the production of further unauthorized copies.
The process of decompiling software, therefore, is likely an infringement of copyright. Because the discovery of a program's ideas can only be accomplished through such decompilation, the end result is that its ideas are inadvertently protected under copyright. There is, however, no public policy for allowing the ideas of software, and no other copyrighted works, to remain hidden. Rather, this protection exists solely because: (1) computer programs, unlike all other copyrighted works, can be sold in object code form that will fulfill their designed purpose while remaining indecipherable to humans; and (2) decompilation, the only way to understand such object code, constitutes a copyright violation.
As noted above, current copyright law allows developers of software to keep the ideas of their programs hidden. Is this too much protection for computer software? To make this determination, one must look to the goals of copyright law first enumerated in the Constitution.(58) "[T]he ultimate purpose of copyright legislation is to foster the growth of learning and culture for the public welfare, and the grant of exclusive rights to authors for a limited time is a means to that end."(59) Because the goal of copyright law is the continued advancement of knowledge, the groyright Act must be tailored in the way that will best promote innovation in the fields it regulates. The issue is therefore whether the inadvertent protection of a program's ideas will unduly burden the advancement of innovation in the software industry. The answer is quite clearly yes.
Furthermore, unlike all other copyrighted works, computer software can be concurrently protected by trade secret law(62) because the inner-working of a computer program remains hidden even after its distribution.(63) This form of double protection is facilitated by lenient copyright deposit procedures, which allow authors to comply with copyright regulations while keeping the contents of their programs secret; although authors are generally required to deposit a copy of their entire work with the Copyright Office,(64) software manufacturers need only deposit the first and last twenty-five pages of their program--in unreadable object code.(65) Trade secret protection also allows manufacturers to license their software longer after copyright protection ends, because the trade secret protection will last until the secret becomes public knowledge.(66) Software thus enjoys protection significantly greater than all other copyrighted works.
Although computer software is protected by copyright, most technology is protected under patent law. In order to obtain a patent, the inventor must make a complete public disclosure of her work,(67) describing and illustrating her invention in great detail.(68) The public has free access to this information, and may use any of the ideas underlying the invention, as long as the invention itself is not appropriated in any way.(69) This system is in clear contrast to the protection currently provided software, under which the ideas cannot be examined, and thus cannot be taken.
Furthermore, software enjoys all of the benefits that copyrighted works generally enjoy over patented works: longer duration,(70) low cost of obtaining protection,(71) and lower standards of originality.(72) Patent protection, unlike copyright protection, also does not offer the inventor an exclusive right to prepare derivative works--she receives protection for her invention alone.(73) Thus, while the inventor retains a limited monopoly over the use of her invention,(74) the technological advances which she made are distributed freely to the public.
Computer programs also enjoy more protection than technology protected solely by trade secret law. Trade secrecy is a common-law doctrine which protects against disclosure of certain kinds of information where the value of the piece of information stems directly from its secrecy.(75) Although the ideas behind a trade secret are not disseminated, reverse engineering is explicitly permitted to allow the discovery of any trade secret.(76) While computer software is afforded all of the benefits of trade secret protection, it does not suffer the main liability of trade secret law--software cannot be reverse engineered, since doing so would violate the program's copyright.
Innovation may be encouraged through the use of two diametrically opposed methods: (1) by freely disseminating information, allowing people to build upon the advancements of others; and (2) by providing incentives for inventors to perform the research necessary for such advancements. When protecting intellectual property, Congress must very carefully balance these two methods in order to best foster innovation in the industry.(84) The above comparisons with other protection schemes illustrate that software protection goes far beyond any balance previously drawn by Congress in the protection of intellectual property. Such protection may stifle innovation, forcing programmers to independently develop basic programming advances that should be freely disseminated.
Overprotecting computer programs is especially dangerous, because software, although classified as a literary work, is a technology.(85) "[P]rograms remain the technology for using computers. They are not designed to communicate information, thought, or feeling to human beings ...."(86) Programs are written to control computers--every single line of a computer program is present for a utilitarian reason.(87) The protection of such technology must be drawn carefully because copyright law is not designed to protect utilitarian works, and as a general policy leaves such works unprotected.(88) This exclusion of utilitarian works from copyright reflects the particular importance of wide dissemination of technological advancements to the growth of innovation. When drawing a balance for software protection, Congress must be particularly careful to address software as a technology. While overprotecting a novella will likely have little effect upon the field of literature as a whole, overprotecting a crucial advancement in technology could seriously hamper future innovation in the industry.
The inadvertent protection of ideas under copyright may suggest that reverse engineering should be permitted in all instances. There is, however, one case in which reverse engineering is particularly justified--making a new program compatible with existing copyrighted software. As a general notion, compatibility refers to a product's ability to work together easily with another product. As an example of such compatibility, consider a word processing program (WriteIt), and an application which creates graphs (GraphIt). Although each software package may be useful as a self-contained program, the two applications become significantly more productive if made compatible with each other. A user might take figures from WriteIt and send them directly to GraphIt to be automatically graphed. Similarly, a graph created using GraphIt might be sent to WriteIt, where it could be inserted automatically into a research report or a letter. Such compatibility, sometimes referred to as interoperability, would make both WriteIt and GraphIt more useful (and hence more valuable) without diminishing the market for either program.
The compatibility illustrated in this example is often difficult to achieve, even with the mutual cooperation of the program's authors. At a minimum, a programmer must have a complete specification of the other program's "interface"--a precise description of how the program receives, stores and/or outputs information--in order to make a compatible program.(92) This information, however, is virtually impossible to determine from the thousands of zeros and ones which comprise the program's object code, the format in which software is generally sold. In most cases, the programmer must decompile the software, changing the object code into source code that humans can understand, and then extracting the interface from source code.
Because reverse engineering(93) is often required to achieve interoperability, it is clear that making compatible programs can only be done at the expense of certain copyright protection.(94) The resolution of this dilemma can only lie with an examination of the fundamental goal of copyright--the advancement of progress and innovation.(95) Is current copyright law incorrectly balanced, impeding progress by restricting development of useful compatible software? Would a law allowing reverse engineering to achieve interoperability restrict the progress of computer science by removing incentives to invent? To answer these questions, one must fully examine compatibility, its costs and benefits, and its subsequent effect upon innovation in the software industry.
Having carefully weighed the costs and benefits of compatibility, the question remains: on which side does the balance tip? From the viewpoint of the user, compatibility clearly offers great rewards by making programs easier to use, providing greater productivity, and offering greater networking capabilities.(113) However, the proper analysis must be made in light of the single goal of copyright--the progress of innovation. Simply put, the issue is whether compatibility will increase or decrease innovation in the computer software industry. This Section analyzes the net effect of standardization, and concludes that the benefits of compatibility far outweigh the costs in the computer industry. Furthermore, the small costs of standardization are likely unavoidable, due to the natural tendency to develop de facto standards. For these reasons, compatibility is both desirable and necessary in the software industry.
Thus, compatibility encourages one type of innovation and discourages another. Which form of innovation is more prevalent in the computer industry? The answer is unmistakably clear--cumulative innovation. Indeed, the rapid early advances in computer science result largely from the willingness of early programmers to completely share all new ideas, developments, and software.(116) Software provides a classic example of technological advancement through incremental developments.
It is worth noting that, to the extent that standardization inhibits revolutionary innovation, this negative effect often will be present whether or not third parties are permitted to reverse engineer in order to achieve compatibility. In the software industry, a field characterized by large network externalities, a popular product may quickly gain a de facto monopoly over the market.(126) This process of "bandwagon standardization," whereby users follow a particular standard precisely because they believe others will follow as well,(127) generally takes place without any formal agreement or discussion. These standards are arbitrary and involuntary in the sense that no single person or organization actually advocates designating the product as the industry standard.(128) Instead, they are a reflection of the consumers' desire to buy what everyone else is buying, and their dominance will occur whether compatibility is encouraged or not.
IV. THE RISKS OF ALLOWING REVERSE ENGINEERING: WILL THE PROBLEM OF PIRACY OFFSET THE BENEFITS OF COMPATIBILITY?
While encouraging compatibility in the software industry will have profoundly positive effects upon innovation, such action can only take place at the expense of a certain amount of copyright protection. In order to determine if copyright law should accommodate compatibility as a goal (by allowing reverse engineering for that purpose), one must carefully examine the negative effects that a decrease in the legal protection of software may produce.
Because of the unfair advantages that piracy entails, and the subsequent effects on innovation, scholars, programmers and legislators are united in their belief that piracy should be banned.(136) Will allowing reverse engineering for the purposes of compatibility suddenly make piracy legal? The answer depends in part on the particular definition of piracy adopted. According to the definition used above--the unauthorized, exact duplication of a product--decompilation will not encourage piracy at all. Pirates do not need to reverse engineer in order to copy; the exact copying of computer programs is a mindless and mechanical task.(137) Allowing reverse engineering would encourage piracy no more than close analysis of literature would encourage unauthorized photocopying.
Copyright law should not, by simply applying the label of "piracy," treat a third-party's creation of a derivative computer program the same as the mechanical duplication normally associated with piracy.(144) Third-party developers, unlike pirates, generally cannot undercut the prices of their competition because the independent development of a compatible or similar program is quite expensive. In addition to the costs of reverse engineering, the third-party developer must undertake the major part of the development herself.(145) The creator of compatible software also cannot make a quick entrance into the market, because the processes of reverse engineering and subsequent development are very time consuming.(146) Therefore, the unfair conditions which create the need for a total ban on piracy(147) are not present in the actions of many third-party developers.
Admittedly, the third-party development described above may represent a "best case" scenario. There will certainly be cases in which third-party developers, under the guise of compatibility, make no more than cosmetic changes to a pre-existing program.(148) The possibility of such an occurrence, however, calls for a method of separating the good development activity from the bad, rather than an indiscriminate prohibition on all activity. The solution proposed in this Comment works within the protection scheme of copyright, providing a "compatibility exemption" for reverse engineering activities that meet certain criteria.
The classification of reverse engineering as a fair use makes sense: although decompiling software involves unauthorized copying, it should be allowed in order to achieve compatibility because of its positive effect upon innovation.
Nonetheless, it is clear that most reverse engineering fails each of the "four factors" which Congress has established to test for fair use.
Indeed, no court has ever held any act of decompilation to be a fair use.(151) The unavailability of the fair use exemption is largely due to the heavy emphasis that the fair use doctrine places on the financial reward of the original author. A use qualifying for this exemption must not only be socially useful, but must also avoid interfering with the author's ability to profit from her work. Reverse engineering, although a net benefit to society, clearly does not fall into this category--the creation of compatible or competing software will obviously affect the author's ability to capitalize on her work.
The heavy emphasis that fair use analysis places upon non-profit, non-commercial use precludes its use as a solution to the reverse engineering problem.(152) The need therefore exists for a separate "compatibility exemption" that, instead of distinguishing between non-profit and commercial uses, will distinguish between legitimate software development and unwanted piracy. Legitimate development would be determined with respect to the fundamental goal of copyright--the growth of innovation in the software industry. In developing this exemption, the framework of the current test of fair use is a good starting point. Each of the factors, however, should be analyzed with the goal of distinguishing piracy from legitimate development efforts.
The first three factors for determining fair use--the purpose and character of the use, the nature of the copyrighted work, and the amount and substantiality of the portion used--are essential in determining whether a given decompilation deserves exemption. The compatibility exemption cannot, however, include the last factor--the effect on the original program's market or value. The consideration of this factor would disqualify all reverse engineering from the exemption, because all compatible software will have some detrimental effect upon the original author's ability to profit from her work, or at least upon the author's ability to market derivative works. The result would be a nullification of the entire exemption. The compatibility exemption therefore uses three factors in its determination of which uses should be permitted. This portion of the Comment analyzes each of these factors and specifically applies them to situations in which a program is reverse engineered for the purpose of achieving compatibility.
In traditional fair use analysis, the chief issue in considering the purpose and character of the use was whether or not it was commercial. It is widely acknowledged that most reverse engineers intend to create and market a new product.(153) As noted above, however, one must not ask which instances of reverse engineering are acceptable to the first author, but rather which instances will fulfill the copyright law's goal of increasing innovation. To this end, the relevant inquiry concerns the nature of the compatibility sought. Many of the legal problems of compatible software stem from the misconceived notion that there is only one form of compatibility. In fact, there are a number of ways in which a program may be compatible with another, and an understanding of these variations provides a excellent framework for determining when compatibility is desirable.
Software is "vertically compatible" when it does not perform the same function as an underlying program, but instead connects to it in some way. Thus, two programs are vertically compatible when the output of one may be sent to the input of the other. Application programs provide examples of this form of compatibility, since sending information from one program to another greatly increases a user's productivity.(154) Vertical compatibility is also present where one program is able to "run" the other, or where one program can "ask" another program to perform a predetermined function. The operating system and application programs of Apple's Macintosh computer exemplify this point. The application program generally does not draw a rectangle, check to see if the mouse was moved, or perform many other functions by itself. Instead, the application will "ask"(155) the operating system to perform the desired function and return to the application when it is finished. This form of compatibility is essential because an application program simply will not work if it is not compatible with the computer's operating system.
When weighing the nature of the copyrighted computer program, one should not consider, as is the case in traditional fair use analysis, whether or not the program is published. The source code of a program remains "unpublished" long after the program's wide-spread sale to the public, since software can perform its utilitarian function while in its unreadable object code format.(164) The fierce protection of unpublished works stems from the strong desire to allow the author to control the first publication of her work(165)--a policy which is satisfied in the case of computer software.
The inquiry under this factor should not concern whether the original program has been published, but should instead ask to what extent banning the decompilation of the original program would have a detrimental effect upon innovation. If the copyrighted computer program has become a de facto standard, then reverse engineering must be allowed in order to prevent a single company from practically excluding all further innovative software from the market.(166) The existence of a de facto standard is admittedly an uncertain and fact-specific determination. Most cases, however, will likely fall far to one side of the blurry dividing line, simply because developers will reap the greatest benefits by making their programs compatible with those most popular in the industry.
When assessing the nature of the copyrighted program, the specific "level" of the software--where it fits between the hierarchy from hardware to user--is also an important consideration. To understand the concept of a program's "level," one must ask why software is useful at all, given the fact that a customized piece of hardware can implement any task that a piece of software can perform.(167) Computer programs are useful because they "make it possible for one machine--a computer--to be many machines. Programs, in effect, tell the computer what kind of machine to be."(168) This function is not performed by one single program, but is instead performed by a hierarchy of programs which, when layered upon each other, successively narrow the computer's task to a specific function.(169) As a result, every computer program must be compatible with the "layer of software" beneath it in order to work.
The "level" of a program within the software hierarchy is therefore important, because allowing a de facto monopoly over a program near the bottom of this hierarchy (such as the microcode(170) or an operating system(171)) could stifle development and innovation of "higher level" software on the computer. The computer program Microsoft Windows 3.0 exemplifies this point; this operating system for IBM computers is quickly becoming a standard.(172) If Microsoft were to withhold the description of the Windows interface from third-party developers, it could control all future development of all application programs for that particular market.(173) The lower the "level" of the software, the more likely its decompilation should be an exempted use.
Thus, when considering the nature of the copyrighted work, one should consider the characteristics of the program that may have an inordinately negative effect upon innovation in the industry. These include, but are not limited to, the level of the copyrighted program and the status of the program as a de facto standard.
The third and final factor addresses the material actually taken from the copyrighted work. Fair use analysis considers "the amount and substantiality of the portion used in relation to the copyrighted work as a whole."(174) This test, however, incorrectly focuses on simply preserving the author's monopoly--exempting only the use of small and inconsequential fragments of the copyrighted program that would not be harmful to the inventor's financial reward. The goal of this test should instead be to separate the desirable instances of decompilation from the undesirable ones. To this end, the proper consideration should be the amount and substantiality of the portion used in relation to the compatible work as a whole. Such a test would properly focus upon the amount of originality and innovation embodied in the derivative work, permitting the development of new and innovative products while preventing the proliferation of unoriginal "knock-off" programs.
(3) the amount and substantiality of the portion of the copyrighted computer program used, in relation to the compatible program as a whole. The terms of this section shall not apply if the information necessary to achieve compatibility has been made available by the author of the copyrighted work.
This compatibility exemption would efficiently distinguish between desirable and undesirable development of compatible software. By explicitly recognizing the importance of compatibility, it would spur the cumulative innovation that is so essential to the software industry. In addition, the compatibility exemption will inject predictability into an otherwise uncertain field. Although the exemption is by no means a bright-line test, it clearly exempts the development of vertically compatible works and the legitimate development of innovative horizontally compatible works. Moreover, it gives weight to the presence of a de facto standard in the industry and prevents manufacturers from tying up important "lower level" technology that will stifle innovation. Finally, it avoids much of the uncertainty brought to copyright law by the "substantial similarity" and "idea-expression" tests, which paralyze development in the software industry.
The development of the computer software industry has been charaterized by cumulative innovation, a process whereby developers study existing products, make improvements, and subsequently develop competing products. The production of compatible software is an integral part of such development because it allows innovators to improve upon already successful works and facilitates entrance into markets dominated by de facto standards. The decision to protect software under copyright law, however, has jeopardized much of this innovation by eliminating developers' ability to study existing software through decompilation. Although the case law in this area is not in any way conclusive, there is a legitimate possibility that the strong protection currently afforded to computer software will eventually stifle development in the industry.
The current overprotection of software could largely be alleviated by permitting the decompilation of programs, thus allowing third-party developers to extract the ideas and create compatible software. The chief stumbling block in the efforts to enact such reform has been the specter of piracy, in which third parties mindlessly copy existing software without incurring the burden of development costs, or contributing any thought, analysis, or innovation to the industry. Although tests for copyright infringement are designed to prevent such piracy, in reality, these tests have been extremely uncertain and unpredictable. As a result, the industry has instead focused on the technical infringements that occur when a program is decompiled, eliminating all legitimate third party development in the process. A total prohibition on reverse engineering, however, is an extremely costly solution to the problem of piracy.
The compatibility exemption described in this Comment will properly balance the rights of original authors and subsequent third party authors, with the twin goals of preventing piracy and encouraging innovation in the software industry. This exemption distinguishes between the legitimate cumulative development that is so vital to the industry, and the piracy which continually threatens to destroy it. The compatibility exemption allows desirable reverse engineering efforts and offers a degree of predictability that is sorely needed in this area of the law. Perhaps most importantly, the emphasis of the law will finally center on encouraging the development of innovative new software--a goal which serves the ultimate purpose of copyright law.
(3) Although users can read the output of programs, the actual instructions that the computer executes are generally stored on a disk as a long series of zeros and ones. This format is called machine code or object code. See infra notes 5-9 and accompanying text.
(4) Reverse engineering is the process of taking a finished product and working backwards in order to discover how it works. See infra notes 47-49 and accompanying text.
(5) 17 U.S.C. section 101 (1988).
(6) See RAYMOND T. NIMMER, THE LAW OF COMPUTER TECHNOLOGY Paragraph 1.03 (1985). For the most part, object code is unreadable by humans. Some "hard-core" programmers will insist that machine code can be understood with considerable patience and skill. Nonetheless, this Comment will assume that such an attempt is prohibitively time-consuming and difficult and that object code is generally unreadable.
(7) See Dennis S. Karjala, Copyright, Computer Software, and the New Protectionism, 28 JURIMETRICS J. 33, 37 (1987).
(8) Some languages, such as assembly language, are symbolically very close to the machine language which operates the computer. Others, such as BASIC, Pascal, C and FORTRAN, bear more than a faint resemblance to English. See Christopher M. Mislow, Computer Microcode: Testing the Limits of Software Copyrightability, 65 B.U.L. REV. 733, 743-44 (1985).
(9) This translation is itself performed by programs, known as compilers, which will automatically convert each higher-level instruction into the appropriate series of machine language commands. A single BASIC instruction may require dozens of lines of object code to achieve the same result. See, e.g., NIMMER, supra note 6, at Paragraph 1.03.
(10) See Pamela Samuelson, CONTU Revisited: The Case Against Copyright Protection for Computer Programs in Machine-Readable Form, 1984 DUKE L.J. 663, 680.
(11) Examples of applications include word-processing programs, spreadsheets, painting programs, databases and checkbook managers. Application programs, unlike the other software in the computer, are generally sold separately from the computer itself. See, e.g., Robert Garretson, What's Hot, COMPUTERWORLD, Jan. 13, 1992, at 66 (describing new applications available for the Microsoft Windows operating system).
(12) This collection of programs, often referred to as system software, performs many of the mundane tasks required by applications, allowing programmers to write their applications at a higher level of abstraction. For example, the system software may contain a complex program, called SQRT, which will calculate the square root of a number. Programmers may then simply have their program "call" SQRT whenever a square root is required, instead of writing the code themselves. See TRACY KIDDER, THE SOUL OF A NEW MACHINE 42 (1981); Karjala, supra note 7, at 37.
(13) See Jorge Contreras et al., NEC v. Intel: Breaking New Ground in the Law of Copyright, 3 HARV. J. L. & TECH. 209, 209 (1990); Karjala, supra note 7, at 36. Unlike application programs, microcode generally resides permanently inside the computer. See Contreras et al., supra, at 210. It consists of a series of programs, each performing a specific machine language instruction. Each line of a microcode program is generally a string of zeros and ones, which will be sent as high or low voltages to the digital circuits of the computer. See id. "A microcode consists of a series of instructions that tell a microprocessor which of its thousands of transistors to actuate in order to perform the tasks directed by the macroinstruction set." NEC Corp. v. Intel Corp., 10 U.S.P.Q.2d (BNA) 1177, 1178 (N.D. Cal. 1989).
(14) For example, two programs may be compatible if they perform the exact same tasks in the same way, or if they both can access data that is stored in a particular format. Compatibility might refer to the ability of two programs to send information to each other, or to one program's ability to run another program. See infra notes 153-163 and accompanying text, for the classification of these concepts into "vertical" and "horizontal" compatibility.
(15) For example, consider a database which contains names and addresses, and a word processing program which prints letters containing these names and addresses. If the two programs are to work together, both must store and retrieve the information in the same order (for instance, first name, last name, street, city, state, zip code). The term "interface" may also refer to the way in which information is entered by or conveyed to the user--this is generally called a "user interface."
(16) Literary works are statutorily defined as "works, other than audiovisual works, expressed in words, numbers, or other verbal or numerical symbols or indicia, regardless of the nature of the material objects, such as books, periodicals, manuscripts, phonorecords, film, tapes, disks, or cards, in which they are embodied." 17 U.S.C. section 101 (1988).
(17) See NATIONAL COMM'N ON NEW TECHNOLOGICAL USES OF COPYRIGHTED WORKS, FINAL REPORT (1978) [hereinafter CONTU REPORT].
There is still fierce academic debate over the appropriateness of copyright as a protection scheme for computer programs. There is considerable belief that copyright law is simply inappropriate as a protection scheme for software, due to its policy against protecting utilitarian works, see infra note 88, and its inexperience with the protection of technology. Indeed, many of the problems in today's computer law are an inherent result of these shortcomings. See, e.g., G. Gervaise Davis, III, Reaching the Limits of Copyright: Protecting Programming Languages, Macros, Formats and Computer Hardware Under the Copyright Laws, in 10TH ANNUAL COMPUTER LAW INSTITUTE, at 77, 79 (PLI Patents, Copyrights, Trademarks & Literary Prop. Course Handbook Series No. 259, 1988) [hereinafter PLI HANDBOOK] ("To a large degree [the decision to protect software under copyright] predestined today's legal and public policy dilemmas...."); Karen Hooten, Is Copyright Right?, COMPUTER LANGUAGE, Mar. 1991, at 99, 102 ("The fundamental fault behind the legal confusion is that copyright law has little experience with technology.").
This Comment focuses upon one flaw in copyright protection for software, namely the illegality of reverse engineering; the larger issue of copyright's appropriateness is beyond the scope of this Comment. For criticism of CONTU's decision to employ copyright protection for software, see, e.g., Ronald Abramson, Why Lotus-Paperback Uses the Wrong Test and What the New Software Protection Legislation Should Look Like, COMPUTER L., Aug. 1990, at 6; Samuelson, supra note 10, at 703-05; Pamela Samuelson, Creating a New Kind of Intellectual Property: Applying the Lessons of the Chip Law to Computer Programs, 70 MINN. L. REV. 471, 475 (1985).
(18) See, e.g., Whelan Assoc. v. Jaslow Dental Lab., Inc., 797 F.2d 1222 (3d Cir. 1986) (finding infringement of an application program which efficiently organized a dental laboratory), cert. denied, 479 U.S. 1031 (1987); Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983) (protecting the operating system of the Apple II computer), cert. dismissed, 464 U.S. 1033 (1984); NEC Corp. v. Intel Corp., 645 F. Supp. 590 (N.D. Cal. 1986) (finding the microcode for Intel's microprocessor copyrightable).
(19) See Franklin Computer, 714 F.2d at 1249.
(20) See id. at 1249; Williams Electronics, Inc. v. Artic Int'l, Inc., 685 F.2d 870, 876-77 (3d Cir. 1982).
(21) In fact, the ease with which programs may be copied was the primary motivation for CONTU's decision. See NIMMER, supra note 6, paragraph 1.03; Raymond T. Nimmer & Patricia A. Krauthaus, Copyright and Software Technology Infringement: Defining Third Party Development Rights, 62 IND. L.J. 13, 21 (1987).
(22) Unlike patent protection, which requires a costly, time-consuming and lengthy application, copyright protection is automatically given to a work as soon as it is "fixed in any tangible medium of expression ... either directly or with the aid of a machine or device." 17 U.S.C. section 102(a) (1988). Thus, a program is protected by copyright merely by saving it on a disk.
(23) Copyright protection generally extends fifty years beyond the death of the author. See 17 U.S.C. section 302(a) (1988).
(24) Nimmer & Krauthaus, supra note 21, at 21; see also 17 U.S.C. section 106(1) (1988); NIMMER, supra note 6, paragraph 1.06.
(25) 17 U.S.C. section 102(b) (1988).
(26) This concept is often called the "merger doctrine," because the idea is said to have merged with its expression. This doctrine exists so that an author cannot gain protection for a process or system simply by copyrighting all of its possible forms of expression.
The description of the art in a book, though entitled to the benefit of copyright, lays no foundation for an exclusive claim to the art itself. The object of the one is explanation; the object of the other is use. The former may be secured by copyright. The latter can only be secured, if it can be secured at all, by letters-patent. Baker v. Selden, 101 U.S. 99, 105 (1880). For an example of the merger doctrine as applied to software, see infra note 40 and accompanying text.
a) Mix beaten eggs, flour, milk and sugar. Then bake.
b) Beat the eggs, and then add the flour, milk and sugar. Mix briskly for 3 minutes. Then bake. The idea of the first recipe may simply be "the baking of cookies," in which case everything else (including the way the cookies are made) is expression. If this is the case, then the second recipe is an infringement, since its sequence and organization is substantially similar to the first recipe. On the other hand, the idea may be the particular method or process for baking the cookies, in which case the expression is simply the way in which the author describes his or her process in words. Under this definition, the second recipe is not an infringement.
(28) 797 F.2d 1222 (3d Cir. 1986), cert. denied, 479 U.S. 1031 (1987).
(29) Id. at 1236 (emphasis omitted).
(30) Id. at 1248; see also SAS Inst., Inc. v. S & H Computer Sys., Inc., 605 F. Supp. 816 (M.D. Tenn. 1985); Stephen J. Davidson, Reverse Engineering and the Development of Compatible, and Competitive Products Under United States Law, in PLI HANDBOOK, supra note 17, at 407, 429 (describing SAS Institute as holding that "copying the organizational and structural details of a program constituted infringement where the resulting program was essentially a translation of the original work"). Whelan relied upon SAS Institute for the principle that a computer program's copyright could extend beyond its literal elements to its structure and organization. See Whelan, 797 F.2d at 1239.
(31) 807 F.2d 1256 (5th Cir.), cert. denied, 484 U.S. 821 (1987).
(32) See id. at 1262.
(33) 20 U.S.P.Q.2d (BNA) 1641 (E.D.N.Y. 1991).
(35) See Karjala, supra note 7, at 79-80.
(36) See supra notes 14-15 and accompanying text.
(37) See Synercom Technology, Inc. v. University Computing Co., 462 F. Supp. 1003 (N.D. Tex. 1978), (holding that the input format of a computer program was an unprotected idea). Analogizing the program's input format to the figure-H gear-shift pattern of a car, the Synercom court noted that "the pattern ... may be expressed in several different ways ... [b]ut the copyright protects copying of the particular expressions ... and does not prohibit another manufacturer from marketing a car using the same pattern." Id. at 1013. This decision also shows an implicit acceptance of compatibility--"[i]n Synercom, the particular input format was not the only method available for entering data into a structural analysis program. The defendants elected to seek 'compatibility' with Synercom since it was a market leader." Nimmer & Krauthaus, supra note 21, at 45.
(38) See Manufacturers Technologies v. CAMS, Inc. 706 F. Supp. 984 (D. Conn. 1989); Pearl Sys., Inc. v. Competition Elec., 8 U.S.P.Q.2d (BNA) 1520 (S.D. Fla. 1988); Digital Communications Assocs. v. Softklone Distributing Corp., 659 F. Supp. 449 (N.D. Ga. 1987); Broderbund Software, Inc. v. Unison World, Inc., 648 F. Supp. 1127 (N.D. Cal. 1986).
(39) 740 F. Supp. 37 (D. Mass. 1990).
(40) Examples of this merger include the rotated "L" screen display which is used in virtually every spreadsheet program on the market, and the use of the "+", "-", "*", and "/" symbols to represent addition, subtraction, multiplication and division. See id. at 66.
(41) A user interface comprises the way in which a user controls and interacts with the program. It includes, among other things, the organization of the screen, the method used to give instructions, and the way choices are presented to the user. The user interface is often called the "look and feel" of a program. It is undisputed that much thought and creativity goes into the development of a good user interface. See generally Bill Curtis, Engineering Computer "Look and Feel": User Interface Technology and Human Factors Engineering, 30 JURIMETRICS J. 51 (1989) (describing how user interfaces are developed).
[I]n making the determination of "copyrightability," the decisionmaker must focus upon alternatives that counsel may suggest, or the court may conceive, along the scale from the most generalized conception to the most particularized, and choose some formulation--some conception or definition of the idea--for the purpose of distinguishing between the "idea" and its expression. Lotus, 740 F. Supp. at 60.
(43) For criticism of this decision, see Abramson, supra note 17, at 6-8.
(44) See supra notes 6-7 and accompanying text; see also STEVEN LEVY, HACKERS: HEROES OF THE COMPUTER REVOLUTION 19 (1984) ("Staring at a long list of computer commands written as binary numbers--for example, 10011001100001--could make you into a babbling mental case in a matter of minutes.").
(45) See supra notes 28-30 and accompanying text.
(46) See Computer Assocs. Int'l v. Altai, 20 U.S.P.Q.2d (BNA) 1641 (E.D.N.Y. 1991). The Altai recognized the errors of the Whelan court, referring to its holding as "simplistic," id. at 1649, "inadequate and inaccurate," id. at 1650, and "fundamentally flawed," id. The court correctly recognized that between identifiable ideas (such as the purpose of a program) and indentifiable expression (such as the literal object code) there are a great many "levels of abstraction." Under this "abstractions test," one starts with the program's most identifiable expression (the actual text) and gradually moves towards its more general aspects. At some point in this series of abstractions, a level is reached where expression has been replaced by ideas. "This abstractions test would progress in order of 'increasing generality' from object code, to source code, to parameter lists, to services required, to general outline." Id. at 1651.
(47) Not surprisingly, the programs to accomplish this are known as decompilers or disassemblers. The process may often be done in several steps, changing the machine code first to assembly language, and then to a higher-level, more easily understood language. See Mislow, supra note 8, at 743 n.42.
(48) As an analogy consider a handbook, written in Japanese, which describes the intricacies of the Japanese phone system. Even after one translated the work to English, it would still be painstakingly difficult to fully understand the logic and design of the system.
(49) See LaST Frontier Conference Report on Copyright Protection of Computer Software, 30 JURIMETRICS J. 15, 24 (1989) [hereinafter LaST Frontier Conference Report] (noting that some courts have begun to take into account the common software industry practice of reverse engineering); Richard H. Stern, Determining Liability for Infringement of Mask Work Rights Under the Semiconductor Chip Protection Act, 70 MINN. L. REV. 271, 327 (1985) ("Semiconductor industry representatives testified that it is an established industry practice to make photographs of one another's chips in order to analyze them and design similar chips.").
(50) See Clifford G. Miller, The Proposal for an EC Council Directive on the Legal Protection of Computer Programs, 12 EUR. INTELL. PROP. REV. 347, 349 (1990) ("For a three-dimensional product, to reverse engineer it, it is a simple matter to buy as many examples as necessary to take apart, inspect, and test without copying anything.").
(2) that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful. 17 U.S.C. section 117 (1988) (emphasis added). See generally Robin Michael, Note, 17 U.S.C. section 117: Is the Amendment to the Copyright Act Adequate to Regulate the Computer Software Market?, 7 COMPUTER/L. J. 227, 239-43 (1986) (arguing that, as applied by courts, section 117 provides inadequate protection of software owners' rights). It is unclear whether loading a program into memory in order to decompile it is proper "utilization of the computer program" as envisioned by section 117. See infra note 57 (discussing Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988)).
Very often, the software manufacturer will include a "shrink-wrap license" with the software, forbidding all but normal use of the program and banning decompilation in particular. See infra note 61 and accompanying text. Thus, even if a particularly determined and skilled programmer attempted to read the object code of the program (rather than decompiling), the mere loading of the program into memory would not be exempted by section 117 and would therefore constitute an infringement.
(52) These copies will exist only inside the memory of the computer and generally will never be seen by humans. Nonetheless, the CONTU report clearly states that unauthorized copies existing in a computer's memory will constitute infringement. See CONTU REPORT, supra note 17, at 13.
(53) Copyright law gives authors an exclusive right to make any works based on their original copyrighted work. These are referred to as derivative works. Regardless of whether the source code is treated as an actual copy or as a derivative work, the decompiled software will constitute a copyright violation. See 17 U.S.C. section 106(1)-(2) (1988).
The US Government's response indicated that the US Copyright Act does not contain provisions explicitly dealing with reverse engineering or decompilation of computer programs. Under US law, copying or reproducing a computer program without permission of the program owner, the response concluded, is not permitted unless excused by the provisions of the fair use doctrine or as a back-up copy under section 117. The response further identified that there were no cases in which fair use had been applied to decompilation. Robert J. Hart, Interfaces, Interoperability and Maintenance, 13 EUR. INTELL. PROP. REV. 111, 113 (1991).
(55) See, e.g., Hart, supra note 54, at 114 (noting that technical infringement will occur whenever obtaining information from the program code); LaST Frontier Conference Report, supra note 49, at 24 (noting that "computer programs cannot be "read' [sic] without disassembling or decompilation, a process that may also involve making a copy of some or all of the code"); Chris Reed, Reverse Engineering Computer Programs without Infringing Copyright, 13 EUR. INTELL. PROP. REV. 47, 53 (1991) (concluding that the title of the author's own article is a contradiction in terms, both theoretically and practically).
(56) See, e.g., Whelan Assocs. v. Jaslow Dental Lab., Inc., 797 F.2d 1222, 1238 (3d Cir. 1986) (holding that copyright principles derived from other areas are applicable to computer programs and that the unauthorized copying of such programs is infringement), cert. denied, 479 U.S. 1031 (1987). Moreover, it seems increasingly unlikely that such a case will ever reach the Supreme Court, due to the incredible amount of money at stake in such cases. Because a complete loss can be so costly (often the future of an entire business is at stake), more and more important cases are settling. See, e.g., Dataline, DATA BASED ADVISOR, May 1991, available in LEXIS, Nexis Library, Currnt File (describing the eventual settlement between Lotus Development Corp. and Paperback Software International).
(57) See, e.g., Whelan, 797 F.2d at 1248 (finding infringement where program was reverse engineered to write a similar program for a different computer); SAS Inst., Inc. v. S & H Computer Sys., Inc., 605 F. Supp. 816, 833 (M.D. Tenn. 1985) (condemning reverse engineering of a statistical analysis program); Hubco Data Prods. Corp. v. Management Assistance Inc., 219 U.S.P.Q. (BNA) 450, 455-56 (D. Idaho 1983) (holding that reverse engineering to increase the power of plaintiff's program was infringement).
[A] genuine issue exists as to whether NEC's initial reverse engineering product, Rev. 0, is a prohibited copy. Yet Judge Gray did not address the issue of whether NEC's Rev. 0 infringed the Intel microcode. Instead, he focused solely on NEC's final product, Rev. 2. As a result, Judge Gray's explicit approval of reverse engineering techniques may itself tolerate infringement by the initial decompiled program (in this case, Rev. 0).
Contreras, supra note 13, at 217-18 (footnotes omitted).
The holding of Intel seems to recognize reverse engineering as a commonplace and valuable activity. Furthermore, it draws a useful distinction between the act of reverse engineering and use of the discovered knowledge in a subsequent work.
The mere fact that defendant's engineers dumped, flow charted, and analyzed plaintiff's code does not, in and of itself, establish pirating. As both parties' witnesses admitted, dumping and analyzing competitor's codes is a standard practice in the industry. Had Uniden contented itself with surveying the general outline of the EFJ program [rather than copying parts of the code itself]... a claim of infringement would not have arisen. Id. at 1501 n.17.
Finally, in Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988), Vault made a copy-protection program (PROLOK) which prevented the duplication of any program placed on a PROLOK diskette. See id. at 256-57. Quaid reverse engineered PROLOK in order to create a new program (RAMKEY) that would undo the effects of the copy protection, leaving the disks unprotected. The Fifth Circuit, in a decision remarkably favorable towards reverse engineering, held that the copying that occurred during the decompilation of PROLOK was exempted by section 117(1), see supra note 51, because the "the copy ... was 'created as an essential step in the utilization' of Vault's program." Vault, 847 F.2d at 261 (quoting 17 U.S.C. section 117(1) (1988)). The court noted that "[s]ection 117(1) contains no language to suggestthat the copy it permits must be employed for a use intended by the copyright owner." Id. Furthermore, the court struck down a Louisiana law permitting manufacturers, through "shrink-wrap licenses," see infra note 61 and accompanying text, to forbid any copying or modifying of their programs. See id. at 270. The holding on this issue was significant because shrink wrap licenses have long been a key weapon in manufacturers' efforts to prevent decompilation.
While the NEC, Uniden, and Vault decisions are encouraging, they unfortunately represent the minority position on the issue of reverse engineering. Unless the Supreme Court explicitly rules that reverse engineering is not an infringement, congressional action will be necessary for decompilation to become legal.
(58) See U.S. CONST. art. I, section 8, cl. 8. ("The Congress shall have Power ... To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries ....").
(59) REPORT OF THE REGISTER OF COPYRIGHTS ON THE GENERAL REVISION OF THE U.S. COPYRIGHT LAW, 87th Cong., 1st Sess. 5 (Comm. Print 1961). It is settled beyond question that the primary goal of copyright is not to reward authors, but is to promote the advancement of science and the arts. This principle was recently stated in Sony Corp. v. Universal City Studios, Inc., 464 U.S. 417 (1984), where the Supreme Court noted that "[t]he monopoly privileges that Congress may authorize are neither unlimited nor primarily designed to provide a special private benefit. Rather, the limited grant is a means by which an important public purpose may be achieved. It is intended to motivate the creative activity of authors and inventors ...." Id. at 429.
(60) See 17 U.S.C. section 102(b) (1988).
(61) A manufacturer is limited in the restrictions he may put upon the use of his work after it is sold. See 17 U.S.C. section 109(a), (c) (1988). Theerefore, most software "sales" are instead constructed as licenses.
Shrink-wrap licenses are licenses attached to the software package, typically visible through the clear plastic wrapping. A buyer generally "agrees" to adhere to the terms of the license upon the opening of the package. The terms of the license invariably contain a prohibition on copying, modifying, and decompiling the program. See supra note 57 (discussing Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988)), in which the court struck down the use of shrink-wrap licenses to forbid copying or modifying programs). For in-depth discussions of shrink-wrap licenses, and the ramifications of Vault, see Deborah Kemp, Limitations Upon the Software Producer's Rights: Vault Corp. v. Quaid Software Ltd., 16 RUTGERS COMPUTER & TECH. L.J. 85 (1990); Page M. Kaufman, Note, The Enforceability of State "Shrink-Wrap" License Statutes in Light of Vault Corp. v. Quaid Software, Ltd., 74 CORNELL L. REV. 222 (1988); D.J. Hale, Recent Development, Vault Corp. v. Quaid Software, Ltd.: Limits to Copyright Protection for Computer Programs, 64 TUL. L. REV. 270 (1989).
There is some question as to whether such contractual terms are a form of misuse." "The patent misuse doctrine was created to deny relief against patent infringement to a patentee 'if he has attempted illegally to extend the scope of his patent monopoly.'" Gerald Sobel, Recent Developments in Patent Law, in TECHNOLOGY LICENSING AND LITIGATION 1991, at 7, 89 (PLI Patents, Copyrights, Trademarks, and Literary Property Course Handbook Series No. 308, 1991) (quoting Dawson Chem. Co. v. Rohm & Haas Co., 448 U.S. 176, 180 (1980)). This doctrine has recently been applied to copyright law. See Lasercomb Am. Inc. v. Reynolds, 911 F.2d 970, 976 (4th Cir. 1990) (holding that the misuse doctrine applies to copyright as well as patent law); see also Note, Clarifying the Copyright Misuse Defense: The Role of Antitrust Standards and First Amendment Values, 104 HARV. L. REV. 1289, 1308 (1991) (advocating a two-step inquiry into First Amendment policy considerations before potential anticompetitive effects under the misuse doctrine); Jere M. Webb & Lawrence A. Locke, Recent Developments, Intellectual Property Misuses: Developments in the Misuse Doctrine, 4 HARV. J.L. & TECH. 257, 267 (1991) (advising caution to copyright owners, given the expansion of the misuse doctrine).
(62) See infra notes 75-76 and accompanying text.
(63) The Supreme Court has held that trade secret laws and federal intellectual property laws may coexist without preemption. See Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470, 492-93 (1974) (holding that patent law and trade secret law enjoy a peaceful coexistence).
(64) See 17 U.S.C. section 407(a) (1988).
(A) ... (1) The first and last 25 pages or equivalent units of the source code .... 37 C.F.R. section 202.20(c)(2)(vii) (1991).
This deposit is used mainly for identification purposes, as opposed to patent's purpose of the public dissemination of information. See Daniel T. Brooks, Reverse-Engineering Computer Software: Is It Fair Use or Plagiarism?, in 12TH ANNUAL COMPUTER LAW INSTITUTE 741, 798-800 (PLI Patents, Copyrights, Trademark & Literary Prop. Course Handbook Series No. 301, 1990). Deposit copies are difficult to find and generally may not be copied. See id. at 803. Furthermore, "the head of the reference facilities reportedly has adopted the practice of confiscating notes taken by users of the reference facility [if] they become 'too extensive' in his judgment. In the case of object code, which he can't read, the reportedly confiscates any notes." Id.
(66) Normally, the duration of a copyright licensing agreement can be no longer than the duration of the copyright. With trade secret protection, however, the license can be for an unlimited duration. Such licenses, however, may be held to be misuses if they do not distinguish between royalties for the trade secret and royalties for the copyright. See Boggild v. Kenner Prods, 776 F.2d 1315, 1321 (6th Cir. 1985); Pitney Bowes, Inc. v. Mestre, 701 F.2d 1365, 1373 (11th Cir.), cert. denied, 464 U.S. 893 (1983).
(67) This requirement is especially significant in the case of an inventor who is not granted the patent. Because her disclosure to the Patent Office is public, she cannot subsequently obtain trade secret protection for her invention. See Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470, 484 (1974); see also infra notes 75-76 and accompanying text.
(68) There are actually two requirements in this disclosure. First, there is an "enabling" requirement, under which the invention must be described in great enough detail so that the average person skilled in the art may recreate the invention. Second, there is a "best mode" requirement, whereby the inventor is required to disclose the invention in the best form currently known. See 35 U.S.C. section 112 (1988). See generally Sobel, supra note 61, at 13-25 (discussing both disclosure requirements).
(69) See Nimmer & Krauthaus, supra note 21, at 18.
(70) Compare 17 U.S.C. section 302(a) (1988) (stating that copyright protection extends fifty years beyond the life of the author) with 35 U.S.C. section 154 (stating that patent protection lasts seventeen years).
(71) See U.S.C. section 102(a) (1988) (extending copyright protection to original works of authorship as soon as they are "fixed in any tangible medium of expression").
(72) Compare Alfred Bell & Co. v. Catalda Fine Arts, Inc., 191 F.2d 99, 102 (2d Cir. 1951) (holding that copyright protection necessitates "[n]o large measure of novelty") with 35 U.S.C. sub section 102, 103 (1988) (prescribing that the subject of the patent must be novel and nonobvious).
(73) Compare 35 U.S.C. section 154 (1988) (prescribing contents and terms of patent) with 17 U.S.C. section 106(2) (1988) (granting copyright owner exclusive right to prepare or authorize the preparation of derivative works). See also O'Reilly v. Morse, 56 U.S. (15 How.) 61, 119 (1854) (holding that the inventor of the telegraph could not claim patent for all devices that used electric current to communicate over long distances; he could only patent the devices he had already invented).
(74) In the United States, patent protection lasts for seventeen years from the date when the patent issues and extends to the patentee's heirs and assigns. See 35 U.S.C. section 154 (1988).
(75) The Restatement of Torts states that "[a] trade secret may consist of any formula, pattern, device or compilation of information which is used in one's business, and which gives him an opportunity to obtain an advantage over competitors who do not know or use it." RESTATEMENT OF TORTS section 757 cmt. b (1939).
(ii) is the subject of efforts that are reasonable under the circumstances to maintain its secrecy. UNIF. TRADE SECRETS ACT section 1(4), 14 U.L.A. 438 (1990) [hereinafter UTSA].
Because a trade secret may be protected only as long as it is not disclosed, an invention can obviously not be protected by both patent and trade secret law. The disclosure to the patent office will be sufficient to eliminate trade secret protection.
2. Discovery by "reverse engineering", that is, by starting with the known product and working backward to find the method by which it was developed. The acquisition of the known product must, of course, also be by a fair and honest means, such as purchase of the item on the open market for reverse engineering to be lawful.... UNIF. TRADE SECRETS ACT section 1 cmt., 14 U.L.A. 438 (1990); see also SI Handling Sys., Inc. v. Heisley, 753 F.2d 1244, 1262 (3d Cir. 1985) ("It is clear that under Pennsylvania law [following the Restatement definition, plaintiff's technology] is not entitled to trade secret protection if it is susceptible to reverse engineering ...."); Secure Servs. Tech., Inc., 722 F. Supp. at 1361 (holding that development of a compatible facsimile machine through reverse engineering was legal where the original machine was protected by trade secret); Acuson Corp. v. Aloka Co., 257 Cal. Rptr. 368, 379-80 (Cal. Ct. App. 1989) (noting that reverse engineering is permitted and even encouraged under trade secret law).
(77) Pub. L. No. 98-620, 98 Stat. 3335 (1984) (codified as amended at 17 U.S.C. subsection 901-914 (1988). For an excellent analysis of the various aspects of SCPA, see Symposium, The Semiconductor Chip Protection Act of 1984 and Its Lessons, 70 Minn. L. Rev. 263 (1985). See also RICHARD H. STERN, SEMICONDUCTOR CHIP PROTECTION (1986) (providing an in-depth analysis of the SCPA).
(78) This type of protection is sometimes referred to as sui generis, defined as: "Of its own kind or class; i.e., the only one of its kind; peculiar." BLACK'S LAW DICTIONARY 1434 (6th ed. 1990).
(79) "A semiconductor chip is a fingernail-sized bit of silicon on which an extraordinary number of transistors have been constructed and connected, so that a chip may contain a million or more electronic elements. Most modern computers are comprised of semiconductor chips, among other elements." John A. Kidwell, Software and Semiconductors: Why Are We Confused?, 70 MINN. L. REV. 533, 540-41 (1985) (footnotes omitted).
(2) a person who performs the analysis or evaluation described in paragraph (1) to incorporate the results of such conduct in an original mask work which is made to be distributed. 17 U.S.C. section 906(a) (1988).
(81) The exact standard of originality is not precisely defined by the Act. The derivative work must show greater originality than the bare minimum needed for copyrighted works, but need not meet the strict "novelty" standard of patent law. See Leo J. Raskind, Reverse Engineering, Unfair Competition, and Fair Use, 70 MINN. L. REV. 385, 399-401 (1985) (analyzing legislative history in order to determine the meaning of "originality"); Stern, supra note 49, at 333-36 (discussing the meaning of "original" and "originality" in the Act).
(82) Congress appeared to rely heavily on the fact that reverse engineering was an established practice of the industry, and was responsible for much of the innovation which had occurred in the development of the field. See Raskind, supra note 81, at 385-86; Stern, supra note 49, at 327. This rationale, however, applies equally to the software industry, which also has grown incrementally through the study of prior works through reverse engineering. See infra notes 114-25 and accompanying text.
(83) The dividing line between hardware (such as semiconductor chips) and software is extremely fuzzy. "It is commonly recognized in the computer science community that a customized piece of hardware can be built to do any task that might otherwise be performed by running a program on a general purpose computer." Samuelson, supra note 17, at 509.
(84) See 17 U.S.C. section 102(b) (1988) (limiting the extent of copyright protection and prohibiting copyright protection for any "idea, procedure, process, system, method of operation, concept, principle, or discovery"); Baker v. Selden, 101 U.S. 99, 107 (1879) (holding that an author's work is not entitled to protection where the idea underlying it and its expression merge). Supporters of the ban against decompilation argue that, if reverse engineering is permitted, other developers will be able to take the most valuable aspects of the software. This, however, results from the fact that the ideas behind a program are often more valuable than the expression of those ideas. See Karjala, supra note 7, at 83 (criticizing the idea/expression distinction). Although this argument supports the need for a system other than copyright protection for software, it does not in any way justify a breakdown of the traditional idea-expression dichotomy.
(85) See, e.g., Nimmer & Krauthaus, supra note 21, at 20 ("Issues about software protection deal with a creative industry different from print, video or music media. Decisions about protecting software are connected to protecting machine processes and scientific or technological concepts.").
(86) Karjala, supra note 7, at 38.
(87) Although other programmers may want to learn by reading programs, the "human reading of a program is a distinctly secondary purpose, deeply subordinate to the primary purpose of causing the computer to perform the intended task." Id.
Such works shall include works of artistic craftsmanship insofar as their form but not their mechanical or utilitarian aspects are concerned; the design of a useful article, as defined in this section, shall be considered a pictorial, graphic, or sculptural work only if, and only to the extent that, such design incorporates pictorial, graphic, or sculptural features that can be identified separately from, and are capable of existing independently of, the utilitarian aspects of the article. 17 U.S.C. section 101 (1988); see also Mazer v. Stein, 347 U.S. 201, 218 (1954). For a wellreasoned argument that utilitarian software should not be copyrightable, see Duncan M. Davidson, Protecting Computer Software: A Comprehensive Analysis, 1983 ARIZ. ST. L.J. 611, 678-93 (dissent by Manny Pokotilow).
(89) See Karjala, supra note 7, at 39. For example, one programming concept may be faster, or may use memory more efficiently.
(90) For example, consider the field of three-dimensional graphics software. Restricting advancement in this field would not only affect the software industry, but also would affect the fields of molecular biology, genetics, and chemistry, which rely upon such programs to display complex molecular compounds and model chemical reactions.
(91) U.S. CONST. art. I, section 8, cl. 8.
(92) See Hart, supra note 54, at 111-12.
(93) See supra notes 50-57 and accompanying text (discussing why decompilation is technically a copyright infringement).
(94) Most courts have been quite unsympathetic to this dilemma, and have held that the need for compatibility does not justify copyright infringement. In Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983), the Third Circuit emphatically stated: "Franklin may wish to achieve total compatibility with independently developed application programs written for the Apple II, but that is a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and expressions have merged." Id. at 1253. In Lotus Dev. Corp. v. Paperback Software Int'l, 740 F. Supp. 37 (D. Mass. 1990), the court took an equally negative view of compatibility as an excuse for infringement: "[E]ven if VP-Planner otherwise would have been a commercial failure, and even if no other technological ways of achieving macro and menu compatibility existed, the desire to achieve "compatibility" or "standardization" cannot override the rights of authors to a limited monopoly in the expression embodied in their intellectual 'work.'" Id. at 69. These decisions indicate that a developer's goal of compatibility with another program should not factor at all into the issues of copyrightability and infringement.
There have, however, been a small minority of cases which are more sympathetic towards the developers of compatible software. In NEC Corp. v. Intel Corp., 10 U.S.P.Q.2d (BNA) 1177 (N.D. Cal. 1989), in which NEC had reverse engineered the microcode for Intel's 8086/88 chip and then independently created a similar set of compatible routines, the district court held that NEC's code was not an infringement because NEC was constrained by its goal of compatibility. The court held that, "[i]n determining an idea's range of expression, constraints are relevant factors to consider .... In this case, the expression of NEC's microcode was constrained by the use of omitted). A favorable view towards compatibility is also present in E.F. Johnson Co. v. Uniden Corp., 623 F. Supp. 1485 (D. Minn. 1985), in which the defendant disassembled the software in the plaintiff's radios and then created compatible radios. The court allowed the copyright of certain object code patterns that were required for compatibility with the plaintiff's radios, but found infringement in the duplication of code unnecessary for compatibility. See id. at 1502-03.
(95) See supra notes 58-59 and accompanying text.
(96) One obvious example is that of the telecommunications industry. Until 1984, the domestic telecommunications industry was standardized by AT&T, which would simply dictate its choice for a standard. Due to AT&T's virtual monopoly of the industry, the other "players" would follow this standard to retain compatibility. See Joseph Farrell, Standardization and Intellectual Property, LaST Frontier Conference on Copyright Protection of Computer Software, 30 JURIMETRICS J. 35, 39 (1989); see also STANLEY M. BESEN & LELAND L. JOHNSON, COMPATIBILITY STANDARDS, COMPETITION, AND INNOVATION IN THE BROADCASTING INDUSTRY (1986) (discussing standardization in the broadcasting industry); Stanley M. Besen & Garth Saloner, The Economics of Telecommunications Standards, in CHANGING THE RULES: TECHNOLOGICAL CHANGE, INTERNATIONAL COMPETITION, AND REGULATION IN COMMUNICATIONS (Robert W. Crandall & Kenneth Framm eds., 1989) (describing the benefist of standardization in the telecommunication industry).
(97) For example, the benefits of standardization are evident in the case of stereo components. When a consumer purchases a compact disc player, he generally assumes that it will connect to his amplifier without any technical innovation on his part. One would expect that the computer industry, especially that section which caters to non-expert users, would benefit similarly from such compatibility.
(98) Farrell, supra note 96, at 36.
(99) This name is derived through analogy to telecommunications, "where being 'on the network'--having a telephone--is more valuable the larger the network is." Id.
(100) Cf. FREIBERGER & SWAINE, supra note 1, at 279 (describing how good publicity and successful initial sales of the IBM PC resulted in third-party development and enormous sales).
(101) For a discussion of de facto standards, see infra notes 102, 124-29 and accompanying text.
(102) Such benefits are dramatically illustrated by the successes of Apple and IBM in popularizing their computer systems. Apple Computer owes much of the success of its Apple II computer to the machine's eight "expansion slots," which allowed third-party manufacturers to create attachments (such as clocks, extra memory boards, modems) which would plug into the machine, as well as its open policy towards third party software developers. See FREIBERGER & SWAINE, supra note 1, at 227 ("In fact, it would be hard to overestimate the contribution of third-party developers to Apple."); MORITZ, supra note 2, at 233. One of the best examples of the mutual benefits of compatibility is the success of VisiCalc, a program which would perform financial calculations on the Apple II.
Not only did VisiCalc sell, but it helped sell Apples. During its first year, VisiCalc was available only on an Apple disk, and it provided a compelling reason to buy an Apple. In fact, the Apple II and VisiCalc were an impressive symbiotic combination, and it's difficult to say which contributed more to the other. Together they did much to help legitimize both the hardware and the software industries. FREIBERGER & SWAINE, supra note 1, at 230.
Similar benefits accrued to IBM when it first introduced its IBM PC computer with a new operating system (MS-DOS). IBM's decision to encourage third-party development spurred a vast amount of compatible hardware and software. "In turn, the add-on products themselves spurred PC sales, since they increased the utility of the machine." Id. at 278. This continuous cycle "served to ratify the PC operating system. MS-DOS quickly became the standard operating system for 16-bit machines." Id. at 279.
(103) See Farrell, supra note 96, at 36.
(104) See, e.g., Michael A. Jacobs, Copyright and Compatibility, LaST Frontier Conference on Copyright Protection of Computer Software, 30 JURIMETRICS J. 91, 100 (1989) ("[T]he benefits that compatibility offers [include] the ability to introduce new products to the market, to innovate, without asking customers to sacrifice their existing investments in data, software and training."). One example of this effect is Borland's "Quattro," an innovative spreadsheet program for personal computers. At the time of its development and release, the spreadsheet market was dominated by Lotus 1-2-3. "Borland felt compatibility was necessary in order to introduce this product to the market; the company advertises that 'Quattro is 100% compatible with The Other Spreadsheet.' The Other Spreadsheet is, of course, Lotus 1-2-3." Id.
... [D]efendant's argument ignores the commercial success of Excel, an innovative spreadsheet that is not compatible with 1-2-3, either in its menu structure or in its macro command facility. Id. at 78.
This comparison with Excel is improper, however, because Excel is a spreadsheet program designed to run on the Apple Macintosh, while Lotus 1-2-3 is run primarily on IBM computers. When Excel was developed, there was not as great a need to make it compatible with Lotus 1-2-3, because Lotus 1-2-3 was not even available for the Macintosh at the time. See Christopher Lindquist, Lotus to Unleash Overdue Mac 1-2-3, COMPUTERWORLD, Dec. 16, 1991, at 8. Furthermore, virtually all Macintosh applications use an interface different from (and more advanced than) the interface of IBM PC applications. To the extent that Excel's interface is different from 1-2-3, it is most likely different out of a desire to be compatible with the standard interface of the Macintosh. See Microsoft Debuts Rival to "Jazz", PC WEEK, May 7, 1985, at 3 ("Excel's design used the common data and screen interfaces of the Macintosh to allow interchange of information from one full-featured program to another without the need for the compromises that are inherent in integrated packages such as Lotus 1-2-3.").
(105) See Farrell, supra note 96, at 37; Thomas M.S. Hemnes, Three Common Fallacies in the User Interface Copyright Debate, 6 COMPUTER L. & PRAC. 163, 167 (1990). See generally Paul A. David, Clio and the Economics of QWERTY, 75 AM. ECON. REV. 332 (1985).
(106) Although Dvorak originally patented his keyboard, he later dedicated it to the public domain in order to encourage its widespread use. Still, however, QWERTY survives today. See Hemnes, supra note 105, at 167 n.58.
(107) This risk is really nothing more than "the Prisoners' Dilemma," applicable to all areas of life where lack of communication and other transaction costs prevent efficient action. In the Prisoners' Dilemma, two criminals commit a crime and are later taken by the police for questioning. Each prisoner is privately told that if he "turns in" his partner, he will be set free. Although the most efficient outcome for the criminals would be for both to remain silent (allowing both to go free), each prisoner will fear being stranded by the other. Thus, the prisoners will likely turn each other in, resulting in jail time for both. See Leo Herzel & Leo Katz, The Prisoner's Dilemma, 24 L. SCH. REC. 8, 8-10 (1985).
(108) See Farrell, supra note 96, at 37. Professor Farrell draws an analogy to a Western movie, with cowboys riding their horses in the middle of the desert. Before going to sleep, to prevent the horses from running off, they simply tie the horses together. The horses will not all want to leave at the same time, and will not all want to go to the same place. When the cowboys wake in the morning, the horses are merely a few hundred feet away. See id; Joseph Farrell and Garth Saloner, Competition, Compatibility, and Standards: The Economics of Horses, Penguins, & Lemmings, in PRODUCT COMPATIBILITY AS A COMPETITIVE STRATEGY 1, 10 (H. Lands Gabel ed., 1987).
(109) One consultant has estimated that it costs one thousand dollars to train each user to learn a popular spreadsheet program. See Kathleen K. Wiegner & John Heins, Can Las Vegas Sue Atlantic City?, FORBES, Mar. 6, 1989, at 130, 132.
(110) Consider, for example, the case of a software company which decides that its products should henceforth be written in the computer language "C" rather than Pascal. Such a change could effectively bring the operation of the entire company to a halt.
Total software compatibility made it easy for customers to do what IBM wanted them to do, which was to buy several different kinds of 360 computers. A customer could buy a small one now and later on buy a bigger one, or vice versa, without having to re-create any software. Software compatibility strengthened IBM's already tight grip on its customers: they weren't likely to forsake IBM and take their business elsewhere when that meant assuming new expenses and problems with software. KIDDER, supra note 12, at 43.
(112) See Carmen Matutes & Pierre Regibeau, "Mix and Match": Product Compatibility Without Network Externalities, 19 RAND J. ECON. 221, 222 (1988). For example, users might build a specialized word processing system, separately purchasing a simple text editor, a complex program for advanced searching and replacing, and a program to produce large quantities of form letters. In such a case, the user chooses only the specific components that contain the features she wants.
(113) See supra notes 96-100 and accompanying text.
(114) See supra notes 102-04 and accompanying text.
(115) See supra notes 105-11 and accompanying text.
(116) For a detailed discussion of the importance of wide dissemination of information and incremental improvements to the success of the computer revolution, see LEVY, supra note 44.
(117) Hemnes, supra note 105, at 167.
(118) Lotus Dev. Corp. v. Paperback Software Int'l, 740 F. Supp. 37, 77 (D. Mass. 1990) (quoting a letter from Sir Isaac Newton to Robert Hooke (Feb. 5, 1675/1676)). Because of this statement, the principle of cumulative development is sometimes referred to as the OTSOG principle (On The Shoulders Of Giants). See id.
(119) Gregg Williams, A Threat to Future Software, BYTE, Jan. 1986, at 6.
(120) For early reviews of the Macintosh, see Thomas Neudecker, Apple's Macintosh, INFOWORLD, Mar. 26, 1984, at 82; Gregg Williams, The Apple Macintosh Computer, BYTE, Feb. 1984, at 30.
(121) See MORITZ, supra note 2, at 298-301.
(122) See id. at 300.
(124) Consider the field of application programs, such as word-processors. The authors of today's leading word-processing programs did not suddenly "invent" great programs. They created their products by incorporating the features of past market leaders, such as MicroPro's "WordStar," itself developed as an improvement to a program called "Electric Pencil." See FREIBERGER & SWAINE, supra note 1, at 152-53. In the field of spreadsheet programs, there is no question that the development of successful programs, such as Lotus 1-2-3, was based on previous advances made by software such as VisiCalc. "[Lotus] 1-2-3, like many electronic spreadsheet programs since, could thus be thought of as an evolutionary product that was built upon the shoulders of VisiCalc." Lotus Dev. Corp. v. Paperback Software Int'l, 740 F. Supp. 37, 66 (D. Mass. 1990).
The conferees agree that achieving compatibility between interface programs of these types--that is, programs that serve as hardware-to-software or a software-to-software interface--is a legitimate goal for software competitors.... [I]nfringement should not be found where functional compatibility cannot be achieved except through exact or nearly exact copying.
LaST Frontier Conference Report, supra note 49, at 22; see also, Farrell, supra note 96, at 47 (stating that interfaces should be unprotected so that other software developers are encouraged to achieve standardization); Hart, supra note 54, at 114 ("In the author's opinion, it is clearly necesary to provide an exception for obtaining interoperability information on program-to-program interfaces."); Hemnes, supra note 105, at 167 (arguing against protection of user interfaces so that compatible products may be developed); Hooten, supra note 17, at 102 ("Technological standards may be ... critical for the commercial success of software. Where would the computer industry be if a standard QWERTY user interface for keyboards did not exist?"); Jacobs, supra note 104, at 103-04 (arguing for a system that would allow development of compatible products); Karjala, supra note 7, at 58 (finding no unfair advantage in legitimate reverse engineering for the legitimate purpose of compatibility); Nimmer & Krauthaus, supra note 21, at 62 (arguing that compatible software and other derivative works should be permitted as long as the use of original work is selective and developmental); Alfred Z. Spector, Software, Interface, and Implementation, LaST Frontier Conference on Copyright Protection of Computer Software, 30 JURIMETRICS J. 79, 87 (1989) ("I believe it is a technological imperative for the law to encourage system designers to use standardized abstractions."); Richard H. Stern, Copyright Infringement by Add-On Software: Going Beyond Deconstruction of the Mona Lisa Moustache Paradigm and Not Taking Video Game Cases Too Seriously, 31 JURIMETRICS J. 205 (1991) (arguing that "add-on" programs--compatible software which modifies the function of a preexisting program--should be legal).
(126) See Karjala, supra note 7, at 44-48. "All it takes is widespread public acceptance of one particular manufacturer's product, for whatever reason. Once lock-in begins, it can become self-sustaining." Id. at 45-46.
(127) An excellent example can be found with the IBM PC computer. "IBM did not begin with a large market share, but because users and software-writers thought that IBM was likely to set a standard, its PC did indeed become a standard: a self-fulfilling expectation." Farrell, supra note 96, at 40. Many examples of market dominance exist in the field of applications software; for instance, Microsoft Excel holds 90% of the Macintosh spreadsheet market, see Robert Wiggins, Spreadsheet Skirmishes, MACUSER, Aug. 1991, at 29, and Lotus 1-2-3, controlled (in 1989) 70% of the spreadsheet market for IBM personal computers, see Richard A. Shaffer, Is Lotus a Buy?, FORBES, March 18, 1991, at 128.
(128) See Farrell, supra note 96, at 40.
(129) The importance of compatibility was recognized in legislation recently passed in the European Community, the result of years of battle over the proper scope of copyright protection for computer software in Europe. The debate was marked by fierce lobbying by special interest groups composed of the world's leading computer companies. The European Committee for Interoperable Systems (ECIS) was composed of 50 software and hardware manufacturers, such as Fujitsu, Unisys, NCR, and Amdahl. It sought to exclude interfaces from copyright protection and to allow reverse engineering of software, so that developers could develop compatible software. See Keith A. Styrcula, The Adequacy of Copyright Protection for Computer Software in the European Community 1992: A Critical Analysis of the EC's Draft Directive, 31 JURIMETRICS J. 329, 343 (1991). The Software Action Group for Europe (SAGE), a group vigorously opposed to allowing any form of reverse engineering, was composed of manufacturers such as IBM, Digital, Microsoft, Apple, and Lotus. See id; Nicholas Kounoupias, The European Commission Software Directive, WHICH COMPUTER?, June 1991, at 134, available in LEXIS, Nexis Library, Currnt File. By all accounts, the battles over reverse engineering and interoperability were the most fiercely fought. See Problems of the New EC Directive, FIN. TIMES, May 1991, available in LEXIS, Nexis Library, Currnt File. One observer noted that "[t]he directive has been lobbied ridiculously on the reverse engineering issue." Suzanne Perry, EC Software Directive Adopted, But Debate Goes On, REUTERS, May 16, 1991, available in LEXIS, Nexis Library, Currnt File.
- the decompilation is performed by the licensee or another person having the right to use a copy of the program, or a person authorized on their behalf; - the information necessary to achieve interoperability has not previously been published or made available to the person; and - the acts are confined to the parts of the original program which are necessary to achieve interoperability.
- to be used for purposes other than the achievement of interoperability. - to be given to others, except when necessary to achieve interoperability. - to be used for any act which would infringe the copyright of the original program, and in particular a program substantially similar in expression to the original. See Computer Software Protection Directive Adopted, Common Mkt. Rep. (CCH), at 1 (May 30, 1991) (describing the contents of the Directive). The Directive correctly recognizes the importance of compatibility as a stimulant to innovation and further recognizes the crucial role that reverse engineering must play in achieving such compatibility. It is essential that the United States follow the lead of the European Community, correcting the imbalance that currently exists in the protection of computer software.
(130) Nimmer & Krauthaus, supra note 21, at 15.
(131) See, e.g., Vault Corp. v. Quaid Software Ltd., 847 F.2d 255, 261 n.13 (5th Cir. 1988) ("In 1983 it was estimated that twenty to thirty percent of the computer software industry's revenues were siphoned off annually by piracy ...."); William M. Bulkeley, Software Makers Are Pursuing "Pirates" Around the Globe with Fleets of Lawyers, WALL ST. J., Dec. 13, 1990, at B1 ("The PC software industry calculates that it loses $3 billion a year to illegal copies in the U.S., $5.3 billion a year in Europe and several billion more in other markets.").
(132) See Nimmer & Krauthaus, supra note 21, at 21.
(134) See, e.g., Karjala, supra note 7, at 58 ("[T]here is essentially no lag time between buying a single copy of the desired original program and getting into competition with the original on a large scale."); Nimmer & Krauthaus, supra note 21, at 22 ("[T]he ease of copying creates a primary incentive for 'piracy' and .... reduces 'head start' advantages.").
(135) To be sure, users will able to obtain a pirated program at a lower price. However, to the extent that this is a benefit, it will be an extremely short-lived benefit. If writing software is no longer profitable, who will write the consumer's next program? Consider the statement of one computer scientist: "Some computer scientists think all software should be free so that we can easily borrow from each other. They argue that this will promote the greatest innovation. They have a point, but I believe there will be less motivation and funds to move the field forward." Spector, supra note 125, at 88.
(136) One commentator has remarked: "Making an exact copy of a program, without analysis or any attempt to understand and improve upon it, should clearly be, and clearly is, a copyright violation. On this point, at least, there is universal agreement." Karjala, supra note 7, at 58.
(137) See id. ("[I]t is not necessary to reverse engineer the product, or even to understand the ideas taken, in order to take them.").
(138) These elements, depending on the particular jurisdiction, may be protected as part of the expression of a program, as compared to its idea. For a discussion of the treatment of this issue in the Third and Fifth Circuits, see supra notes 25-35 and accompanying text.
(139) See 17 U.S.C. section 106(1), (2) (1988).
(140) See supra notes 50-57 and accompanying text.
(141) Peter Waters & Peter G. Leonard, The Lessons of Recent EC and US Developments for Protection of Computer Software under Australian Law, 13 EUR. INTELL. PROP. REV. 124, 129 (1991) (emphasis added); see also John M. Conley & Robert M. Bryan, A Unifying Theory for Litigation of Computer Software Copyright Cases, 63 N.C.L. REV. 563, 597 (1985) ("Substantial similarity, after all, is only circumstantial evidence of copying, to be used when no direct evidence is available."); Susan A. Dunn, Note, Defining the Scope of Copyright Protection for Computer Software, 38 STAN. L. REV. 497, 515-20 (1986) (discussing the use of course of development evidence to prove infringement as an alternative to substantial similarity).
(142) A bright-line test for substantial similarity may well be impossible, due both to the fact-specific nature of software infringement cases and to the courts' major difficulties with the idea/expression dichotomy in software. Courts have continually attempted to clarify substantial similarity and idea/expression. See, e.g., Whelan Assocs. v. Jaslow Dental Lab., Inc., 797 F.2d 1222, 1236, 1245 (3d Cir. 1986) (noting that "the line between idea and expression may be drawn with reference to the end sought to be achieved by the work in question" and that, when determining substantial similarity, "the court must make a qualitative, not quantitative, judgement about the character of the work as a whole and the importance of the substantially similar portions of the work"), cert. denied, 479 U.S. 1031 (1987); Lotus Dev. Corp. v. Paperback Software Int'l, 740 F. Supp. 37, 59 (D. Mass. 1990) ("If ... the expression of an idea has elements that go beyond all functional elements of the idea itself, and beyond the obvious, and if there are numerous other ways of expressing the noncopyrightable idea, then those elements of expression, if original and substantial, are copyrightable."). But the tests have been muddled, and academic response has not been glowing. See, e.g., Abramson, supra note 17, at 6 (criticizing the court in Lotus for treating computer software like any other traditional literary work); J. Dianne Brinson, Copyrighted Software: Separating the Protected Expression from Unprotected Ideas, A Starting Point, 29 B.C. L. REV. 803, 832 (1988) (criticizing the Whelan court for "confusing the program function with the unprotected idea"); Steven R. Englund, Note, Idea, Process, or Protected Expression?: Determining the Scope of Copyright Protection of the Structure of Computer Programs, 88 MICH. L. REV. 866, 908 (1990) (concluding that a program's structure must be protected under copyright law, "subject to the limitations imposed by the idea-expression and process-expression dichotomies and the merger doctrine"); Peter G. Spivack, Comment, Does Form Follow Function? The Idea/Expression Dichotomy in Copyright Protection of Computer Software, 35 UCLA L. REV. 723, 748 (1988) ("The Whelan court's rule for dividing idea and expression teeters precariously on the brink between the arbitrary and the ad hoc.") (footnote omitted).
(143) Waters & Leonard, supra note 141, at 129.
(144) "The original developer of innovative technology ... is likely to lable as 'piracy' any use not expressly authorized by her. Simply that individual creators would like more protection in a particular case ... does not show that we have been wrong all these years in denying more protection to nonpatented innovations." Karjala, supra note 7, at 78 n.161.
(145) See Jacobs, supra note 104, at 102. "It is generally agreed that testing a product and debugging it comprises about 50 percent of the development effort. Detailed design and coding is about 35 percent of the development effort. Functional design, the specification of the functions and the interfaces, represents 15 percent of the development effort." Id. Therefore, in a case where a third-party independently creates a compatible piece of software, he saves at most 15 percent of his development costs. There would not appear to be a "free rider" problem in such a case. See Karjala, supra note 7, at 58 ("[R]everse engineering ... provides the competitor in the usual case with little if any advantage in reduced development costs.").
(146) See, e.g., Nimmer & Krauthaus, supra note 21, at 22 ("If the second developer must adapt and invest resources to learn and apply the technology, the cost advantages are reduced; the activities require time. This retains commercial advantage for the original developer.").
(147) See supra notes 130-34 and accompanying text.
(148) See, e.g., Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1245 (3d Cir. 1983) (noting that the "variations that did exist were minor, consisting merely of such things as deletion of reference to Apple or its copyright notice"), cert. dismissed, 464 U.S. 1033 (1984).
(149) 17 U.S.C. section 107 (1988). For a very complete description of the fair use exemption in copyright law, see WILLIAM F. PATRY, THE FAIR USE PRIVILEGE IN COPYRIGHT LAW (1985).
(150) PATRY, supra note 149, at 401 (footnote omitted). Some might argue that the test has not been applied fairly to reverse engineering. For example, consider the nature of the copyrighted work. Courts have been extremely protective of unpublished works, and have steadfastly refused to find fair the use of an unpublished work. See Harper & Row, Publishers, Inc. v. Nation Enters., 471 U.S. 539, 555-60 (1985) (finding one magazine's "scoop" of prepublication excerpts of President Ford's memoirs regarding his pardon of President Nixon not a fair use); Salinger v. Random House, Inc., 811 F.2d 90, 98-99 (2d Cir.) (holding issue of injunction permissible where biographer had taken substantial portions from famous author's copyrighted unpublished letters), cert. denied, 484 U.S. 890 (1987). This protection stems from "the author's right to control the first public appearance of his expression." Harper & Row, 471 U.S. at 564. In the case of software, however, a program can remain unpublished even after it has been disseminated to the public, due to the unreadable nature of its object code. Therefore, when considering whether reverse engineering is a fair use, one should recognize that the original author has already exploited his "unpublished" work.
(151) See Hart, supra note 54, at 113.
(152) Consider the statement of one industry representative, made before Congress: "[T]he twin goals of certainty and encouragement of innovation can be achieved only if legitimate reverse engineering is permitted. We feel that existing 'fair use' provisions of Section 107 of the Copyright Law may not be sufficient, however, as they tend to emphasize non-commercial purposes." Copyright Protection for Semiconductor Chips: Hearings on H.R. 1028 Before the Subcomm. on Courts, Civil Liberties, and the Administration of Justice of the House Comm. on the Judiciary, 98th Cong., 1st Sess. 201 (1983) (statement of NEC Electronics U.S.A., Inc.).
(153) See, e.g., PATRY, supra note 149, at 400 (acknowledging that the typical reverse engineer does not decompile a program "for the greater public welfare but [does so] only for the commercially selfish purpose of increasing . . . profits by marketing a product in direct competition with the original").
(154) Consider the example of the WriteIt and GraphIt programs described earlier. See supra text preceding note 92.
(155) Although the inner workings of computers are more easily understood if they are humanized, it should be clear that programs do not actually ask, talk, or understand. Communication between operating systems and application programs is generally performed via a series of routines known as "system calls" or "a toolbox." See, e.g., APPLE COMPUTER, INC., 1 INSIDE MACINTOSH (1985) (describing the toolbox of the Apple Macintosh). For example, an operating system is designed so that it will draw a rectangle whenever it receives the instruction "DrawRectangle." The application program will then be written so that it sends the "DrawRectangle" instruction whenever a rectangle must be drawn on the screen.
(156) The possibility exists, however, that some amount of copying is necessary to achieve such vertical compatibility. This problem is discussed further in light of the third factor of fair use--amount and substantiality of the portion used. See infra notes 174-78 and accompanying text; see also Vault Corp. v. Quaid Software Ltd., 847 F.2d 255, 267-68 (5th Cir. 1988) (permitting the copying of 30 characters from the original work in order to make it vertically compatible).
(157) See supra notes 144-47 and accompanying text.
(158) There is one subcategory of vertically compatible programs that may not be desirable--those programs that destroy or counteract the effectiveness of the original program. For example, in Hubco Data Prods Corp. v. Management Assistance Inc., 219 U.S.P.Q. (BNA) 450 (D. Idaho 1983), the plaintiff placed "governors" which restricted the power of his operating system on certain versions of his program which then were sold at a lower price. The defendant developed and sold a program that would remove the "governors," thereby restoring full power to the plaintiff's operating systems. To do this, the defendant's program would compare line-by-line a "full power" operating system (stored in its memory) with the user's "less powerful" operating system, removing any differences from the latter. The court held that the method used by the defendant's program could be a copyright infringement, and therefore granted a preliminary injunction to the plaintiff. See id. at 452, 457-58.
A more common example of this genre of "destructive programs" are the "copying" programs. Manufacturers often use "copy protection" software to physically prevent the unauthorized duplication of their programs. Copying programs, through a variety of methods, undo this protection, thus allowing users to freely pirate the manufacturer's program. This type of compatibility, however, has been explicitly upheld by the Fifth Circuit. In Vault Corp., the court allowed the defendant's copying of 30 characters by the "copying" program (RAMKEY), noting that "Vault's program and RAMKEY serve opposing functions; while Vault's program is designed to prevent the duplication of its customers' programs, RAMKEY is designed to facilitate the creation of copies of Vault's customers' programs." Vault Corp., 847 F.2d at 268.
(159) This result occurs because other forms of software, such as operating systems and microcode, are generally sold in conjunction with the computer itself. Because every computer owner will already own a copy of the original operating system and microcode, there is not much of a market for programs that will perform the same tasks. Application programs, however, are generally sold separately, thus creating a market for horizontally compatible programs.
(160) See supra notes 126-127 and accompanying text.
There is no question, overall, that Quattro Pro's user interface is substantially different from the Lotus 1-2-3 user interface, except in one respect. The Borland product can be executed in a "Lotus 1-2-3 emulation mode," that is, by specifying a particular command the Borland spreadsheet incorporates the Lotus 1-2-3 menu structure into its own.
Id. This feature was included because "[Lotus] 1-2-3 is the de facto standard for spreadsheets, [thus] any company hoping to achieve significant success must be compatible with it." Peter H. Lewis, When Computing Power is Generated by the Lawyers, N.Y. TIMES, July 22, 1990, at F4.
Despite these justifications, Lotus Development Corporation, encouraged by its victory in Lotus Dev. Corp. v. Paperback Software Int'l, 740 F. Supp. 37 (D. Mass. 1990), has instigated a currently pending infringement suit against Borland International. See Carissa Casey, Lotus v. Borland Finds New Twist: Lotus Development Corp., Borland International Look-and-Feel Law Suit, PC USER, Oct. 23, 1991, at 18, 18, available in LEXIS, Nexis Library, Current File (describing the suit between Lotus and Borland).
(162) Note that this "innovation" requirement is not the same as the originality requirement that determines whether or not a work is copyrightable. While a low standard of originality is used to determine copyrightability, a significantly higher standard should be used when considering whether an infringing use should be exempted. The originality standard of the SCPA would likely strike a good balance. See supra notes 80-81 and accompanying text.
(163) See infra notes 174-78 and accompanying text.
(164) This is an advantage to developers who, by keeping programs unpublished, are able to secure trade secret protection in addition to copyright protection. See supra notes 62-66 and accompanying text.
(165) See supra note 150.
(166) See supra notes 126-29 and accompanying text.
(167) See, e.g., Samuelson, supra note 17, at 510.
(169) See Samuelson, supra note 10, at 680 ("[W]e must realize that it is not the application program alone that performs the task . . . . Nor is it the hardware alone. Rather, it is the complex hierarchy of programs and hardware that, while interacting with one another, works as a unit to perform a particular application task."). For an example of this interaction between programs, see supra note 155.
(170) See supra note 13 and accompanying text.
(171) An operating system provides a "platform" from which a user can choose and run specific programs. Operating systems can also include "a toolbox," a set of common programs and routines that may be accessed and run by any application program. See supra note 12 and accompanying text.
(172) See Microsoft to Launch Windows Ads on TV, REUTERS, Jan. 23, 1992, available in LEXIS, Nexis Library, Current File (noting that Microsoft has already reached about 20 million of 50 million desktop machines capable of using the program).
(173) In practice, this is probably not likely because an operating system generally will not become popular unless there are a large number of programs written for it. Thus, developers generally distribute the interface information for their operating systems. But note that Microsoft is currently under investigation by the FTC for antitrust violations. See Brit Hume, Of Mice and Software: The Antitrust Case Against Microsoft, WASH. POST, Apr. 22, 1991, Washington Business, at 17.
(174) 17 U.S.C. section 107(3) (1988).
(175) By definition, most vertically compatible software would fit into this category. The application of this third factor therefore meshes well with the first factor, which would exempt all vertically compatible works.
(176) This would decide the two Lotus cases in a satisfactory manner. Both Borland and Paperback Software took large portions of Lotus 1-2-3's user interface. See Lotus Dev. Corp. v. Paperback Software Int'l, 740 F.Supp. 37, 68-70 (D. Mass. 1990); Casey, supra note 161, at 18. Borland, whose Quattro Pro program is substantially original and innovative, would be exempted, while Paperback Software, whose VP-Planner was more or less an unoriginal clone, would not be exempted.
(177) See supra notes 25-35, 142 and accompanying text.
(178) Of course, there will be instances in which a program copies the structure of another program without adding anything original. In such a case, the issue of whether the structure was idea or expression will undoubtedly arise. This, however, is really more a question of infringement rather than exemption. The compatibility exemption focuses not upon whether there was an infringement, but whether the particular effort to achieve compatibility was desirable or not.
Copyright 1992 Gale, Cengage Learning. All rights reserved.
Defining an "adequate" package of health care benefits.
A proposal for the indexation of debt for inflation.

References: v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
sui generis
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v.