Fordham Intellectual Property, Media & Entertainment
Copyright (c) 2000 Fordham Intellectual Property, Media & Entertainment
Spring, 2000; 10 Fordham I. P., Media & Ent. L.J. 619
Open Source Software: The Success of an Alternative
Intellectual Property Incentive Paradigm
[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
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
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.
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
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
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.
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
Sendmail is a utility that routes about 80% of the e-mail on the Internet.
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.
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.
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
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.
[*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
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.
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.
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
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."
* * * * *
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>
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
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)
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.
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
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.
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).
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)
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.
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.
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.
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."
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.
n57. See 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
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
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.
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,
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
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.
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
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
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,
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.