Fordham Intellectual Property, Media & Entertainment Law Journal
Copyright (c) 2000 Fordham Intellectual Property, Media & Entertainment Law Journal

Spring, 2000; 10 Fordham I. P., Media & Ent. L.J. 619


Open Source Software: The Success of an Alternative Intellectual Property Incentive Paradigm

Marcus Maher
[Associate, Wiley, Rein & Fielding, J.D., Harvard Law School. The views expressed in the article are entirely those of the author. The author thanks Prof. Lawrence Lessig for helpful comments and criticism.]


[*619]  Introduction

Intellectual property protection in the United States is based on an incentive system.  n1 The protections provided by intellectual property law are designed to produce economic incentives to "promote the progress of science and useful arts."  n2 The open source software movement, which has gained publicity as the popularity of the Linux operating system has grown, provides an alternative to the economic incentives that dominate the thinking of U.S. intellectual property policy. Product comparisons show that open source software attains high technical standards despite the relative absence of economic motivation for the creators of this software. This technical success is all the more puzzling to the traditional computer community, given the distributed, almost ad hoc, development methodologies employed by the open source movement. This article shows how the science of complexity theory is able to explain the open source movement's ability to translate  [*620]  non-economic incentive mechanisms into a process for technological development and innovation.
This paper will begin to address this quandary by providing a factual introduction into the details of the open source development process...

* * * * *

I. Overview of Open Source Software Development

The open source software development process has been described as similar in nature to the familiar methods of research in the scientific community.  n3 Key to the scientific method are the principles of discovery and justification. Justification of scientific discoveries comes from peer review. This review is only possible if the discovery process is shared - the hypothesis, the experiment, the analysis, et cetera. The sharing of ideas allows not only vindication of the initial results, but information upon which other scientists can build, allowing advancement of the state of knowledge and the strengthening of existing theories.  n4
Open source methods could be seen, in part, as the scientific method at work in the computer science community. As will be seen, however, the reality is more complicated. The principles of both discovery and justification play extremely important roles in delineating the bounds of activity in the open source community.
[*621] 

A. Open Source Examples

Before describing the development process, it is useful to have a basic understanding of a few of the more prominent programs and packages that have been developed through the open source process.

1. Apache

Apache began as an effort to address problems that were perceived in the NCSA httpd web server.  n5 The Apache has been the most popular web server since April, 1996 and today is more widely used than all other web servers combined.  n6 The advantages of Apache include the fact that it is free (as in costless), that it is free (as in open source), and that it provides high quality performance.  n7

2. BIND

The Berkeley Internet Name Domain package (BIND) is the software that provides domain name service (DNS)  n8 for the vast majority of name serving machines on the Internet. BIND was originally developed at Berkeley under a grant from the Defense Advanced Research Projects Agency (DARPA)  n9. However, the development and maintenance of BIND has been taken over by the Internet Software Consortium (ISC).  n10

[*622]  3. Linux (GNU/Linux)  n11

Linux is a Unix-like operating system. It is not, however, a version of Unix, based on a version of Unix from the basic AT&T Unix sourcecode, or a derivative thereof.  n12 It was intentionally modeled after Unix to make it convenient for others to adopt,  n13 and because it had been proven to be portable.  n14 Beginning in 1984, the GNU Project worked to create the elements of a complete operating system.  n15 By the early 1990s the only substantial operating system element remaining to be developed, was the kernel.  n16
The Linux kernel started as the hobby of Linus Torvalds, a Finnish computer science student, in part to teach him about his new 386 computer.  n17 He started with the "Minix" kernel, a kernel created by a computer science professor for educational use. Torvalds eventually rewrote the entire kernel, creating the foundation for the Linux kernel. After the kernel was mentioned on a Minix newsgroup, he was provided the opportunity to distribute the kernel publicly on an FTP server.  n18
The Linux kernel was the final element needed for the operating system. With some effort, the kernel and existing GNU programs were integrated into a functioning operating system.  n19 The  [*623]  operating system grew and expanded through the open source processes to be discussed, eventually growing into a complete operating system package that is available, both freely, and as a part of a commercial distribution. Although estimates are difficult to pin down accurately, a good estimate for the number of current users of Linux is about 7.5 million.  n20
Linux is the open source project that has probably undergone the greatest number of publicized tests, reviews and comparisons. These have consistently shown Linux to be of superior technical quality, performing equal to, or better than, most of the products with which it is compared.  n21

4. Mozilla

Mozilla is the open source version of Netscape's Communicator. On January 23, 1998, Netscape announced that, in addition to giving away its Communicator product, its previously closed-  [*624]  source Communicator software was going to become open source.  n22 Not long after the source code was made available, a group of developers added 128-bit encryption capabilities, releasing a "Cryptozilla" product.  n23 Netscape's official Communicator version 5.0 incorporated modifications suggested by open source contributors.  n24

5. Perl

Perl is a programming language that has become one of the most popular languages for Web page development, Internet services, graphical programming and many other purposes.  n25 Perl "is the engine behind most of the "live content' on the Web."  n26

6. Sendmail

Sendmail is a utility that routes about 80% of the e-mail on the Internet.  n27

B. Initial Stages of Open Source Development

Any open source project begins with the desire of a developer to meet some currently unfulfilled or inadequately fulfilled need. As one commentator artfully wrote, "every good work of software starts by scratching a developer's personal itch."  n28 To put the point more generally, this desire also accounts for programs that meet some need recognized by the programmer, even if that need  [*625]  is not one the programmer experiences personally.  n29
Further, "good programmers know what to write. Great ones know what to rewrite (and reuse)."  n30 In the open source community, where the source code for existing programs is available, developers are more likely to reuse this code in developing new programs. When a substantial amount of open source software exists, there is an excellent chance of finding code that can be modified to meet a particular need. This eliminates the necessity of inefficiently reinventing the wheel.
Reusing existing code does not mean that open source software developers escape the trial and error process.  n31 As Eric Raymond put it, "you often don't really understand the problem until after the first time you implement a solution.... So if you want to get it right, be ready to start over at least once."  n32 This process can come in several forms. First, it may be the case that a new piece of software is in the process of being created using some code from an existing program when a program that would provide a better basis for modification is found.  n33 Second, an existing program may provide an initial framework for development; a framework that is eventually replaced as the project progresses.  n34 Finally, subparts of a larger project may have several prototypes developed, with only one (or parts of several) chosen for ultimate refinement through the open source process and inclusion in the larger project.  n35

[*626]  C. Review by the Open Source Community

