¶1

The proper legal treatment of "code" is one of the most contested topics of cyberlaw.1 Over time, observers examining the issue have taken a broad range of positions, citing such diverse legal regimes as patent law,2 copyright law,3 and even sui generis regimes of intellectual property protection4 as the most appropriate legal basis for the protection of software. The most recent claim in the debate is that software should be "open." The "open source movement," whose proponents were the first to raise this claim, has recently received a great deal of public attention,5 political support6 (despite its radical stance) and endorsement from the stock markets.7 Open source advocates frequently claim that software should either not be subject to intellectual property law at all or benefit from only limited protection.8 The open source philosophy has been surprisingly well-received in legal academia, whose members, such as Larry Lessig, advocate a slightly more moderate stance.9 While arguing that affording software too much legal protection might undermine some of the central political values upon which our society is based, Lessig recognizes the continued need for intellectual property protection.

¶2

In this Article, I have two goals: First, I will suggest a possible reason why parts of legal academia have reacted so favorably to the open source philosophy. Second, I will take a closer look at the philosophy itself and try to show that it is conceptually flawed. Based on a thorough analysis of the concept of "openness," I will argue that, although a casual inquiry might create the impression that the current application of copyright law to software is inherently inconsistent, closer reflection leads to the conclusion that there are in fact no such inconsistencies, that the open source philosophy does not constitute a viable alternative to the current regime, and that copyright law should therefore continue to be applied to software in the way in which it is applied currently, meaning that software developers should not be required to disclose the source code of their software. My thesis, which is based on a utilitarian conception of intellectual property law, is backed by the empirical observation that the current regime has benefited society by, among other things, encouraging commercial software houses, such as Microsoft and Oracle, to develop and market innovative programs that enable people to use PCs in an infinite number of applications. In making this argument, I hope to provide a missing link in the ongoing academic debate, which, while rich with political arguments in favor of open code, appears not to have devoted sufficient attention to the economic risks associated with forcing software developers to open up their code to the world at large. Hopefully, the analysis provided in this Article will give judges and legislatures a balanced picture and enable them to take a sober look at the popular, albeit in my view mistaken, belief that the law as it currently stands affords software developers too much power.

¶3

Part I describes the nature of software and the unique relationship between source code and object code, and explores how intellectual property law is currently applied to these two aspects of software. Putting this question at the beginning of the discussion is helpful because in many ways it holds the key to understanding and evaluating the complex issues surrounding the open source movement. Regarding the current application of copyright law to software, I draw two main conclusions: First, with regard to the widespread perception that software patents might hamper rather than promote progress in the software industry, I argue that further research should be carried out to validate these concerns. In addition, I suggest several slight modifications to the current framework that might be made in case the government were to decide to address the issue. Secondly, I point to two ostensible inconsistencies in the current application of copyright law to software that I consider the main, if unstated, reason why the claim that software should be "open" has been received so enthusiastically in parts of the academic world. These perceived inconsistencies concern both the way in which copyright law protects software developers in comparison with authors of other types of creations and the relationship of copyright protection of computer programs to patent and trade secret protection.

¶4

Part II takes a closer look at the open source philosophy itself and evaluates a number of policy reasons for and against affording software various types of legal protection, focusing on Larry Lessig's works on cyberlaw as well as on a number of arguments developed by the open source movement that so far have not been subjected to a systematic analysis in law journals. In doing so, I introduce a distinction between two different concepts of "openness": legal openness and factual openness. Legal openness means the complete freedom by an intellectual creation of all legal restrictions. Factual openness, by contrast, is a measure for the amount of factual access that the public has to the intellectual substance of a creation. While the distinction between legal and factual openness is an especially useful tool for digging through the multitude of arguments that have been put forward in the open source debate, it applies to all types of intellectual creations and hence may provide a useful conceptual framework for analyzing policy issues arising in other areas of intellectual property law as well. On the basis of this distinction, Part II's conclusion is that it would be hazardous and thus undesirable to deny software producers legal protection or to force them to disclose their source code, which, while containing commercially sensitive material, usually has no or only little intellectual value.

¶5

Part III ties the policy discussion of Part II to the currently applicable law and, in doing so, attempts to resolve the ostensible inconsistencies identified in Part I. On the basis of two widespread theories of intellectual property law (the utilitarian incentive theory and the Lockean labor-desert theory), it tries to show that the inconsistencies identified in Part I are in fact necessary adjustments of copyright law to account for the unique characteristics of software and the relationship between source code and object code.

 

I. The Legal Protection Of Software

BACK TO TOP | TABLE OF CONTENTS

 

A. Software

¶6

As background to the analysis of this Article, this section introduces the concept of "software" and certain related terms, and provides an overview of software technology. Although the discussion is aimed at the computer layman, the technologically savvy reader equally may find it beneficial, as it focuses the attention on certain aspects of software technology that are essential to understanding the open source philosophy.

¶7

In the following, the terms "software," "computer programs," and "code" will be used synonymously to refer to a series of instructions whose purpose and effect is to make a computer behave in a certain predetermined way.10 Strictly speaking, this equation is not entirely correct. "Code" signifies merely a series of instructions for a computer, whereas a "computer program" is a self-contained body of code designed to achieve a certain result. "Software," by contrast, encompasses not only computer programs but also the data processed by them and the accompanying documentation.11 For purposes of this Article, however, these distinctions are irrelevant. The point is merely that software, however named, is what determines how computers operate.

¶8

Another important pair of concepts is that of "source code" and "object code." While technically source code and object code are merely two different ways of representing a piece of software,12 they differ from each other in several fundamental respects, and in order to analyze the legal issues surrounding the legal protection of software and the claims of the open source movement, it is important to understand these differences.13 The first noteworthy difference is that object code is intended to be directly executable on computers. Because computers understand only the machine language supported by the central processing unit ("CPU") on the basis of which they operate, object code must comply with the machine language of the type of computer on which it is intended to run.14 Source code, by contrast, is not intended to be directly executable. While source code thus need not comply with any particular machine language,15 its independence of technical constraints means that it must be translated into object code before it can be executed.16 The translation of source code into object code is called compiling. The compilation of software is an automated task that is usually carried out by standardized compiler software.17 Unlike translations from one human language into another, such as from English to German, however, the compilation of source code into object code is a one-way process. In other words, once a piece of source code has been translated into object code, it is virtually impossible to translate it back into the original source code.18 The main reason is that when compilers translate source code into object code, they do not simply replace terms and connectors of one language with those of another, but also perform a series of optimizations with aN=LEFT VALIGN=TOP NOWRAP WIDTH="30">¶8

Another important pair of concepts is that of "source code" and "object code." While technically source code and object code are merely two different ways of representing a piece of software,12 they differ from each other in several fundamental respects, and in order to analyze the legal issues surrounding the legal protection of software and the claims of the open source movement, it is important to understand these differences.13 The first noteworthy difference is that object code is intended to be directly executable on computers. Because computers understand only the machine language supported by the central processing unit ("CPU") on the basis of which they operate, object code must comply with the machine language of the type of computer on which it is intended to run.14 Source code, by contrast, is not intended to be directly executable. While source code thus need not comply with any particular machine language,15 its independence of technical constraints means that it must be translated into object code before it can be executed.16 The translation of source code into object code is called compiling. The compilation of software is an automated task that is usually carried out by standardized compiler software.17 Unlike translations from one human language into another, such as from English to German, however, the compilation of source code into object code is a one-way process. In other words, once a piece of source code has been translated into object code, it is virtually impossible to translate it back into the original source code.18 The main reason is that when compilers translate source code into object code, they do not simply replace terms and connectors of one language with those of another, but also perform a series of optimizations with a view to enhancing the program's speed and resource utilization. As an (unintended) side-effect of these optimizations, virtually all information regarding the structure of the source code, the names that the developer has given the modules and data structures of which the software consists and the precise sequence of the instructions used is lost. Thus, it is practically impossible to recreate a program's original source code from its object code. Software firms do offer decompilers, which attempt to reverse engineer object code,19 but while decompilers frequently generate source code which, when re-compiled, leads to object code that is functionally equivalent with and may even look similar to the original object code, the decompiled source code invariably looks different from the original source code.

¶9