There are several stages to the peer review process that are part of the success of the open source model. These stages include attaining technical prerequisites before soliciting feedback and developing a base of users/developers. This user base must then be encouraged to maintain an active role in the program's development. This is accomplished in part through the exercise of the traits necessary for project leadership.

1. Technical Prerequisites

Prior to submission to the open source community, a piece of code must attain a minimal level of technical development.  n36 Once sufficient development has occurred, the software is sufficiently advanced to undergo community review. A second technical prerequisite is a means of handling communication with contributors. Contributors to an open source program are often geographically dispersed. For larger or more successful projects, the contributors may also be substantial in number.  n37 Use of modern communication technologies - project web pages, mailing lists, newsgroups, et cetera - are necessary to facilitate the desired peer feedback that is at the heart of the open source process. In short, the growth of the Internet and Internet technologies has made the open source method possible.  n38 Finally, the technology to engage in debugging and development must be available to the user for them to contribute. In the case of the Linux OS, for example, the act of installing  [*627]  the debugging and development environment is implicit to the act of installing the operating system.  n39 Thus, participation by Linux users in open source software development is facilitated by the common use of GNU tools for development used in the open source community.  n40

2. Obtaining Peer Review

Initially obtaining peer review is an important issue in itself. There are two principle ways to garner community involvement. The first is to take over ownership of a relevant existing program and make use of the existing user/developer base. The second possibility is to start a new project and solicit support from the open source community generally.
The easiest way to get peer review of a program is to take over an existing open source project which will serve as a basis for modification. The first way to do this "is to have ownership of the project handed to you by the previous owner (this is sometimes known as "passing the baton')."  n41 The owner of a project is seen as having a duty to pass on the ownership of a project that he or she no longer is able to or wishes to maintain.  n42 Alternatively, ownership of an existing project may be obtained if the project needs work and the owner no longer maintains the project. In conformance with community norms, the would-be successor must first attempt to find the owner. Then it is appropriate to announce ownership of the project in as many relevant forums as possible, allowing substantial time to pass. If anyone claims to have been working on the project during this period of time, their claim will have priority. If no one makes such a claim, the successor may take over the project, and the existing user/developer base that accrues to the project's new owner.  n43 Ownership of the project provides access to the existing userbase from whom it is possible to  [*628]  solicit feedback and development effort regarding any changes in the code.
The process of creating a new project can be difficult, particularly in the beginning. Brian Behlendorf, co-founder of the Apache Group, detailed the resource requirements necessary to start an open source project. There must be a project "captain" who oversees any changes to the code, fixes incompatibilities in contributions and in general "has overall responsibility for the quality of the implemented code."  n44 Someone must perform "infrastructure support," maintaining mailing lists, the web server, bug database and other resources. In addition, there must be maintenance of the bug database - receiving reports about bugs, and responding to valid bug issues. The project must also be documented, which means not only providing explanations of the project and its current status, but also maintaining the Web site.  n45 Someone also needs to "build momentum" for the project among other developers and users who will try the project and make peer-review contributions.  n46 In addition to these roles, it is necessary to have people who can work on the development of the code until users join the project.  n47

3. Converting User Base Into Developers

Once there is a user base for a program, the open source process takes advantage of these users for program development.  n48 Specifically, these users are sources, not only of feedback regarding  [*629]  flaws or shortcomings in the program, but sources of solutions for these problems. In highly planned, hierarchical development approaches, finding and fixing bugs is a long and arduous process, taking "months of scrutiny by a dedicated few."  n49 This necessitates long periods of time between releases and disappointment when bugs remain in these long-awaited products. In contrast, bugs are relatively shallow, and easier to find and solve, in software subjected to the open source approach. Users of open source programs are encouraged to contribute not only identifications of bugs, but potential solutions as well. Thus, bugs are not only identified quickly, but given the abilities of the average open source user, a solution is quickly found.  n50
The ability to fix bugs quickly is analogized to the "Delphi effect" - the fact that the averaged opinion of a group of individuals with equal knowledge is much more reliable than the opinion of one randomly-chosen individual. The open source development process has shown "that the Delphi effect can tame development complexity even at the complexity level of an OS kernel."  n51 While this is due in part to the fact that averaged opinions are more reliable, it is also due to the fact that, although open source software development "requires debuggers to communicate with some coordinating developer, it doesn't require significant coordination between debuggers."  n52 This means that the intricacies and management costs associated with adding more developers to a hierarchical project are minimal in the distributed open source context.  n53
This difference from the structured, hierarchical model also allows much shorter release intervals. Releasing more often yields more corrections, and ultimately results in a high-quality piece of software developed relatively quickly.  n54 This also helps minimize the administrative costs associated with peer-reviewed open source  [*630]  methods. By releasing new versions often and incorporating bug fixes obtained through feedback, the duplicative efforts of debuggers are kept to a minimum.  n55

4. The Role of Leadership

Although the open source model involves much more distributed participation than the traditional, centralized, proprietary software development method, there are important roles for project leaders to play. In addition to handling the logistics of incoming bug reports and bug fixes from users, it is necessary to select among them. Only certain fixes can be implemented, and owners must select among the (potentially) many alternatives to find the solution that will ultimately be used.  n56 However, there is more to the role than just recognizing good ideas. Often, different perspectives yield different characterizations or conceptions of a problem. These different perspectives can be insightful in determining how to fix problems.  n57 Finally, suggestions for code changes may come, not only in the form of patches to fix problems, but code streamlining as well. As Eric Raymond noted, "perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."  n58
A project owner must also resolve disputes arising in the project. The project head has the authority, under open source community norms, to make ultimate design decisions and help keep a group from breaking into multiple branches ("forking").  n59 The issue of giving credit for contribution to a project is a more difficult issue to resolve, but also involves the project owner. Decision-making is easiest if the project is structured according to the "benevolent  [*631]  dictator" model.  n60 This model of ownership consists of a single leader who makes design and group maintenance decisions, and also assigns project credit as constrained by community norms.  n61 In the simplest sense, credit for contribution means ensuring that contributors receive a fair reputational stake in the success or failure of a project. As a project develops, tiers of contributors can arise, consisting of ordinary contributors and co-developers.  n62 The co-developers get greater decision-making power over the conflicts formerly resolved solely by the "dictator." Even further removed from the benevolent dictator model are the leadership committee and rotating dictatorship models. These models involve turning co-developers into a leadership committee, or passing control among co-developers. These models are generally more complicated and less stable than the "benevolent dictator" model.  n63
Several character traits are important for project leaders as well. One important trait, even before substantial development begins, is strong people and communication skills.  n64 These skills are helpful in attracting others to the project, and keeping developers happy so that they enjoy working (typically for free) on the project. Further, a somewhat humble, or at the very least non-egotistical, non-self-promoting, individual is necessary, given the community norms. This not only provides confidence in the project leader's ability to evaluate the work of contributors, but helps assure that participants are able to claim for themselves the prestige that they are entitled to - a critical element for participation.  n65