Software developers rarely write a program in object code, but instead first write the program's source code and then have a compiler generate the corresponding object code.20 This procedure is efficient because source code, unlike object code, does not have to comply with machine language. Given the greater flexibility of source code, it is much easier for programmers to create source code than to write object code. Coding directly in machine language would be problematic for at least two reasons. First, because the instructions of all machine languages are based directly on the design of the integrated circuits of the CPUs used in modern computers, their functionality is relatively limited.21 From a technological perspective, this accommodation is an advantage because it enables computers to execute billions of machine language instructions per second. At the same time, however, it means that software developers who used such languages to create programs would have to combine an unimaginable amount of instructions to achieve any but the most trivial results. Second, given the current state of technology, all machine languages are binary, which means that their instructions consist of a series of only zeros and ones.22 This feature makes it extremely difficult for human beings to read and write object code, let alone devise solutions for complex problems in machine languages. Owing to these two limitations, the manual creation of object code would not only be burdensome, but also time-consuming and error-prone.23 In comparison, creating source code is much less problematic. Unlike object code, source code may be devised on the basis of any computer language for which a compiler exists that is capable of translating source code written in that language into object code. Such languages are commonly referred to as high-level languages (to distinguish them from low-level machine languages).24 Over time, a vast number of high-level languages have been developed (along with compilers), some of which are well-known even outside the computer scientific community. The most prominent examples are "C," "Pascal," and "Basic."25 The common characteristic of all of these languages is that they consist of words and structures modeled on the English language and widely used mathematical symbols.26 Because these features allow the representation of even complex algorithms and data structures in a way that is intelligible to human minds,27 they not only make it relatively easy for human beings to learn high-level languages, but developers who use such languages are frequently able to come up with new software much faster than if they had to rely solely on machine languages. In addition, the fact that a number of common high-level languages are understood by virtually all code writers facilitates maintaining and updating software as changes are made to existing programs and new versions are created.

¶10

The different characteristics of source code and object code and their unique relationship create a powerful incentive for software producers to offer consumers only the object code of their programs and to keep the source code confidential.28 It is essential to understand the effect of this interrelationship because it appears to go to the heart of why the open source movement has met with so much enthusiasm in legal academia. First, as noted above, object code is all that is necessary for software to run on computers. Since running on computers is all that ordinary consumers expect software to do, virtually all of the commercial value of software is embodied in its object code.29 By implication, then, any additional revenue that software producers would be able to raise by providing consumers with source code in addition to object code is limited.30 As a result, software producers have hardly any economic incentive to provide consumers with access to source code. This weak incentive is transformed into a strong disincentive by the fact that the source code of most industrially produced software contains valuable trade secrets31 which, if disclosed, would unfairly allow a software company's competitors to take a free ride on its development efforts.32 Against this background, it is perfectly understandable that developers of commercial software are generally reluctant to make the source code of their software publicly available. Different considerations apply only in special circumstances, such as when access to a program's source code is essential to a software supplier's customers in order to enable them to seamlessly integrate the software in their existing IT systems or to allow their staff to fix bugs as they come up.

¶11

It is essential to appreciate that the incentives of software developers to commercialize the object code of their programs while keeping the corresponding source code secret is not a special feature of the software world. On the contrary, other types of creators have the exact same incentives as they, too, would prefer to exploit only the commercially valuable aspects of their creations, while keeping any related trade secrets confidential. The only difference is that software, as discussed, has two manifestations (source code and object code), and that the respective characteristics of each of these manifestations enable software developers to do what creators normally find difficult to achieve, namely to make money on the commercially valuable aspects of their creations while keeping the underlying trade secrets to themselves. Writers, for example, cannot sell their stories without disclosing to their readers the structure and content of the text. Similarly, inventors who sell technical apparatuses cannot prevent third parties from studying how they are constructed and from building functionally equivalent applications themselves. The question of whether this difference mandates that software be treated differently from other creations might, as we will see, be the central issue that may be responsible for the popularity of the open source movement in legal academia. In the remainder of this Article, I will show why some members of academia may have answered the question with "yes," and why, on closer reflection, the answer should be "no."

¶12

In summary, therefore, source code and object code differ from each other in three respects. First, while source code is intelligible to human beings, object code is not. Second, unlike source code, object code is directly executable on computers. Third, it is virtually impossible to recreate the source code of a piece of software on the basis of its object code. As a result of these differences, software developers have a natural incentive to keep the source code of their programs secret and publicize only the resulting object code.

 

B. Legal Protection

¶13

As the brief discussion of software technology in the previous section suggests, there are essentially two dimensions along which law might regulate software. On one hand, it might regulate the amount of legal protection afforded software producers (with respect to each of source code and object code). On the other hand, it might reinforce or alter the existing incentives of software producers to make only object code available to consumers while keeping source code secret, thereby regulating the amount of factual access that the public has to any given piece of software. This section explores how the currently applicable law regulates software along each of these two dimensions. More precisely, it examines the applicability of patent, copyright and trade secret law to three different aspects of software: (i) algorithms, which are essentially abstract descriptions of the steps that computer programs perform;33 (ii) source code; and (iii) object code. While various other aspects of software (such as the ornamental design of the media on which computer programs are stored and the names under which they are marketed) may be eligible for other types of intellectual property protection, none of these other prongs of intellectual property law protects the functional elements of computer programs.34 Accordingly, the following discussion will focus on patent, copyright and trade secret law.

 

1. Patent law

¶14

Generally, patent law provides legal protection for inventions but not for discoveries in the strict sense (the ambiguous wording of the Intellectual Property Clause of the Constitution notwithstanding).35 Its purpose is "[t]o promote the Progress of Science and useful Arts."36 The principal source of patent law in the United States is the Patent Act.37 Section 101 of the Patent Act defines the scope of patentable subject-matter as encompassing "products, processes, compositions of matter and improvements thereof."38 While the U.S. Supreme Court once characterized the statutory language as covering "anything under the sun that is made by man,"39 it has always been clear, consistent with the statutory language, that certain things are not patentable, namely abstract ideas,40 laws of nature and fundamental scientific principles,41 mathematical formulas,42 and, despite a controversial recent decision by the U.S. Court of Appeals for the Federal Circuit (the "CAFC"),43 business ideas.44

¶15

In light of Section 101 of the Patent Act, the only aspects of computer programs that may be eligible for patent protection are the algorithms on which they are based. Algorithms, after all, might be considered processes. Source code and object code, by contrast, merely implement these processes and are therefore not independently patentable. As a result, patent cases involving software usually center on the question of whether the algorithms underlying the software are eligible for a patent.

¶16

Given the scope of Section 101 of the Patent Act, the threshold question is whether algorithms constitute patentable processes or whether they fall within the mathematical formula/abstract idea limitation. The Court addressed the issue for the first time in 1972 in Gottschalk v. Benson.45 The question in Gottschalk was whether an algorithm for converting decimal numbers into binary numbers constituted patentable subject-matter within the meaning of Section 101 of the Patent Act. The Court held that it did not.46 It noted that algorithms were similar to abstract intellectual concepts and therefore not patentable. While it recognized that the algorithm at issue had a practical application in that it could be used "in connection with a digital computer,"47 the Court concluded that granting a patent for the claimed process would be tantamount to patenting the algorithm itself.48 It should be noted that, in reaching its conclusion, the Court did not argue that software patents are socially undesirable. Rather, it felt that given the complexity of the question of whether algorithms should be considered patentable subject-matter, the issue was better addressed by Congress, which, in the Court's view, should amend the Patent Act if empirical data were to show that software patents are beneficial.49 Unfortunately, to date, Congress has failed to clarify the controversy. Interestingly, the Court's self-restraint in Gottschalk in relation to patent law is mirrored by its approach to copyright law in Sony Corp. v. Universal City Studios more than ten years later where it stated that the judiciary should be careful in its application of intellectual property law to new technologies and that in cases of doubt it was for Congress, not the courts, to decide how the law should apply to such technologies.50

¶17

Six years after Gottschalk, in Parker v. Flook51 the issue of whether algorithms are eligible for patent protection came up again, and the Court used the occasion to affirm the principle that it had stated in Gottschalk. In Parker, the case under inquiry involved a new algorithm as part of an otherwise known process for calculating alarm limits in a petroleum refining process. The respondent-inventor argued, and the Court agreed, that Gottschalk was not controlling because the process for which respondent sought a patent involved the use of an algorithm in a specific petrochemical application rather than in connection with a general purpose computer. Nevertheless, the Court reversed the judgment of the Court of Customs and Patent Appeals (the predecessor to the CAFC), which had held the claimed process patentable subject-matter. Respondent argued that while the algorithm as such was as abstract as the one in Gottschalk, the process it claimed used the results achieved by the algorithm for a "specific post-solution activity," namely the adjustment of the alarm limit to the figure calculated by means of the algorithm.52 Therefore, respondent concluded, the algorithm fell outside of the mathematical formula exception and should be considered patentable subject-matter. The Court, however, disagreed. Noting that Section 101 of the Patent Act was not "like a nose of wax which may be turned and twisted in any direction . . . ,"53 it rejected respondent's argument as exalting form over substance. While it conceded that an algorithm may be patentable if there is some "inventive concept in its application,"54 token post-solution activity was not enough to bring the algorithm within the scope of patentable subject-matter. After refusing to hold the algorithm at issue patentable, the Court asked whether any other aspects of the claimed process were novel, nonobvious and useful, and thus patentable.55 Since this was not the case, the Court held the process unpatentable.

¶18

In 1981, the Court decided Diamond v. Diehr,56 which is yet another case touching on the question of whether algorithms constitute patentable subject-matter. The issue before the Court was similar to that which lay at the heart of Gottschalk and Parker. This time, the facts involved a process for molding raw, uncured synthetic rubber into cured precision products. The process relied on software to continuously recalculate a certain formula, and the question was whether the process was eligible for patent protection. The Court answered the question affirmatively, emphasizing that respondent-inventors claimed a patent for an improved process for molding rubber articles rather than for an algorithm in the abstract and that, consistent with Gottschalk and Parker, a process that otherwise contained statutorily patentable subject-matter did not become unpatentable simply because it used a mathematical formula or algorithm. According to the Court, the difference between Diehr and Parker, which, as discussed, involved similar facts, was that the claimed process in Parker, apart from the algorithm, contained only "token post-solution activity,"57 whereas the process in Diehr "applie[d] [the algorithm] in a structure or process which, when considered as a whole, [was] performing a function which the patent laws were designed to protect."58 Despite the Court's attempt to distinguish Diehr from Parker, the facts of the two cases are very similar, so similar in fact that Justice Stevens, joined by three other justices, dissented from the majority's opinion.59 In explaining the Court's holding, Stevens reckoned that the judges' deviation from Parker resulted from their failure to read the claims of the patent application correctly.60

¶19

Although difficult to align, the unifying theme of all three decisions discussed above is that algorithms as such are not patentable, whereas concrete and tangible inventions that use an algorithm as part of a specific application are eligible for a patent, provided that they fulfill the further threshold criteria of utility, novelty, and nonobviousness.61 In subsequent years, however, the Court of Customs and Patent Appeals/CAFC, whose judges did not always agree with the Supreme Court's reading of Section 101 of the Patent Act,62 had difficulty coming up with a consistent body of case law.63

¶20

After years of uncertainty, the CAFC finally revisited the issue in State Street Bank & Trust Co. v. Signature Fin. Group, Inc. in 1998.64 The case involved a computer program for calculating daily changes in the allocation of assets among various mutual funds that had pooled their assets in a partnership in order to achieve economies of scale. The issue was whether the algorithm employed by the software constituted patentable subject-matter. The CAFC held that it did. In examining the question, the CAFC found, without much discussion, that for an algorithm to be patentable, it was enough if it achieved a "useful, concrete, and tangible result . . . even if the useful result is expressed in numbers, such as price, profit, percentage, cost, or loss."65 The CAFC's reasoning obviously goes far beyond the three Supreme Court precedents discussed in the preceding paragraphs. Because virtually all algorithms lead to useful results that can be expressed in numbers, the State Street Bank holding effectively eliminated the subject-matter requirement of Section 101 of the Patent Act for software. Doctrinally, the CAFC's reasoning in State Street Bank appears to be inconsistent with the aforementioned Supreme Court precedents, which leave no doubt that the mere fact that an algorithm leads to a useful and tangible result is not by itself sufficient to render it patentable subject-matter.66 It is unclear whether State Street Bank will prevail as the law of the land. While the CAFC has affirmed its approach,67 it is uncertain whether the Supreme Court will break with its own precedent the next time it has an opportunity to decide a pertinent case.68

¶21

Whether or not one follows State Street Bank, certain algorithms, specifically those used as part of novel, nonobvious, and useful products, processes, or compositions of matter, are clearly patentable. With respect to these, the protection that patent law affords software developers is, in many ways, much more powerful than the protection available to them under either trade secret or copyright law.69 Instead of merely prohibiting third parties from ferreting out secret algorithms by improper means, which is what trade secret law does, a valid patent prohibits third parties from using the patentee's algorithm altogether. And unlike copyright law, patent law does not provide an exception for independent development. As a result, a patent is usually considered the by far most powerful type of intellectual property protection available to software developers.70

¶22

From the perspective of software developers, however, patents also suffer from a number of drawbacks. First, while patent law affords inventors extremely comprehensive legal protection, it grants the public unrestricted factual access to what one might call the intellectual substance of the patented inventions. The reason is that, pursuant to Section 112 of the Patent Act, a patentee is required, as a precondition for being issued a patent, to provide a detailed description of its invention to the patent examiner.71 Once the patent issues, the description is disclosed to the public.72 The depiction of the invention has to be so detailed as to enable someone skilled in the art to reduce the invention to practice without undue experimentation73 and reflect the best mode of practicing the invention known to the inventor.74 Such stringent disclosure requirements run counter to the interests of patentees generally and, in particular, to those of software developers, as they require revelation of any trade secrets that their code may contain. This is especially true of algorithms that have a useful life that exceeds the statutory term of patent protection. The second drawback of software patents is that the life of a patent is limited to 20 years from the date of the filing of the patent application with the Patent and Trademark Office (the "PTO").75 Given that the useful life of most software is only about five years,76 this may be less of a limitation for software than for other types of inventions. Some software, however, may be based on algorithms whose commercial life lasts for 20 years or longer. This is particularly true in respect of file formats that become widely used standards, such as the General Image Format ("GIF"). Moreover, software producers frequently release their software in a series of versions or offer different programs based on the same technology. Because the 20-year term runs from the date at which the patent application is filed, software that incorporates the patented technology but is released later is subject to a shorter term of protection. Finally, patents are expensive, especially when a company seeks to obtain legal protection across multiple jurisdictions.77

¶23

Recently, the current application of patent law to software has come under attack from various angles and especially from circles that are close to the open source movement.78 One concern that is frequently articulated points to empirical evidence suggesting that the increasing lenience with which software patents have been issued since the U.S. Supreme Court's decision in Diamond in 198179 has not sparked a corresponding increase in research and development in the software industry.80 If true, this would mean that patent law as currently applied to software misses its constitutionally mandated goal of promoting progress.81 Interestingly, in 1966, the President's Commission on the Patent System reached a similar conclusion, noting that "the creation of programs has undergone substantial and satisfactory growth in the absence of patent protection . . . . "82 In addition, the fact that software patents are increasingly issued for inventions that even hobby programmers would consider obvious could be seen as leading to results that the legislature and courts have not intended. First, it leaves companies no choice but to seek patent protection for as many obvious technologies as possible in order to be able to induce their competitors, which may hold patents on similarly obvious technologies that are key to particular applications, to cross-license these technologies at commercially viable fees. Second, it compels companies to acquire and maintain comprehensive patent portfolios so as to increase their chances to settle any patent infringement suits that may be brought against them by their competitors. In addition, the mere size of a company's patent portfolio, irrespective of which technologies it covers, may have a favorable impact on the company's stock market evaluation. The need for companies to accumulate software patents tends to favor established players over new market entrants as the former are more likely to have specialized legal departments.83 Another point to bear in mind is that software patents favor commercial software over open source software as the latter is usually developed on a decentralized basis by individuals without the financial backing of corporate institutions. The above concerns, to the extent they have merit, are aggravated by the fact that the number of software patents has increased from less than 1,000 in 1983 to almost 7,000 in 1995.84 Observers estimated that by the end of 1998, the year in which State Street Bank was decided, the number had grown to 17,500.85

 