D. Open Source Culture

The discussion of "user-developers," taken alone, neglects an important characteristic of the open source community that facilitates  [*632]  participation. A user base must be converted from mere users to active contributors to the code development. Possibly the prime factor which leads to participation in the open source development process is the so-called "gift culture" factor.  n66 "In gift cultures, social status is determined not by what you control but by what you give away."  n67 There are several particular reasons why community reputation may lead to participation. The strongest reward is the pleasure of the good reputation itself.  n68 Prestige within the open source community may allow a programmer to more readily persuade others to join projects owned by such a person, or to place particular value on that person's input.  n69 To a lesser extent, the prestige of a developer in the open source community may also spill over to the exchange economy, placing them in higher demand within that market. While the gift-culture idea may be counter-intuitive to many businesses, it has been used to explain philanthropy and donation of resources in general.  n70 Indeed, following from the analogies to philanthropy, it is reasonable to expect that open source participants' identities in their own eyes and the eyes of others may to come from their role in open source projects.  n71
[*633]  Open source social ownership customs  n72 provide a background in which esteem may be granted or withheld in a manner that supports the open source community. Ownership in the open source context means "having the exclusive right, recognized by the community at large, to re-distribute modified versions [of a program]."  n73 This idea is in tension with the ideology of the open source movement, as expressed in licensing terms; namely, the idea that the source code should be available to be freely modifiable by anyone.  n74
Another indication of why users may become developers comes from what draws many users to open source software in the first place. Specifically, the control over the code that open source software allows users has significant appeal. Thus, many of the users that are drawn to open source software are drawn by the prospect of being able to make their own changes to the code.  n75  [*634]  Coupled with this is the interaction between project owners and users, which can facilitate turning users into user-developers. Examples from open source projects indicate that a combination of encouraging participation among users, specifically soliciting comments regarding design decisions, implementing suggested changes and praising users when they provide patches and feedback, leads to further participation.  n76 These can help encourage users, who may already be inclined to make improvements to the code, to resubmit these improvements to the project.
The norm against explicitly egotistical behavior,  n77 which would appear to be inconsistent with the role esteem-seeking plays in the open source community, may actually help drive participants to a higher standard of contribution.  n78 The norm helps assure that "one's work is one's statement."  n79 This, in turn, ensures that the participants are driven toward a high level of performance, because rewards only come from a peer determination of program quality. Further, because code from self-promoting individuals is not rewarded, such "noise" is filtered out of the open source development discourse.  n80 Finally, self aggrandizement is inconsistent with the quality of intelligent selection of code, necessary for a good  [*635]  project leader. It is also inconsistent with the proper distribution of esteem by the leader to contributors, necessary for sustained user-developer contributions.  n81 Thus, the norm against such behavior helps strengthen the quality of individual that ultimately leads an open source project.
The pure pleasure of hacking is another reason why individuals contribute to open source projects.  n82 For some people, the enjoyment of programming can be satisfied through open source projects, which, in particular, may allow for greater creativity and experimentation than opportunities in the proprietary software world. A further aspect of this justification for participation comes from the enjoyment of creating a beautiful program, above and beyond any reputational benefits that may come from its creation.  n83 However, this is intimately intertwined with the reputational benefits of the open source system. When contributions consist, not of entire programs, but of particular patches, project leadership, et cetera, it is difficult to evaluate the relative "beauty" of a particular developer's contribution. Thus, the knowledge that a contribution is technically superior comes from the critical review provided by the open source model.  n84
The norms of the open source community can also serve as a hurdle to participation. Such hurdles are of at least three different types. First, there are "password-like" mysteries.  n85 Groups prevent  [*636]  participation by anyone who has not uncovered the mystery.  n86 Second, there is often a requirement of understanding of some particular technical issue. This serves as a proxy for the participant's overall technical ability to contribute to the project.  n87 Finally, through the examples of other hackers working on a project, a new participant is expected to learn both the procedural and social rules and norms that govern behavior.  n88 Such norms play an important role in the control of the open source community by aiding in the acculturation of new members. However, it is important to note that barriers to participation which are not associated with the goals of acculturation or ensuring technical proficiency could have negative consequences.  n89

E. Modularity

Modularity  n90 of code plays an important role in open source development as well. The advantages of modular code include:

1. If a function performed by a module changes, only that module changes and the rest of the program is unaffected.

2. If a new program feature is added, a new module or hierarchy of modules to perform that feature can be added.

3. Program testing and retesting is easier.

[*637]  4. Program errors are easier to locate and correct.

5. Program efficiency is easier to improve.  n91

Thus, modularity can make project leadership a manageable task by making the program easier to maintain.  n92 It allows projects to be divided up into discreet tasks, with programmers working in parallel, yet not creating conflicting changes.  n93 Modularity may also facilitate the borrowing of portions of code, making the code for particular tasks easier to find in old programs.  n94 The program design necessary to allow the insertion of code borrowed for a discreet task will also encourage modular design in the program being created. The discreet, understandable nature of modular code can facilitate peer evaluation. Finally, "the traditional approach for enhancing program quality is modularization."  n95

F. Open Source Licenses

"Open Source lives or dies on copyright law."  n96 The licenses applied to open source software play an important role in whether future versions or changes to the software remain open source. Indeed, the licensing terms of software are critical to the determination of whether it meets the formal "Open Source" definition.  n97  [*638]  There are a number of different types of licenses that are consistent with the requirements of the open source definition.  n98

1. GNU General Public License (GPL)

The GNU GPL is the most well-known and widely used of the open source licenses. An important initial note about the GNU GPL is that it contains not only the licensing terms, but a discussion of the justifications for those terms.  n99 The basic requirements of the GPL are that "enhancements, derivatives, and even code that incorporates GPL'd code are also themselves released as source code under the GPL."  n100 Thus, modifications to GPL software cannot be made closed-source, and no GPL program can be incorporated into a proprietary program.  n101

2. The GNU Library GPL (LGPL)

The LGPL is derived from the GPL for use with software libraries. The primary difference is that "a LGPL-ed program can be incorporated into a proprietary program."  n102 GNU is currently  [*639]  discouraging the use of the LGPL, in favor of the GPL instead.  n103

3. The BSD-style License

Another popular license, the BSD-type license, is used by Apache and BSD-based Unix operating systems. This license has been summed up as stating ""here's this code, do what you like with it, we don't care, just give us credit if you try and sell it.'"  n104 This does allow incorporation of the code in proprietary products, which is seen by some as an advantage for "common" protocols or services.  n105 However, there are also risks because "no incentive is built into the license to encourage companies to contribute their code enhancements back to the project.  n106 The apparently benign requirement that advertising of products including BSD-licensed software must give credit to Berkeley University can become untenable in a large, multi-component distribution, which could require pages of footnotes.  n107

[*640]  4. Mozilla Public License (MPL)

The MPL was the result of dissatisfaction with existing licenses for the particular needs of Netscape and Netscape Communicator. Its development resulted from a consideration of the advantages and benefits of existing license types, comment from the open source community and work by teams of Netscape employees.  n108 Any changes to an MPL distribution must be released under the same copyright as the MPL, making it available back to the project. However, ""distribution' is defined as the files as distributed in the source code," meaning that the files could be incorporated into another, proprietary program.  n109 This license also requires that anyone "contributing code back to the project release any and all claims to patent rights that may be exposed by the code."  n110

5. Netscape Public License (NPL)

The NPL is a Netscape-specific version of the MPL. It grants special privileges to Netscape that do not apply to anyone else. Essentially, it allows Netscape "to take [open source] modifications private, improve them, and refuse to give you the result."  n111

6. Artistic License

The Artistic license was originally developed for Perl, but is currently disfavored as compared to other licenses such as the GPL. The license "prohibits sale of the software, yet allows an aggregate software distribution of more than one program to be sold.  n112 The Artistic license also requires modifications to be made open source, but then provides loopholes for taking releases private, or putting it in the public domain.  n113
[*641] 

G. Important Pre-existing Facilitators of the Open Source Method

There are a number of factors that made the open source development model possible that are not, strictly speaking, part of the development model itself. However, given the important roles these factors play as preconditions of open source success, they are worth consideration.

1. Academia

Given the important role that the culture and norms of the open source community play in the success of open source software, it is important to recognize the role that academia plays in teaching those norms. Richard Stallman, arguably the founder of the modern free software  n114 movement, first experienced this type of community at The Massachusetts Institute of Technology in the 1970s. At the MIT Artificial Intelligence Lab there was a software-sharing community, allowing free use of software and free access to source code for anyone who wanted to use it. Although this culture changed due to commercial influences in the 1980s, the principles Stallman took away from the experience led him to recreate this type of community through the GNU project.  n115 Thus, the free software movement has its roots in the source-sharing culture of the university computer science community. Similarly, the norms and culture of the university setting at large may themselves represent analogous cultural systems to the open source community. The activities of tenured professors, who no longer have concerns about "survival issues," become focused on "reputation enhancement" through intellectual achievement.  n116 This is similar to the behavior of hackers in the open source gift culture.
The university setting continues to be not only a forum for introduction  [*642]  into the norms of open source society, but also a forum for introduction to open source technology. For example, much work on components of Linux and GNU was done by individuals at educational institutions. Open source software is frequently utilized by universities for purposes of computer science education, due in large part to the accessibility of the source code. Use of open source software in the university setting also means that new research ideas are often tried out first in open source software. Finally, universities may facilitate the distribution of open source programs to areas with only marginal Internet penetration.  n117

2. Communications Technologies

The Internet is a technology whose existence was critical for the development of the open source movement. "Open Source has been born into a digital renaissance made possible by the Internet, just as modern science was made possible during the Renaissance by the invention of the printing press."  n118 The economic and physical barriers to software and source code distribution have been lowered by the Internet.  n119 The Internet also brought together hackers in a community, rather than leaving them isolated in small groups.  n120 Finally, the computers and the Internet allow the marginal cost of distributing software or source code to be zero.

3. Standards

Technical standards have played an important role in the ability of open source projects to go forward. Indeed, it is the elimination of open source community access to standards that Microsoft has raised as a primary means of preventing competition from Linux.  n121 "OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized,  [*643]  simple protocols."  n122

H. The Business of Open Source Software

Despite the feeling among some in the community that software should be given away, not sold,  n123 the "business" of open source software dates back to its origins.  n124 For the purposes of this discussion, the business of open source will include efforts to sell open source software, whether done for profit or merely to recover some costs. This business includes both the marketing and sale of pre-existing open source projects, or the "taking open source" of previously proprietary commercial products.
A number of companies have successfully based their business on selling open source software.  n125 Part of what is being sold is simply a convenient aggregation of open source programs. However, many of these companies also provide value beyond this convenient aggregation. For example, traditional models of customer support  n126 may be provided for the programs included in the  [*644]  software package. These businesses may also help to implement changes suggested by their customers for immediate use by the customer in their environment, and perhaps also in future versions of the product. Because it is software whose source code is freely available that is being sold, the open source market is a commodity market.  n127 Brand equity, therefore, is a selling point to a much greater extent than the underlying technology.  n128
Many in the open source community would most naturally point to the reliability and technical superiority of open source software as the primary marketing points.  n129 However, business experience has taught that, while technical excellence is necessary for an open source business's success, it is not sufficient.  n130 Rather, other points must be emphasized in addition to the technical merits in order to be successful. Open source software can be a means of lowering overhead.  n131 Open Source software also may allow the support of a broader range of platforms than would be possible with proprietary software. For example, privately undertaken  [*645]  ports of a program to a new platform will be contributed back to the project, allowing for incorporation into the next version of the product.  n132 Because open source software is a commodity market, competitors may try to offer new features for the software. However, these features can simply be added into future versions of the general program that will be sold by all the business's competitors.  n133 Thus, as long as a dominant company maintains its own high levels of performance, it is unlikely a competitor will be able to beat them merely by offering new software features.  n134 Further, open source software allows a business to maintain close relations with customers, even to the point of "co-opting your customers' engineers to help your development."  n135 This further lowers overhead, but also, by incorporating customer feedback and fixes into rapidly re-released products, allows heightened responsiveness to customer needs.  n136 Implicit in the "co-opting" of a customer's engineers is the idea that customers can make their own modifications when needed. The ability to make needed or desired modifications to a program on their own is an extremely important selling point for many customers.  n137

I. Freedom and Free Software