2. Copyright law

¶24

Another source of legal protection for software is copyright law,86 which, in today's world, is probably the most important prong of intellectual property law as far as the protection of software is concerned.87 At the same time, its application to software is more complex than that of patent or trade secret law. Copyright law, which is governed by the Copyright Act,88 protects original expressions of ideas but not ideas as such.89 Similarly to patent law, it seeks to promote progress. In 1980, in response to a report by the Commission on New Technological Uses of Copyrighted Works ("CONTU"),90 which Congress established specifically for the purpose of examining the issues generated by the interrelationship of advancing technology and copyright law,91 Congress amended the Copyright Act to clarify the application of copyright law to computer programs.92 Acting on a recommendation by CONTU,93 Congress amended Section 101 of the Copyright Act, which delineates the scope of copyrightable subject-matter, to add a provision that defines the term "computer program."94 Since Section 101(a) defines the concept of "literary work" broadly, encompassing "words, numbers, or other verbal or numerical symbols or indicia,"95 and since the legislative history makes it clear that Congress intended that concept to encompass software in all its manifestations,96 it soon became clear that the Copyright Act covers both the source code and the object code of software.97 CONTU's second recommendation was that the idea/expression dichotomy,98 which is a key concept of copyright law, be applied to software as well.99 As a result, a central question that arises in virtually all copyright cases involving software is which aspects of software constitute original expressions of ideas and are thus copyrightable literary works within the meaning of Section 101, and which are merely facts or ideas and as such ineligible for copyright protection.

¶25

Since protocols and interface specifications consist of factual information, similar to the description of the bookkeeping system that was at issue in Baker v. Seldon, they are not considered eligible for copyright protection.100 Courts have confirmed this understanding on the basis of applying the scènes-a-faire doctrine101 to those elements of a piece of software that are necessary make the software interoperable with other programs.102

¶26

The legal status of algorithms, source code, and object code is more complex. The traditional test for distinguishing between ideas and expressions is the "levels of abstraction" test developed by Learned Hand in Nichols v. Universal Pictures Corp., a landmark case in copyright law.103 The purpose of the test is to determine whether an alleged copyright infringer has stolen the protected expression of an author's work, or whether the purported wrongdoer has merely borrowed from the work's unprotected idea. The test is based on the notion that every work of authorship can be analyzed as a series of abstractions of increasing generality.104 In Learned Hand's view, "there is a point in this series of abstractions where they are no longer protected, since otherwise the [creator] could prevent the use of his 'ideas,' to which, apart from their expression, his property is never extended."105 If the similarities between the allegedly infringing work and the original occur in the realm of idea, the alleged infringer goes free; otherwise, it may be liable for infringement.106 In practice, Learned Hand conceded, "[n]obody has ever been able to fix that boundary, and nobody ever can."107 As a result, it is impossible to formulate a general rule; rather, the levels of abstraction test needs to be applied on a case-by-case basis.108 The case-specific nature of the levels of abstraction inquiry notwithstanding, it would seem safe to say that algorithms in the abstract are generally more akin to ideas, whereas source code and object code are generally more similar to expressions of ideas (the ideas being the algorithms that they implement). Therefore, applying Learned Hand's reasoning to software cases, the likely result would be that algorithms as such are not copyrightable works.109 This view, however, is not universally accepted.

¶27

Specifically, in Whelan Associates v. Jaslow Dental Lab, 110 a case involving a software system for the management of a dental laboratory, the Third Circuit developed a test that would seem to dictate the exact opposite conclusion. Rather than looking for ways to apply Learned Hand's levels of abstraction test to software cases, the court based its analysis on Baker, another seminal case in copyright law, in which the Supreme Court held that aspects of a utilitarian work (blank forms) that are necessary to practice the art described therein (accounting) are not protected by copyright law, even if other aspects of the work are eligible for protection.111 The Third Circuit found Baker particularly persuasive because unlike Nichols (the case in which Learned Hand developed the levels of abstraction test),112 Baker involved a utilitarian work.113 Noting that Baker "focused on the end sought to be achieved,"114 the court argued that with respect to computer software, as with respect to utilitarian works generally, the line between idea and expression should be drawn with respect to the end sought to be achieved. In the court's view, the only aspects of a computer program that should be considered idea are its "purpose or function,"115 whereas everything "that is not necessary to that purpose or function"116 should be considered expression. An aspect of a piece of software should be regarded as unnecessary to achieving the software's purpose or function, the court explained, if there are "various means of achieving the desired purpose."117 Under the court's test, therefore, code that is mandated, for example, by efficiency reasons would seem to be ineligible for copyright protection, whereas most other code would be protected.

¶28

It should be noted that in Whelan the court defined the purpose or function of the software before it in an extremely abstract and general manner, namely as the efficient management of a dental laboratory. If courts were to apply a similarly all-encompassing formula in other software cases as well, they would have no choice but to consider most algorithms means of achieving a function rather than functions themselves. As a result, under Whelan, most algorithms would seem to qualify as copyrightable subject-matter. Policy-wise, this outcome is unfortunate because it expands the scope of copyrightable subject-matter beyond the boundaries of the levels of abstraction test that has become the generally accepted test for distinguishing between idea and expression in other areas of copyright law, thereby bringing copyright protection of software in proximity to software patents. While the Whelan court was aware of the argument that affording software too much legal protection might impede progress in computer science, it considered its approach necessary to put software on an equal footing with other intellectual creations.118 At the same time, it conceded that the test it had developed was "certainly not problem-free"119 and that its economic implications were "somewhat speculative."120 As a result, it suggested in a footnote that the test might need to be applied differently to software that is designed not just to achieve a certain purpose or function but to achieve it in a particular way.121 The practical significance of the court's qualification remains unclear.

¶29

In addition, one should recognize that while the Whelan formula may sound deceptively simple, it provides no greater guidance than the levels of abstractions test. For the answer to the question of whether a particular aspect of software falls on the idea side or the expression side varies, depending on how one delineates the program's function or purpose. This determination, however, like the application of the levels of abstraction test, has to be made on a case-by-case basis. Finally, it would seem that any attempt to distinguish software that seeks to achieve a certain end by means of a particular algorithm from software that has a certain function or purpose but that does not rely on a particular algorithm to achieve it, is more or less arbitrary.122 Not surprisingly, Whelan was received with mixed feelings by other courts.123

¶30

In Computer Associates v. Altai, the Second Circuit expressly rejected the Third Circuit's approach in Whelan.124 Following the analysis of a well-known commentator, the court particularly criticized that Whelan failed to appreciate the "reality of [the] structural design [of software]."125 According to the court, rather than being the expression of a single idea, software frequently consists of a number of modules, each being an independent expression of a separate idea. The Altai court's characterization of software and its recognition that programs have a modular structure is indeed a more accurate description of modern software design than the Whelan court's assumption that software represents a monolithic body of code that implements a single idea. To distinguish the ideas underlying the various modules of a piece of software from their expressions, the court relied on the levels of abstraction test. While it recognized that Nichols involved a traditional literary work, it found Learned Hand's insight to be so fundamental as to be amenable to adaptation for use with other types of works of authorship as well. According to the court, the decision as to which aspects of a computer program are copyrightable and which are not should encompass three steps.126 The first step should involve dissecting the software conceptually and isolating the various levels of abstraction. In the second step, one should, at each level of abstraction, single out those components that constitute ideas or elements mandated by efficiency constraints or external factors (such as elements necessary to achieve interoperability with other programs or widely accepted software design principles) or that are taken from the public domain. Finally, one should compare the remaining elements of the original software with the allegedly infringing copy and decide whether there are substantial similarities. The court's statement that certain aspects of software, including most notably "widely accepted programming practices within the computer industry,"127 should not be considered copyrightable combined with its recognition that software is rarely the expression of one single idea but usually consists of a number of self-contained, yet interrelated building blocks would seem to lead to the conclusion that the vast majority of algorithms as such constitute ideas, rather than expressions.

¶31

While the classification of algorithms remains controversial, source code is clearly an expression of an idea, the idea being the algorithm on which it is based (or, if one were to follow Whelan, the underlying function or purpose that the software seeks to achieve), and the expression being its representation in a high-level language on a tangible storage medium (such as a hard disk, a computer's RAM, or a printout).128 In light of the extremely diminished originality standard of copyright law,129 virtually all source code has to be considered original. As a result, it comes as no surprise that courts uniformly have held source code copyrightable.130

¶32

The legal status of object code is more complex. While courts have followed the CONTU recommendations and held object code copyrightable,131 the doctrinal basis for this qualification merits closer analysis. The reason why the qualification is not obvious is that usually when a literary work is translated from one language into another, copyright law regards the translation as a derivative work of the original and the translator as the holder of an independent copyright in the translation.132 The qualification of translations as derivative works has certain doctrinal implications. First, it should be noted that even though copyright law affords the translator a separate copyright in the translation, the original author's copyright remains intact. This means in particular that the author retains full control over all aspects of the commercialization of the original, including the power to decide whether derivative works should be prepared at all, and if so, by whom.133 As a result, the author of an unauthorized translation cannot prevent the holder of the copyright in the original from preparing or commissioning and commercializing other translations. Second, with respect to the unauthorized translation, the author and the translator are at a "standoff."134 While the author of the original may not commercialize the translation without the translator's consent, the translator has no right to disseminate the translation without the author's consent either. If the translator did so, it would violate the author's exclusive right to prepare derivative works.135 A third, and for our purposes the most interesting, implication is that given that courts consider computer programs literary works, the most consistent doctrinal classification of object code would be to regard it as a derivative work of source code. Technologically, after all, object code is merely a translation of source code from a high-level into machine language.136

¶33

Applying the derivative works doctrine to object code, however, would lead to awkward results. The main reason is that, as discussed earlier, software developers usually do not create object code manually. Instead, they generate source code first and then rely on compilers to handle the translation.137 As a result, however, the creation of object code does not require or even permit any originality on the part of the author of the source code from which the object code is derived. Originality, however, is a constitutional requirement for the grant of a copyright.138 Therefore, in order to consider object code a derivative work of source code, one would have to look further and ask who might supply the originality that would be required for the recognition of a separate copyright. Clearly, the only person that could provide that originality is the developer of the compiler software. Although compiling software is an automated process, it arguably does involve a certain amount of originality. The reason is that compilers, when transforming source code into object code, perform a number of optimizations.139 Since these optimizations, while mechanical, are based on sophisticated algorithms, they might be considered original transformations. To regard the owner of the compiler as the author of all software generated with the compiler's help, however, would be unsatisfactory from a practical perspective. For it would mean that the people who developed the source code of any given software would be unable to commercialize it autonomously. To sell the software's object code, they would need the permission of the author of the compiler, who, strictly speaking, would in turn have to obtain special permission from the company owning the compiler with which its own compiler was generated. Ultimately, the person who developed the first compiler for any given platform would be able to control all software subsequently created with it. Alternatively, companies could sell consumers source code instead of object code and authorize them to compile it. In practice, however, this obviously would not be a viable alternative since most consumers are not familiar with the usage of compilers. Moreover, the dissemination of source code only would divulge the trade secrets underyling the software.

¶34

To avoid these results, the U.S. Copyright Office has traditionally taken the view that object code is not a derivative work of source code.140 Instead, the Copyright Officers consider the source code of a piece of software and the corresponding object code as the same literary work. To support this approach, one might argue that while the originality hurdle of copyright law is extremely low,141 the use of a pre-fabricated compiler to create a translation based on a mechanical application of a fixed set of rules, similar to the production of a white page telephone directory listing the names of all subscribers in alphabetical order,142 may well be one of the few instances in which that threshold is not met. In the absence of originality, however, there is no separate work. As a result, on that theory, a software developer's copyright in the source code of its programs automatically extends to the object code even if the compiler used is owned by a third party. While this may be the only doctrinally feasible way to allow software developers to invoke copyright law for the protection of their object code, one should not forget that technologically source code and object code have very different characteristics.143 The fact that it is necessary to ignore these differences and to equate source code with object code in order to bring software within the scope of copyrightable subject-matter is one example of the apparent inconsistencies in the application of copyright law to software that may be responsible for the enthusiasm with which many academics have embraced the open source concept, which, as we will see in Part II, promises an internally consistent, if conceptually flawed, alternative to the current legal framework.

¶35

From the perspective of software developing companies, copyright law has numerous benefits and virtually no drawbacks. Its greatest advantage is that it shields them against the activity to which they are most vulnerable: verbatim copying. At first glance, Section 117 of the Copyright Act,144 which limits the scope of the exclusive right of software producers to control the reproduction and distribution of their object code would seem suggest a different assessment. The provision allows owners of computer programs to copy their software without the manufacturers' consent if, among other things, the copy is created as an essential step in the utilization of the software or for archival purposes. The provision also permits owners to transfer the software, along with all rights in it, to third parties.145 However, because the aforesaid limitations apply only to people who already own a piece of software, they do not reduce the number of consumers that potentially might purchase a copy of the software in the market. As demonstrated by numerous other provisions, the Copyright Act's overall goal is to protect software developers against the threat of unauthorized copying. One example of the Act's thrust is the way in which it treats the applicability of the first sale doctrine to software. While the first sale doctrine normally entitles purchasers of works of authorship to redistribute the copyrighted material without restrictions once it has been sold for the first time and while Section 117(a), as mentioned, applies this principle of the transfer of software,146 Section 109(b) limits the scope of the doctrine by providing that it does not apply to the commercial rental or lending of computer programs.147 The legislative history suggests that this limitation resulted from a concern that the first sale doctrine, when applied to software, might facilitate the creation and distribution of pirate copies.148 A second advantage of copyright law is that unlike patent law, it does not require software producers to disclose their source code. The lack of a disclosure requirement is not just an advantage in itself (although it is that as well), but it benefits software producers also because it allows them to combine copyright protection for object code with trade secret protection for source code.149 Finally, copyright protection is virtually perpetual for all practical purposes. While formally the Copyright Act provides protection for a term of 70 years (and, in certain circumstances, more than that),150 the useful life of most computer programs is estimated to be only about five to seven years.151 The statutory term of 70 years is extended by the fact that each subsequent revision of a piece of software is eligible for a new copyright provided that it satisfies the originality threshold and is sufficiently different from its predecessor versions.

¶36

The only downside of copyright law is that it does not prohibit third parties from independently developing and marketing software that is identical with a copyrighted program. As a result, it does not provide software developers with absolute protection. The likelihood, however, that a third party independently comes up with a program whose source code is substantially similar to that of an existing piece of software is extremely remote. The much more viable threat to software producers is the fact that consumers may make unauthorized copies of their object code, and in that respect, copyright law offers manufacturers of software generous entitlements.

¶37

In summary, the amount of legal protection that copyright law affords software developers, while weaker than that available under patent law, is still relatively strong. At the same time, it does not require programmers to grant the public factual access to the source code of their software but rather allows them to treat it as a trade secret. The resulting mix of legal protection for object code combined with the lack of any requirement for public factual access to source code makes copyright law an extremely attractive, and arguably the most attractive, legal choice for software developing companies.

3.  

3. Trade secret law

¶38

Finally, there is trade secret law. Unlike the Copyright Act and the Patent Act, which are both federal statutes, the protection of trade secrets is governed by state law.152 One major source of trade secret law is the Uniform Trade Secrets Act (UTSA), which, in one form or another, has been adopted by 33 states and the District of Columbia.153 Section 1(4) of the UTSA defines the concept of "trade secret" as "information, including a formula, pattern, compilation, program, device, method, technique, or process that: (i) derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by, other persons who can obtain economic value from its disclosure or use, and (ii) is the subject of efforts that are reasonable under the circumstances to maintain its secrecy" (emphasis added).154 In those states that have not adopted the UTSA, trade secret law is governed by the common law.155 The common law and the provisions of the UTSA have been compiled in the Third Restatement of Unfair Competition (the "Restatement"), which, although essentially a private commentary, provides valuable guidance to courts and practitioners with respect to the application of trade secret law.156 Section 39 of the Restatement defines the term "trade secret" as "any information that can be used in the operation of a business or other enterprise and that is sufficiently valuable and secret to afford an actual or potential economic advantage over others" (emphasis added).157 Although the UTSA and the Restatement provide largely similar definitions, the latter omits the requirement that the holder of a trade secret make efforts that are reasonable under the circumstances to maintain the secrecy of the information. Despite the slightly different wording, however, as a practical matter, the respective scopes of the two definitions are virtually identical.158 This is demonstrated by the fact that, on one hand, the American Law Institute (the "ALI"), which is responsible for the Restatement, considers the efforts made by the holder of a piece of information relevant to the determination of whether the information is valuable and secret.159 On the other hand, the UTSA demands only "reasonable" efforts by the holder to keep the information secret, suggesting that there may be circumstances in which no such efforts are required at all.

¶39

Trade secret law protects any information that is secret, has economic value and is reasonably shielded from public access. The UTSA's definition expressly mentions formulas, compilations of data, and computer programs as protectable subject-matter. As far as the common law is concerned, it is equally well-established that software is eligible for trade secret protection.160 Despite the applicability in principle of trade secret law to software, it is nevertheless useful to consider the legal status of its various elements separately.

¶40

Algorithms and source code are generally both valuable and subject to reasonable secrecy efforts. Therefore, unless a specific algorithm or piece of source code is generally known or readily ascertainable it qualifies as a trade secret, under both the UTSA and the Restatement.161 An algorithm is generally known or readily ascertainable, in particular, if it is discussed in the standard literature on computer programming or is otherwise known in the software industry.162 Even if certain elements of an algorithm or a piece of source code are in the public domain, however, a combination of these elements may amount to a trade secret if it integrates them in a way that is not generally known.163

¶41

A different question is whether object code qualifies for trade secret protection as well. Under special regulations promulgated by the Department of Defense164 that offer trade secret-like protection for products developed by private manufacturers under federal defense contracts, the term "computer software" is defined as including "computer programs, source code, source code listings, object code listings, . . . . "165 Because the scope of these regulations is limited to the defense sector, however, the definition is not directly relevant to trade secret law. Among the various criteria provided by the UTSA and the Restatement, the principal question is whether object code is to be considered secret. Unfortunately, neither the UTSA nor the Restatement provide much guidance as to what secrecy means. Courts uniformly have held object code eligible for trade secret protection.166 This qualification is obvious with respect to object code that a software manufacturer does not disseminate as a product but instead commercializes on a client-server basis, that is, without letting its customers download the code.167 Whether the same applies to object code that is made available to the public is a different question. In light of the UTSA and the Restatement, the answer ought to be that, as soon as the object code of a piece of software is released to the public, it is no longer confidential and thus cannot be considered a trade secret. In rebuttal, one might argue that although the object code of such software is publicly available, consumers ordinarily do not study the series of zeroes and ones of which it consists, and therefore, it is not "generally known" within the meaning of trade secret law. Even if one were to accept this argument, however, object code would still have to be considered "readily ascertainable by proper means," because consumers undoubtedly could, if they wanted to, access the information contained in it. Another argument that one might make to rebut the assertion that object code is not secret would be to say that object code consists of machine language instructions, which, as discussed, are unintelligible to human beings. Therefore, one might argue, even though object code may be publicly available in the sense that consumers can access it, they cannot understand the information that it represents. And yet, while tempting, the suggestion that the secrecy condition should be interpreted as containing an implied intelligibility criterion obscures the issue. The reason is that object code contains two types of information, each of which is unintelligible in a different sense. First, object code is itself information. By that, I mean the above-mentioned sequence of zeroes and ones that define the instructions which computers execute when they run software. While this information is unintelligible to human beings in the sense that they cannot understand it, it is also impossible to make it more intelligible to humans without corrupting it, that is, without making it incomprehensible for computers and thereby destroying the purpose that it is intended to serve. As a result, the instructions of which object code consists should not be regarded as trade secrets. In addition to being information itself, however, object code also contains a variety of information on the underlying algorithms, data structures and source code from which it is derived. By this, I mean the multitude of information that may result if one successfully reverse engineers software. The way in which this information is represented in object code is unintelligible to human beings as well, but unintelligible in a different sense. Unlike the sequence of binary digits of which object code is made up, it is certainly possible to represent the information on the underlying source code and algorithms in a more intelligible manner. Therefore, if anything, only these aspects of object code should be considered confidential. Even the latter type of information, however, would fail to meet the further eligibility criteria laid down in the UTSA and the Restatement. For example, any "economic value" that object may have stems primarily from its functionality, and much less, if at all, from the fact that it is impossible for people to decipher it.168 Hence, the conclusion is that unlike source code, object code is not eligible for trade secret protection.169

¶42

From the perspective of software developers, trade secret law offers both advantages and disadvantages. Its most obvious disadvantage is the restricted scope of its entitlements. While patent law offers absolute protection and copyright law protects software developers at least against copying, which is the activity to which they are most vulnerable, trade secret law prohibits third parties only from ferreting out proprietary information by improper means, such as industrial espionage. It proscribes neither independent development nor reverse engineering.170 In the words of one commentator, reverse engineering is the "the process of working backward to determine the nature of a product or service, or the method used to produce it, by examining, dissecting, or analyzing the product or service itself."171 Trade secret law does not consider reverse engineering object code an improper means of obtaining access to the underlying source code provided that three conditions are satisfied: First, the object code must have been obtained lawfully. Second, the reverse engineering must be carried out for a legitimate purpose (such as to make another computer program interoperable with the software whose object code is being reverse engineered). Finally, the person carrying out the reverse engineering must have no alternative means of accessing the source code. It should be noted, however, that, while the abstract possibility of reverse engineering looms over holders of trade secrets generally,172 it does not constitute a significant limitation of the legal position of software developers. For not only is decompiling software, as discussed, a rather futile undertaking, the amount of information that may be obtained by reverse engineering the object code of a piece of software is unlikely to be enough to enable competitors to reconstruct the software's original source code.173 As a practical matter, therefore, the fact that trade secret law does not prohibit the reverse engineering of software would not seem to expose software companies to competitive threats.

¶43

The relatively narrow entitlements of trade secret law are somewhat offset by its extremely broad scope. While copyright law protects only the way in which ideas are expressed and patent law applies only to the embodiment of ideas in products, processes, compositions of matter and improvements thereof, trade secret law is the only prong of intellectual property law that protects abstract ideas as well. For software companies, this means that, the Third Circuit's rather unfortunate decision in Whelan174 and the CAFC's doctrinally problematic holding in State Street Bank175 notwithstanding, trade secret law is the only type of intellectual property protection that they may invoke to protect algorithms in the abstract. A further advantage of trade secret protection is that it is not limited in time. Unless leaked to the public or otherwise disclosed, a trade secret benefits forever from legal protection. This feature of trade secret law gives software developers the assurance that by taking adequate steps to preserve the secrecy of the algorithms and source code of their programs, they may perpetuate any competitive advantage that their code may confer on them. In summary, one might say that, while trade secret law does not apply to object code and while the amount of legal protection that it affords source code is limited, it does not require that software producers afford the public factual access.

 

C. Assessment

¶44

The discussion so far leads to three insights: Most importantly, as we will see in a moment, it suggests a possible reason why the open source concept, which we will take a closer look at in Part II, has fallen on such fertile ground in legal academia. But let us deal with the more obvious insights first. The immediate lesson of our survey of the currently applicable law is that software is eligible for patent, copyright and trade secret protection.

¶45

The second insight that we gained is that, as far as patent law is concerned, there are certain concerns that the way in which the PTO and the CAFC currently apply it to software may hamper, rather than promote progress and innovation in the software industry. As discussed, further research will be necessary to determine whether these concerns have merit. If they do, slight changes to the applicable law should be sufficient to alleviate the issue. In fact, all that courts would have to do is cut back the current excesses of the CAFC's jurisprudence with respect to software patents.176 This could be done in three ways. One (albeit radical) way would be to abolish software patents altogether, either in an international treaty, a statute or a Supreme Court decision that clarifies that software does not constitute patentable subject-matter.177 This approach may be cleanest solution to the problem if it turns out that patents deter rather than encourage innovation in the software industry.178 Although preliminary evidence suggests that patent protection may be inappropriate for software, the precise economic impact of software patents remains subject to further research. At this point, the evidence is arguably not sufficiently compelling to warrant the abolishment of software patents. Furthermore, a step as radical as the exemption of software from the scope of patent law would require a political mandate that currently is unlikely to exist. As a result, changing patent law to exempt software is at best a long-term option. An alternative advocated by supporters of the open source movement would consist in continuing to recognize software patents but to deny patentees enforcement of their patents against open source software that relies on patented technology. The problem with this option, however, is that it would unfairly disadvantage developers of proprietary software in situations where open source and proprietary software are in direct competition with each other. Since the purpose of the patent system is to encourage investments in research and development, a software company's expectation of receiving legal protection is as worthy of protection when its products compete with proprietary software as when they compete with open source software. Therefore, the arguably least drastic short-term solution to the perceived problems would be simply to adjust the way in which patent law is currently applied to software.

¶46

If government decided to go down this road, three changes might be made, none of which would constitute a radical interference with the current setup of the patent system. First, the scope of patentable subject-matter could be construed consistently with the guidelines established by the Supreme Court.179 Under this option, algorithms in the abstract--that is, algorithms that are not part of a tangible product, process, or composition of matter--should not be considered eligible for patent protection even if, as in State Street Bank or Excel Communications, they lead to useful results. A retraction of the principles developed by the CAFC would resolve many of the perceived problems currently attributed to software patents. Second, the nonobviousness threshold could be raised significantly. Currently, the PTO issues patents for innovations in software development that even hobbyist programmers consider obvious.180 The lenience applied by the PTO in examining prior art is at least partly owing to the fact that software development is a global and extremely fast-paced process, which makes it hard for anyone, but especially for administrative agencies, to keep track of all new innovations. In addition to technology evolving at an ever-increasing pace, the number of patent applications has increased dramatically as well. In 1999, the department of the PTO responsible for software patents processed 2,658 patent applications.181 Without perfect knowledge of the current state of technology, it is virtually impossible to make informed judgments on whether or not a particular algorithm is obvious in light of prior art.182 To address this issue, it may be enough to increase the PTO's staffing, to make sure that its employees receive adequate training, and to provide them with powerful, constantly updated databases.183 In addition, Congress might consider introducing adversarial elements in the patent application process, thereby shifting the burden of undertaking a prior art search away from the PTO and onto the industry. Furthermore, in light of the empirical evidence discussed, which seems to suggest that broad software patents may be less apt to promote progress in the software industry than narrow ones, it may be advisable to use a higher nonobviousness hurdle for software patents than for other types of utility patents. Finally, and independently of the foregoing, to account for the fact that the life of most software is much less than the term of a utility patent, the government might create a special term for software patents of anywhere between five and seven years.

¶47

A third insight resulting from our discussion concerns copyright law. This insight is particularly important for our discussion because it suggests a possible explanation why the open source movement may have seemed so attractive to many members of legal academia. At first glance, one might get the impression that the application of copyright law to software is inherently inconsistent in at least two respects. The first apparent inconsistency concerns the way in which copyright law treats software in relation to other works of authorship. As we have seen, while copyright law usually treats translations of a literary work as derivatives of the original, it is necessary to consider source code and object code as part of the same work in order to arrive at practicable results. A related inconsistency results from the fact that software developers have an incentive to keep their algorithms and source code secret and at the same time to retain as exclusive as possible control over their object code. The law accommodates this incentive by allowing software developers to invoke trade secret protection for their source code, algorithms, data structures, and any other valuable information that may be contained in their software and to combine it with copyright protection for their object code. The reason why a casual observer might consider the concurrent applicability of copyright and trade secret law to software to be inconsistent is that it seems to provide software developers with a shield of legal protection that is significantly greater than that which is available to authors of other types of creations. The unique characteristics of software and the special relationship between source code and object code discussed earlier184 eliminate several of the limitations that legislatures and courts have by default built into trade secret and copyright law. The most significant limitation of trade secret law, that it offers no protection against reverse engineering, is eliminated by the fact that in practice it is virtually impossible to access source code by reverse engineering object code. Copyright law has two built-in limitations, but again, neither is particularly relevant for software. The fact that copyright law does not protect software developers against third parties who independently develop substantially similar or even exactly the same code exposes them to virtually no threats because the abstract ideas underlying their programs are usually kept secret, which, all else being equal, makes independent development less likely than it would be if, as in the case of other works, these ideas were freely accessible. The other drawback of copyright protection, its limited term, is equally irrelevant with respect to software since even the minimum term of protection exceeds the life of virtually any piece of software by at least several decades. The possibility of software developers to use the respective benefits of copyright and trade secret law to eliminate each other's drawbacks brings the resulting level of protection in proximity to that offered by patent law.185

¶48

The second ostensible inconsistency relates to the way in which copyright law protects software in comparison with patent and trade secret law. To see why an observer might consider this relationship to be inherently inconsistent, one has to understand that currently applicable intellectual property law is characterized by a sliding scale that reaches from trade secret law at one end to patent law at the other and that appears to link the amount of legal protection available to creators for commercial applications of their ideas with their willingness to make the underlying abstract elements available to the public.

¶49

At one end of this scale is trade secret law. As we have seen, to qualify as trade secrets, abstract ideas must be both secret and subject to reasonable concealment efforts by their holders. By definition, then, creators who meet the eligibility threshold for trade secret protection are not willing to afford the public access to their ideas. To be sure, there may still be lawful ways for the public to unearth these ideas but if so, then despite the creators' efforts, not as a result of them. In return, as we have seen, trade secret law protects creators only against certain improper ways of getting access to their ideas, but it does not afford them protection for the ideas themselves or for commercial applications of these ideas. On the contrary, as discussed, it even endorses legitimate efforts aimed at revealing information protected as trade secrets.186 As a result, a creator who has an idea and reduces it to a commercial application cannot rely on trade secret law to prevent third parties from obtaining access to the idea (with legitimate means), imitating the application, and using it to compete with the creator.

¶50

If trade secret law reluctantly protects creators who are unwilling to share their ideas with the public, it enthusiastically embraces those who voluntarily disclose them. As discussed, an inventor applying for a patent is required to describe its invention to the patent examiner in a sufficiently detailed manner so as to enable someone "skilled in the art" to reduce the invention to practice without undue experimentation. If the PTO ultimately issues a patent, the description provided by the inventor is publicized. The amount of publicly available information on the abstract ideas underlying patented inventions is thus infinitely greater than in the case of trade secrets. In return, the entitlements associated with patents reach much further than those granted for trade secrets. During the life of a patent, nobody--not even third parties who independently create the same abstract idea and independently reduce it to practice--are allowed to use the patented invention. Working together, the different levels of protection afforded by patent and trade secret law create an incentive for inventors who wish to commercialize their ideas to apply for a patent, thereby making the underlying abstract elements publicly available.

¶51

Last, but not least, there is copyright law. While the way in which copyright law follows the disclosure/protection tradeoff of patent and trade secret law is less obvious, it equally fits in with the sliding scale described. Copyright law may not encourage authors to disclose the abstract elements of their ideas in the same way that patent and trade secret law do, which offer only weak protection for authors who keep the intellectual substance of their works confidential, and strong protection for those who disclose it. There is admittedly no mechanism in copyright law capable of distinguishing between these two cases. The absence of such a mechanism, however, does not mean that copyright law is indifferent as to the question of whether the public should have factual access to the abstract ideas underlying concrete expressions of ideas. On the contrary, it clearly favors access over control. What is different, however, is that rules encouraging or even requiring authors to disclose their ideas are usually not necessary to achieve disclosure.

¶52

The reason is that traditional works are subject to what one might call a mechanism of "inevitable disclosure" that forces authors who would like to commercialize their works to disclose the works' underlying abstract ideas. This insight is similar to that of Learned Hand's levels of abstraction test,187 which we discussed earlier, according to which any expression of an idea may be analyzed as a series of abstractions of increasing generality. Every layer of this series of abstractions contains information on the more general or more abstract elements on which it is based. This information may not always be obvious at first glance, but by analyzing an expression carefully enough, one will eventually unearth the abstract ideas on which it is based. For example, every narrative contains a host of information on the underlying plot and structure of the story, and by analyzing the narrative, one may gain an understanding of the plot and fathom its structure. Similarly, a piece of sheet music contains information on the genre, structure, tunes, harmonies, and rhythms of the piece. Because concrete expression and abstract idea, while conceptually distinct, are intrinsically linked with each other in such a way that any expression inevitably reveals information concerning the underlying ideas, it is impossible for authors to disseminate their works to the public without giving away the abstract ideas on which they are based. Readers, for example, can read and thereby enjoy a book only if its words and structure are made available to them; music can be enjoyed only if the listener is exposed to its tunes, harmonies and rhythms. This is what I mean by inevitable disclosure.

¶53

If copyright law were concerned that the inevitable disclosure mechanism unfairly jeopardizes the competitive position of an author vis-à-vis third parties, it presumably would prohibit third parties from using the abstract ideas underlying a copyrighted work as inspiration for new works of their own at least for a certain period of time. Protection against this threat could be achieved by affording copyright owners similarly far-reaching entitlements as patent law affords patentees. Significantly, however, copyright law does not do this. Instead of prohibiting the commercial exploitation of abstract ideas underlying protected expressions, it "encourages others to build freely upon the ideas and information conveyed by a work" (emphasis added).188 The absence of any such prohibition may be read as an endorsement by copyright law of the inevitable disclosure mechanism.

¶54

The notion of a disclosure/protection tradeoff that links all areas of intellectual property law and of which the inevitable disclosure mechanism of copyright law forms an integral part explains why one might, at first glance, perceive the application of copyright law to software as being inconsistent. The reason is once again rooted in the distinction between source code and object code. As we have seen, in order to commercialize a program, software developers have to disclose only the program's object code, but not its source code, which is, as we have seen, the only manifestation of the software that contains the underlying abstract ideas in a form that is intelligible to human beings. This unique characteristic of software is irrelevant as far as trade secret law and patent law are concerned. For trade secret and patent law implement the disclosure/protection tradeoff by means of an explicit deal. Strong (patent) protection is available only when a creator affirmatively discloses the abstract ideas underlying its creation in a form that is intelligible to human beings. Weak (trade secret) protection is the norm when these ideas are kept secret. In the case of copyright law, however, the aforesaid tradeoff is implicit, not explicit. Unlike patent and trade secret law, however, copyright law does not require that anything be disclosed as a precondition for the grant of protection. Instead, as discussed, it relies on an inevitable disclosure mechanism. Yet, software is not subject to that mechanism. While the abstract ideas underlying a piece of software are embodied both in its source code and in its object code, only the source code version represents them in a way that is understandable to humans. At the same time, virtually all of a program's commercial value rests in its object code.189 Therefore, the exploitation of a piece of software does not require software developers to disclose the underlying abstract ideas.

¶55

The reason why I have spent so much time on developing the inconsistency theme is that I believe that the aforesaid perceived inconsistencies in the application of copyright law to software are the main reason that have made members of legal academia susceptible to the open source concept. To supporters of this concept, the defiance by open code of all legal protection for software promises an internally consistent alternative to the currently applicable legal framework. On closer reflection, however, we will see that in practice the open source philosophy does not constitute a viable basis for the legal protection of software (see Part II) and that the ostensible inconsistencies described in this section are in fact no inconsistencies at all (see Part III). The Article concludes that the currently applicable legal framework is a sound approach to the regulation of software.

 

II. Open Code--A Viable Alternative?

BACK TO TOP | TABLE OF CONTENTS

 

A. The Open Source Movement

¶56

The purpose of this section is to discuss the open source movement, whose vision of how the law should apply to software is diametrically opposed to the legal framework currently in place.190 Ideally, open source advocates argue, software should not be subject to legal protection at all, or, in open source terminology, software should be free or "open." At the outset, it should be noted that open source advocates are for the most part software developers with no legal background. Only recently have they been joined by legal academics, such as especially Larry Lessig. As a result, it is not surprising that supporters of open source software frequently take a very different approach to the policy issues surrounding the legal protection of software than lawyers. Another noteworthy observation is that while open source software developers are the fiercest opponents to intellectual property law, they are the ones whom intellectual property law is designed to protect. This is especially interesting in comparison with the MP3 discussion where it is consumers, not producers who are the ones who are most skeptical of affording intellectual creations legal protection. The issue that I will address in the following is whether the open source philosophy is a viable alternative to the current legal framework governing software. As we will see, I believe that it is not. Nevertheless, it would be unscholarly to attempt to answer this question without first listening to and evaluating the arguments made by those who are most familiar with the subject-matter being regulated.

¶57

Perhaps the easiest way to explain the concept of "open source software" is by contrasting it with proprietary software, that is, software whose developers rely on intellectual property law for their protection.191 Proprietary software generally has two characteristics: first, it is subject to licenses that define among other things whether, and subject to what conditions, licensees may use, distribute, and modify the software; second, as discussed, only its object code is publicly available, whereas its source code is kept confidential by its owner.192 Open source software, by contrast, may be used, distributed, and modified freely (subject to the only restriction that secondary distributions of the software be subject to no greater restrictions). Moreover, the source code of open source software is freely accessible by the public.193 While members of the open source movement, for reasons discussed below, often mention these two characteristics of open source software in one breath,194 they are not the same, and, as a conceptual matter, it is important to keep them separate. On one hand, then, the term "open" as applied to software means software that is subject to virtually no legal restrictions (the "restriction" that subsequent distributions not be subjected to greater restrictions does not count since it is necessary to perpetuate the initial freedoms); for lack of a better term, I will call this type of openness "legal openness." On the other hand, it means software whose source code is freely accessible by the public, meaning software whose source code the public is able to access and view without any restrictions, regardless of whether, from a legal perspective, the public is also entitled to use the source code for certain purposes; I will refer to this second aspect of openness as "factual openness."

¶58

Before analyzing these two conceptions of "openness" in greater depth, it is helpful to explore the context in which they have evolved. The open source movement has its roots in the hacker195 communities that developed parallel to the emergence of modern computers. While the movement's exact origins are difficult to pin down,196 its direct precursor are the various communities of software developers that worked at the three hotbeds of computer science in the 1960s: the University of California at Berkeley, Xerox's Palo Alto Research Center, and the Massachusetts Institute of Technology. To get a better idea of the state of computer technology around that time, it is helpful to consider a couple of reference points. In 1961, MIT purchased a computer called PDP-1.197 Microcomputers, by contrast, such as the Apple II in the United States or the C-64 in Europe, PCs, or even laptops, had yet to be invented, and commercial software companies did not exist. Among hackers, it was common practice to share and exchange the source code of all software that they developed. The term "community," which is still the predominant expression that open source software developers use to refer to each other, reflects the fact that in the early days, there used to be only a limited number of hackers who developed software in a cooperative manner. From today's perspective, it may seem astounding that hackers did not invoke copyright, patent, or trade secret law to protect their respective code. At the time, however, there was no market for software, and so there was nothing to be gained by individual programmers from excluding the community from access to their respective code. Furthermore, computer science was much more tightly connected with other academic fields such as mathematics and physics, and the principal motivation for becoming a hacker was scientific curiosity, not the desire to make money or to use code as a means of shaping society.198

¶59

Around 1980, however, things changed. Maybe the most significant event of the early 1980s from a cultural perspective was Commodore's release of the C-64, which quickly became the flagship of the microcomputer revolution and suddenly created a tremendous market for commercial software. Commercial enterprises equally became interested in using computers as a means of streamlining their internal processes, and a number of startup ventures set out to embrace this host of new opportunities.199 Similarly to the dot-com revolution about 15 years later, the gold rush signaled by the arrival of the microcomputer drained universities of qualified staff, and numerous skilled software developers who had grown up in the hacker community left academia to found their own companies.200 For a brief moment, it looked like the hacker cult might not survive the onset of commercial software, as the temptations for programmers to make money on their skills might be too great. But when the dust settled, the open source movement as we know it today had surfaced.

¶60	If one person deserves to be called the father of the open source movement, it is Richard Stallman, who worked at MIT's Artifical Intelligence Lab since 1971 and followed the commercialization of s