An important part of the discussion surrounding the open source movement involves the issue of freedom, particularly as it  [*646]  applies to software and intellectual property. The Free Software Foundation, and Richard Stallman in particular, have been the leading proponents of the freedom-enhancing aspects of "copylefted"  n138 software. There are three specific freedoms associated with free software. "First, the freedom to copy the program and give it away to your friends and co-workers; second, the freedom to change the program as you wish, by having full access to source code; third, the freedom to distribute an improved version and thus help build the community."  n139 Free Software supporters argue that "efforts to attract new users into [the free software] community are far outstripping the efforts to teach them the civics of our community."  n140 Thus, the Free Software supporters argue against the use of the term "open source," as diverting the focus of attention away from freedom and "to appeal to executives and business users."  n141

* * * * *

FOOTNOTES:

n1. See Statement of Copyright and Intellectual Property Law Professors in Opposition to H.R. 604, H.R. 2589, and S.505 "The Copyright Term Extension Act"(Submitted to the Committees on the Judiciary United States Senate United States House of Representatives)(last modified Jul. 16, 1999) <http://www.public.asu.edu/<diff>dkarjala/legmats/1998Statement.html>.
n2. U.S. Const. art. I, 8.
n3. See Chris DiBona et al., Introduction, in Open Sources: Voices from the Open Source Revolution 1, 6-7 (Chris Dibona et al. eds., 1999).
n4. See id.
n5. See About the Apache HTTP Server Project (visited Apr. 20, 2000) <http://www.apache.org/ABOUT<uscore>APACHE.html>.
n6. See id.
n7. See id.
n8. See ISC BIND (visited Jan. 27 2000) <http://www.isc.org/products/BIND>
n9. Id.
n10. See ISC BIND (visited Jan. 27 2000) <http://www.isc.org/products/BIND>.
n11. Although this open source operating system is most commonly referred to as "Linux," there have been some recent efforts, in particular by Richard Stallman, to encourage use of the name "GNU/Linux," due to the substantial role of GNU software in the operating system. See Richard Stallman, Linux and the GNU Project, (last modified Jan. 22, 2000) <http://www.fsf.org/gnu/linux-and-gnu.html>. Since the term "Linux" is still the most common usage, that term will be used throughout.
n12. See Linus Torvalds, The Linux Edge, in Open Sources: Voices from the Open Source Revolution, supra note 3 at 101,102.
n13. See Richard Stallman, The GNU Manifesto (last modified Jan. 16, 2000) <http://www.fsf.org/gnu/manifesto.html>.
n14. See Richard Stallman, Overview of the GNU Project (last modified Nov. 2, 1999) <http://www.fsf.org/gnu/gnu-history.html>.
n15. See Stallman, Linux and the GNU Project, supra note 11.
n16. See id.
n17. See Appendix A in Open Sources: Voices from the Open Source Revolution, supra note 3, at 221, 223-24 (debate between Andrew Tanenbaum and Linus Torvalds in comp.os.minix regarding Linux).
n18. See Glyn Moody, The Greatest OS That (N)ever Was (last modified Aug. 1997) <http://www.wired.com/wired/5.08/linux.html>.
n19. See Stallman, Linux and the GNU Project, supra note 11.
n20. See Robert F. Young, Sizing the Linux Market, Second Edition (last modified Mar. 5, 1998) <http://www2.linuxjournal.com/enterprise/linuxmarket.html>.
n21. See Eric Hammond, 1997 Product of the Year: Operating Systems - Network Operating Systems (visited Jan. 27, 2000) <http://www.infoworld.com/cgi-bin/displayTC.pl?97poy.win3.htm#linux> (naming Red Hat Linux as the best network operating system of 1997); John Kirch, Microsoft Windows NT Server 4.0 versus UNIX (last modified Aug. 7, 1999) <http://www.unix-vs-nt.org/kirch> (comparing Windows NT to Linux and other UNIX operating systems, including a favorable direct technical and feature comparison of Linux with Windows NT); Henry Baltazar, Linux: Enterprise Ready - The New Linux: 2.2.0 Kernel PC Week Online, Feb. 1, 1999 <http://www.zdnet.com/pcweek/stories/news/0,10228,387766,00.html> (technically reviewing Linux 2.2); Steven J. Vaughan-Nichols & Eric Carr, Linux Up Close: Time To Switch, Smart Reseller, Jan. 25, 1999 <http://www.zdnet.com/sr/stories/issue/0,4537,387506,00.html> (technical comparison of versions of Linux); Quinn P. Coldiron, Replacing Windows NT Server with Linux (last modified Mar. 2, 1998) <http://citv.unl.edu/linux/LinuxPresentation.html> (analysis of trial of Linux use to replace Windows NT); Murry Shohat, Engineers Speak Out: Linux vs. Windows NT, Part 1 (last modified Jul. 1998) <http://www.isdmag.com/Editorial/1998/CoverStory9807.html> (Review of engineer's responses to a request for evaluations of Linux). But see, Linux: How Good Is It? (abstract) (visited Feb. 6, 2000) <http://www.dhbrown.com/dhbrown/linux.cfm> (finding the enterprise capabilities of UNIX and Microsoft NT superior to Linux); A File and Web Server Comparison: Microsoft Windows NT Server4.0 and Red Hat Linux 5.2 Upgraded to the Linux 2.2.2 Kernel (last modified Apr. 13, 1999) <http://www.mindcraft.com/whitepapers/nts4rhlinux.pdf> (test sponsored by Microsoft which found that NT beat Linux in performance tests).
n22. See Our Mission (last modified June 1, 1999) <http://www.mozilla.org/mission.html>.
n23. See Michael Stutz, Cryptozilla Thwarts Feds Crypto Ban (last modified Apr. 3, 1998) <http://www.wired.com/news/news/technology/story/11465.html>.
n24. See Netscape's Brain Transplant (last modified Nov. 10, 1998) <http://www.wired.com/news/news/technology/story/16163.html>.
n25. See What Is Perl? The Perl Journal, The Voice of the Perl Community (last modified Oct. 23, 1998) <http://tpj.com/whatisperl.html>.
n26. Open Source Products (last modified Feb. 18, 1999) <http://www.opensource.org/products.html>.
n27. See Josh McHugh, For the Love of Hacking, Forbes, Aug. 10, 1998 at 94.
n28. Eric S. Raymond, The Cathedral and the Bazaar: The Mail Must Get Through (last modified Aug. 8, 1999) <http://www.tuxedo.org/<diff>esr/writings/cathedral-bazaar/cathedral-bazaar-2. html>.
n29. See Richard Stallman, The GNU Operating System and the Free Software Movement, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 53, 64 (discussing the fact that "many essential pieces of GNU software" were created as part of a plan to create a free operating system, rather than from a particular need for the software on the part of the programmer).
n30. Raymond, Mail Must Get Through, supra note 28.
n31. Eric S. Raymond's associated rule is "plan to throw one away; you will, anyhow." Id. (citing Fred Brooks, The Mythical Man-Month, Chapter 11).
n32. Id.
n33. This is what Eric S. Raymond describes happening with his efforts to modify fetchpop into a POP3 client for handling e-mail, which he eventually abandoned in favor of modifications to another program, popclient. See id.
n34. This is what happened with Linux. Linus Torvalds started with Minix, a Unix-like operating system for 386 machines. Eventually all the original Minix code was replaced, but it had provided a basis upon which to found the initial efforts. See id.
n35. Apparently, this occurred in the development of Linux. See Halloween I: Open Source Software - A (New?) Development Methodology, (last modified Aug. 11, 1998) <http://www.opensource.org/halloween/halloween1.html>.
n36. "It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn't try it. I didn't either. Your nascent developer community needs to have something runnable and testable to play with." Eric S. Raymond, The Cathedral and the Bazaar: Necessary Preconditions for the Bazaar Style (last modified Nov. 20, 1998) <http://www.tuxedo.org/<diff>esr/writings/cathedral-bazaar/cathedral-bazaar-9. html>.
n37. See Halloween I, supra note 35.
n38. See id. Consequently, it is also reasonable to conclude that access to the Internet is necessary for participation in open source projects. Thus, Internet grow, not only in terms of technology, but also in terms of world penetration is important for open source software.
n39. Id.
n40. See id.
n41. Eric S. Raymond, Homesteading the Noosphere: Ownership and Open Source, (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-4.html>.
n42. See Raymond, Mail Must Get Through, supra note 28, P 2.2.
n43. See Raymond, Ownership and Open Source, supra note 41.
n44. See Brian Behlendorf, Open Source as a Business Strategy, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 149, 163.
n45. See id. The existence of a Web site ("home" page) for the project has interesting implications for the "ownership" nature of an inherently abstract thing, like an open source project. A web page reinforces the idea of ownership as it relates to the more physical, territorial use of the term. See Eric S. Raymond, Homesteading the Noosphere: Noospheric Property and the Ethology of Territory (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-14.html>.
n46. Behlendorf, supra note 44, at 164.
n47. Id.
n48. See Eric S. Raymond, The Cathedral and the Bazaar: The Importance of Having Users, (last modified Nov. 20, 1998) <http://www.tuxedo.org/<diff>esr/writings/cathedral-bazaar/cathedral-bazaar-3. html>; Eric S. Raymond, The Cathedral and the Bazaar: Release Early, Release Often (last modified Nov. 20, 1998) <http://www.tuxedo.org/<diff>esr/writings/cathedral-bazaar/cathedral-bazaar-4. html>.
n49. Raymond, Release Early, Release Often, supra note 48.
n50. Eric S. Raymond offers three alternative formulations of this point: (1) "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone," (2) "Given enough eyeballs, all bugs are shallow," and (3) "Debugging is parallelizable." Id.
n51. Id.
n52. Id. (quoting Jeff Dutky).
n53. See id.
n54. See id.
n55. See id.
n56. See Eric S. Raymond, The Cathedral and the Bazaar: Popclient becomes Fetchmail, (last modified Nov. 20, 1998) <http://www.tuxedo.org/<diff>esr/writings/cathedral-bazaar/cathedralbazaar-6. html>.
n57. See id.
n58. Id.
n59. See Eric S. Raymond, Homesteading the Noosphere: Causes of Conflict (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-14.html>.
n60. See Eric S. Raymond, Homesteading the Noosphere: Project Structures and Ownership (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-16.html>.
n61. See id.
n62. See id.
n63. See id.
n64. Raymond, Necessary Preconditions, supra note 36.
n65. See infra notes 77-81 and accompanying text.
n66. See generally Eric S. Raymond, Homesteading the Noosphere, (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading.html>.
n67. See Eric S. Raymond, Homesteading the Noosphere: The Hacker Milieu as Gift Culture (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-6.html>.
n68. See Eric S. Raymond, Homesteading the Noosphere: The Many Faces of Reputation (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-8.html>.
n69. See id.
n70. Susan Rose-Ackerman argues that "one explanation for giving is that donors benefit from the act of giving itself." Altruism, Nonprofits, and Economic Theory, 34 J. Econ. Lit. 701, 712 (1996). Thus, even though a person may benefit from someone else's donation to some charity, they may well prefer to donate the sum themselves because they value their own act of charity. See id. She notes that one benefit donors may get from their own charity comes from a "buying-in" mentality. "They may feel that they deserve to feel good about the charitable program only if they have made some marginal contribution to it," and further, "some charities are so small and some donors are so wealthy that individual gifts do affect service levels in observable ways." Id. at 713. This is consistent with the "homesteading" label on developer behavior in Eric S. Raymond's observations of the open source community. See Eric S. Raymond, Homesteading the Noosphere: Locke and Land Title, (last modified Jan. 1, 1999) <http://www.tuxedo.org/<diff>esr/writings/homesteading-5.html>.
n71. For example, it was observed that among philanthropists in New York, "that involvement with particular organizations becomes part of donors' own identity in the eyes of those they know." Francie Ostrower, Why the Wealthy Give: The Culture of Elite Philanthropy (1995). "One important implication is that individuals derive prestige from their identification with organizations and the elite networks with which they are associated." Id.
n72. These are discussed in part, supra notes 41 - 47 and accompanying text.
n73. Raymond, Ownership and Open Source, supra note 41.
n74. See infra Section I.F (discussing open source licenses). However, this is not a direct conflict. Anyone can still make changes to their own copy. They have no guarantee of having it implemented in the main project, however.
n75. "Subsequent improvements [to projects such as Apache] of the code often stem from individuals applying the code to their own scenarios." Halloween I, supra note 35. See also Dibona, Introduction, supra note 3, at 13-14 (noting that most open source projects begin when someone is looking for a tool to do a job and finds none, or one that is poorly maintained); Robert Young, Giving it Away in Open Sources: Voices from the Open Source Revolution 113, 117-120 (1999) (discussing the appeal provided by control over source code); Frank Hecker, Setting Up Shop: The Business of Open Source Software, (last modified Dec. 6, 1999) <http://www.hecker.org/writings/setting-up-shop.html> (noting a number of practical reasons why access to the source code is valuable to customers, including the ability to maintain their software even if the vendor goes out of business, the ability to fix bugs themselves if the vendor is unwilling to do so, or to port the software to platforms not otherwise supported by the vendor); Young, Giving It Away, supra at 120 (discussing NASA's choice of open source software due to their need to customize the code - they require a level of performance not available from any standard distribution of a program).
n76. "If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource." Eric S. Raymond, The Cathedral and the Bazaar: When Is A Rose Not A Rose? (last modified Nov. 20, 1998) <http://www.tuxedo.org/<diff>esr/writings/cathedral-bazaar/cathedral-bazaar-5. html>. See also id. (discussing his efforts and their results regarding an open source software project); Marshall Kirk McKusick, Twenty Years of Berkeley Unix, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 31, 42 (contributors were solicited to rewrite Unix utilities from scratch, compensated only by being listed among the contributors. Contribution began slowly, but as the list of contributors grew, the rate of contribution grew.) Cf. Jim Hamerly, et. al, Freeing the Source, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 197, 201-02 (discussing the process as applied to the development of their open source license).
n77. See Eric S. Raymond, Homesteading the Noosphere: The Problem of Ego (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-10.html>.
n78. However, Eric S. Raymond notes that this norm "has made it emotionally difficult for many hackers to consciously understand the social dynamics of their own culture[.]" Id.
n79. Eric S. Raymond, Homesteading the Noosphere: The Value of Humility (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-11.html>.
n80. See id.
n81. See id. Taking excess esteem for him or herself means that others in the project will be under-compensated in terms of esteem. Self-promotion may also lead others in the open source community to screen out the "noise" of that project, reducing the amount of esteem potentially available from the project.
n82. See Eric S. Raymond, Homesteading the Noosphere: The Joy of Hacking (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-7.html>.
n83. See id. See also DiBona, supra note 3 at 13 ("Much like the rush a runner feels while running a race, a true programmer will feel this same rush after writing a perfect routine or tight piece of code. It is difficult to describe the joy felt after completing or debugging a hideously tricky piece of recursive code that has been a source of trouble for days.")
n84. See Raymond, The Many Faces of Reputation, supra note 68.
n85. Eric S. Raymond, Homesteading the Noosphere: Acculturation Mechanisms and the Link to Academia (last modified Nov. 21, 1998) <http://www.tuxedo.org/<diff>esr/writings/homesteading/homesteading-18.html>.
n86. "As one example, there is a USENET newsgroup called alt.sysadmin.recovery that has a very explicit such secret; you cannot post without knowing it, and knowing it is considered evidence you are fit to post. The regulars have a strong taboo against revealing this secret." Id.
n87. See id.
n88. See id.
n89. For example, it has been suggested that the reason there was forking, a rare occurrence in open source projects, in the case of BSD Unix was due to the fact that not everyone can contribute to the BSD codebase. Thus, forking could be driven by the hope of establishing a project that could supplant the existing project in popularity and acceptance. See Halloween I, supra note 35. This is not likely to be a problem with the existing barriers - the excluded members have qualities (failure to follow norms, low technical ability) that makes them unlikely to have the ability to start a project that can truly compete.
n90. A modularized program involves "constructing a program as a set of conceptually and operationally independent pieces (modules)." James Martin & Carma McClure, Software Maintenance: The Problem and Its Solutions 79 (1983).
n91. Id. at 79-80.
n92. See id. at 79. For example, Linus Torvalds stated that, in leading a project, "without modularity I would have to check every file that changed, which would be a lot, to make sure nothing was changed that would effect anything else." Torvalds, The Linux Edge, supra note 12 at 108. On the other hand, "with modularity, when someone sends me patches to do a new filesystem and I don't necessarily trust the patches per se, I can still trust the fact that if nobody's using this filesystem, it's not going to impact anything else." Id.
n93. See id.
n94. See Mark A. Lemley & David W. O'Brien, Encouraging Software Reuse, 49 Stan. L. Rev. 255 (1997) (discussing value of modularity to software reuse).
n95. Martin, supra note 90, at 79.
n96. Larry Wall, Diligence, Patience, and Humility, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 127, 142.
n97. As a way of reliably knowing whether a piece of software is open source, the Open Source Initiative ("OSI") has registered the term "OSI Certified" as a certification mark. See The OSI Certification Mark and Program (visited May 18, 2000) <http://www.opensource.org/certification-mark.html>. Using the term "OSI Certified" requires compliance with the Open Source Definition. Id. The Open Source definition requires that a license "not [to] restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale." The Open Source Definition (last modified Dec. 20, 1998) <http://www.opensource.org/osd.html>. "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." Id. "The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties." Id. Further, the license may not discriminate against persons or groups or fields of endeavor. See id. These are just some examples of the license requirements. For others, see id.
n98. These licenses are intended to cover the most widely-used licenses, and is not intended to be an exhaustive list of licenses that comply with the open source definition.
n99. See The General Public License (GPL) (last modified June 1991) <http://www.opensource.org/licenses/gpl-license.html>.
n100. Behlendorf, supra note 44, at 167. See also The General Public License (GPL), supra note 99. Behlendorf notes that this aspect of the GPL is "viral" in nature, in that "there is no chance of a commercial interest forking their own development version from the available code," creating a closed-source product that they can then market and sell exclusively. Id.
n101. See Bruce Perens, The Open Source Definition, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 171, 182. For purposes of the GNU GPL the term "proprietary" means "any program with a license that doesn't give you as many rights as the GPL." Id.
n102. Id
n103. See Richard Stallman, Why You Shouldn't Use the Library GPL For Your Next Library (last modified Nov. 6, 1999) <http://www.fsf.org/philosophy/why-not-lgpl.html>. The original GNU C library was issued under this, because the number of existing C libraries meant that restricting use to GPL developers would merely have led proprietary developers to use another C library. With new libraries, the theory was that restricting them to GPL developers could give them a competitive advantage. See id.
n104. See Behlendorf, supra note 44, at 164. For examples of the BSD-style license, see The BSD License (last modified Nov. 30, 1998) < http://www.opensource.org/bsd-license.html>; The Apache License (last modified Feb. 16, 1999) <http://www.apache.org/LICENSE.txt>.
n105. Apache chose the BSD-style license so that HTTP would become a true standard. It was not considered a problem if Microsoft chose to incorporate their HTTP engine into their products, since that was assumed to help keep HTTP a common protocol. See Behlendorf, supra note 44, at 165.
n106. Id. This could be particularly problematic, give Microsoft's proposed strategy for dealing with open source software - namely, to "de-commoditize protocols & applications" See Halloween I, supra note 35. Under the BSD-style license it seems clear that Microsoft could incorporate open source standard protocols into their products, but make proprietary modifications, that would then propagate out through Microsoft's large OS user base, becoming the de-facto standard; a standard over which Microsoft has exclusive control.
n107. "The Debian GNU/Linux distribution contains over 2,500 software packages, and if even a fraction of them were BSD-licensed," this would require a substantial list of software and credit in an advertisement. Perens, supra note 101, at 183.
n108. See Hamerly, supra note 76, at 200-03.
n109. Behlendorf, supra note 44, at 166.
n110. Id. at 166-67. See also, Mozilla Public License (last modified Dec. 8, 1998) <http://www.mozilla.org/NPL/MPL-1.0.html>.
n111. Perens, supra note 101, at 184. See also Netscape Public License (last modified Dec. 8, 1998) <http://www.mozilla.org/NPL/NPL-1.0.html>.
n112. Perens, supra note 101, at 183-84. This loophole is substantial. By aggregating software under the Artistic license with a trivial program it can be sold as a "bundle."
n113. See id.
n114. "Free software" is essentially the same as open source software, but is the preferred term of Richard Stallman. For uniformity, this paper has used "open source" throughout, but will use the term "free software" here to respect Stallman's preference for the term free software, for its implicit reference to principles of freedom.
n115. See Stallman, supra note 29, at 53-58.
n116. See Raymond, Acculturation Mechanisms and the Link to Academia, supra note 85.
n117. See Halloween I, supra note 35.
n118. See DiBona, supra note 3, at 16.
n119. See id.
n120. See Eric S. Raymond, A Brief History of Hackerdom, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 19, 20 (specifically, discussing the role of ARPANET).
n121. See Halloween I, supra note 35.
n122. Id.
n123. "Many people believe that the spirit of the GNU project is that you should not charge money for distributing copies of software, or that you should charge as little as possible - just enough to cover the cost." See Richard Stallman, Selling Free Software, (last modified Dec. 17, 1998) <http://www.fsf.org/philosophy/selling.html>. However, Stallman goes on to note that GNU "encourages people who redistribute free software to charge as much as they wish or can." Id.
n124. One of the first projects that originated what has now become the open source, or free software, movement was GNU Emacs. Richard Stallman made this available for free via ftp, but also would mail a copy on tape for a fee of $ 150. See Stallman, The GNU Operating System, supra note 29, at 58.
n125. For example, Red Hat (www.redhat.com), Debian (www.debian.org) and S.u.S.E. (www.suse.com) sell versions of the Linux operating system. The basic economics of the market for proprietary software taken open-source, as well as the marketing points raised in the context of existing open source projects apply to these programs with equal force. Thus, the two ways of getting to an open source business will not be considered separately. However, one additional factor raised to justify changing proprietary programs to open source. In areas where there is a "commercial wall" between two open source programs, there will be a strong tendency for an open source program to arise to "bridge the gap." Behlendorf, supra note 44, at 160. It may be beneficial for the company to take the program open source preemptively. See id. The business could then use their existing brand reputation to continue to profit from the sale of a particular product even after it has become open.
n126. What is meant by customer support here is what is called "hand-holding" - providing training and basic knowledge that helps the customer understand how to use the existing product. Customer service could also include responding to customer complaints and recommendations for changes or needed features for the software. See Young, supra note 75, at 115-17.
n127. See id.
n128. This point is emphatically made by Robert Young. He likens the marketing of Red Hat to the marketing of cars or ketchup. Even though ketchup can be made at home, the convenience of having Heinz or Hunts do it encourages purchases. However, it is the brand marketing of Heinz, rather than the technical superiority of their ketchup, that leads them to have 80% market share. See id. See also, Nicholas Petreley, Linux and the Monopoly Game (visited Feb. 10, 2000) <http://www.linuxworld.com/linuxworld/lw-1999-01/lw-01-penguin.html>.
n129. See, e.g., The Business Case for Open Source (last modified Dec. 18, 1998) <http://www.opensource.org/for-suits.html> (noting reliability and technical arguments); Michael Tiemann, Future of Cygnus Solutions in Open Sources: Voices from the Open Source Revolution, supra note 3, at 71, 83 (noting his initial marketing focus on the technical merits of GNU tools).
n130. See Young, supra note 75, at 120 (stating that "the benefit to using Linux is not the high reliability, ease of use, robustness, or the tools included with the Linux OS," but rather other features of the software).
n131. Cygnus took the marketing approach of "explaining to customers why they should buy from us instead of trying to do the work with their own people," noting that "their engineers would benefit from having us do the baseline porting, support, and maintenance work." Tiemann, supra note 129, at 83. This benefit will also be of importance in the decision to take proprietary software open source. See also The Business Case for Open Source, supra note 129.
n132. See Tiemann, supra note 129, at 83.
n133. See id.
n134. "Unlike proprietary software in which competitors fight in a two-sided win/lose contest, with Open Source it's more like fighting on a Moebius strip, and everything flows to the side of the primary maintainer." Id at 84. Thus, while competitors can easily enter the market because the product is freely available, the grounds on which existing businesses can be outperformed is limited in the long term.
n135. The Business Case for Open Source, supra note 129.
n136. See Tim O'Reilly, Hardware, Software and Infoware, in Open Sources: Voices from the Open Source Revolution, supra note 3, at 189, 195.
n137. For example, NASA chose Red Hat Linux because the source code was available. Their performance standards were extremely exacting, and thus they needed to be able to modify the code to fit particular needs. See Young, supra note 75, at 120. Young goes on to state that "the benefit to using Linux is not the high reliability, ease of use, robustness, or the tools included with the Linux OS. It is the benefit of control that results form the two distinctive features of this OS; namely, that it ships with complete source code, and that you can use this source code for whatever you chose - without so much as asking our permission." Id. at 120; See also Tiemann, supra note 129, at 86.
n138. Copyleft refers to the GNU-style license. Rather than withholding the ability to use the work, as with copyright, the ability to use the work is specifically granted under copyleft.
n139. Stallman, Overview of the GNU Project, supra note 14.
n140. Stallman, The GNU Operating System, supra note 29, at 69.
n141. Id.