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. Next, a background
introduction to complexity theory will be provided. The features of open
source development will then be analyzed, uncovering the complex nature of
open source development. While the complex nature of open source software
provides an explanation as to its technical success, it also provides insight
into a number of problems that are facing the open source community. The
threats to the complex nature of open source development will be considered
and means of circumventing these problems suggested. Finally, the potential
for complexity to solve some anticipated open source problems will be discussed.
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
II. Introduction to Complexity Theory
Complexity theory, as a subject matter, has its roots in many different
fields of study. Aspects of the theory were developed in such diverse fields
as genetics and economics to explain empirical observations that were not
predictable by traditional theories. Specifically, traditional "linear" models
were often unable to account for certain observed behaviors that seemed "nonlinear"
in nature. Briefly, complex systems are groups of agents whose nature and
behavior are governed by certain sets of rules. The nature and behavior of
these agents lead to outcomes within the system and capabilities of the system
making it greater than the sum of its parts. As will be seen, the complex
nature of a system may be valuable in many ways, but also makes the prediction
of specific future characteristics of the system difficult or impossible.
Finally, it is important to note that complex systems may exist side-by-side
with [*647] other types of systems. n142
The discovery that a system is complex in nature could lead to two different
conclusions for anyone concerned with the future of the system. First, attempts
could be made to force the system to behave more linearly, resulting in a
loss of the benefits of complexity, but perhaps a gain in predictability.
Alternatively, the ambiguity in specific future states of the system could
be accepted, with faith placed in the ultimate benefits that accrue to complex
systems.
Greater explanation of the nature of complex systems has been detailed elsewhere.
n143 Thus, a description of what constitutes a complex system will be outlined
here in brief. The factors that make up a complex system are: (1) a systems
of agents with certain internal traits, (2) interactions among these agents
that occur following certain rules, and (3) the general consequences that
can be expected to result.
A. System of agents
The term "agent" likely conjures up different, but nonetheless clear, pictures
in the minds of everyone. In the law, an agent is "a person authorized by
another to act on his account and under his control." n144 However,
in a complex system an agent is merely any actor (be it a person, a computer
program, or a gene) that has certain internal and behavioral characteristics.
In complexity theory, the internal traits of an agent are considered to be:
"(1) a performance system, (2) a credit-assignment algorithm, and (3) a rule-discovery
algorithm," and, as will also be seen, (4) a mechanism for making predictions.
n145
[*648] "The performance system specifies the agent's capabilities
at a fixed point in time - what it could do in the absence of further adaptation."
n146 Basically, this includes the agent's ability to obtain information from
its environment, as well as its ability to act on its environment on the
basis of this information. n147 Implicit in this ability is the necessity
of a "processing mechanism." This can be analogized to a set of if-then rules
that allow the agent to determine what action is appropriate for the given
bit of information with which it is dealing. n148
The agent's credit assignment mechanism is a tool for evaluating the processing
rules that it uses. This mechanism must somehow determine which if-then rules
lead to good outcomes for the agent, and which do not. Competition between
rules is used to find and reinforce rules with successful outcomes, and weed
out those that are unsuccessful. n149 This is a challenging proposition
for several reasons. First, the ease with which a rule is able to be evaluated
will depend upon the role the rule plays. A rule that calls for direct interaction
with the agent's environment will be easier to evaluate, because it will
generate direct feedback from the environment. However, "credit assignment
is much more difficult when some early stage-setting action makes possible
a later useful outcome." n150 Second, the credit assignment mechanism
is dependent on the current status of the agent in its environment. Thus,
the mechanism must be able to respond to changes in the agent and the agent's
environment. n151
A supplement to the credit assignment mechanism is the rule discovery mechanism.
This process allows new if-then rules to be put into circulation for evaluation
by the credit assignment process. [*649] This occurs principally
by replacing the unsuccessful rules, which were weeded out by the credit
mechanism, with new rules based on permutations of successful rules.
n152 The two processes by which these permutations of successful rules are
created are combination n153 and mutation. n154 Combination simply
involves the inclusion of various elements of successful rules to create
a new rule. Mutation is the alteration of a successful rule to create a slightly
different rule.
Finally, agents need a prediction mechanism to allow the environmental feedback
obtained by the agent to be translated into a broader set of rules than would
be possible from the limited experiences of any agent. Agents with a means
of making predictions are able to take the "building blocks" from their actual
experiences, and by emphasizing patterns, use these blocks to create tools
for dealing with patterns in their environment. n155 The best example
of this is the human ability to reuse basic "building blocks" such as "tree,"
"car," or "person," to comprehend vast numbers of novel situations. Similarly,
the laws of physics are relatively simple, and small in number, compared
to the behavior of the world that they are able to describe. n156 "If
[you] have a process that can discover building blocks... the combinatorics
start working for [you], rather than against [you]. [You] can describe a
great many complicated things with relatively few building blocks."
n157
B. Interactions of agents
The interaction among agents leads to many of the beneficial [*650]
aspects of complex systems. There are basic principles that describe the
processes of interaction among agents in complex system, including the presence
of flows and the use of tagging mechanisms. Agent interactions lead to changes
in the system, not only in the co-evolution of agents and their environment,
but through the multiplication and recycling of resources and diversity in
the system. Finally, the interaction of agents allows them to form "meta-agents"
which act as agents at a higher level.
1. Rules for Interaction
As John Holland observed, "complex large-scale behaviors [emerge] from the
aggregate interactions of less complex agents." n158 Agent interaction
is characterized by the use of tags and the existence of flows over a network
of agents. Tagging allows agents to determine traits of their environment
and other agents. Agents compare their own tags with the tags of other agents
to determine if resources can be exchanged, and in what quantity. n159
Over time, in a complex system, this allows agents to specialize and cooperate.
n160 Further, tags evolve in a manner similar to that of internal rules.
As agent interactions occur, the system selects "for tags that mediate useful
interactions and against tags that cause malfunctions." n161 Cooperation,
specialization and tag evolution facilitates the emergence of meta-agents
and general system characteristics that endure despite the continual evolution
of the internal components of the system. n162
In complex systems, agents can be considered "nodes" and the possible interactions
of agents, defined by the tags, are "connectors" in this network. n163
As interactions occur between the nodes, "flows" of resources occur along
the various connectors. These flows vary over time as the agents and their
environments co-evolve based on their experiences with one another.
n164 The importance [*651] of these flows will be seen to arise
from the role they play in the changes they bring about in the system. The
future of agents in a complex system are influenced by prior interactions
of among agents and their environment. n165
2. Interactions Yield Systemic Changes
The nature of the interaction of agents in a complex system leads to several
large-scale results for the system itself. These results include system-wide
changes from changes in flows, and diversity that results from the co-evolution
of agents and their environment. The nature of flows in a complex system
are such that the input of a resource at one node will result in that resource
being spread throughout the system producing a chain of changes. n166
The fact that, as a result of flows, changes in the entire system can occur
through the introduction of a new resource or the re-routing of an existing
resource makes it nearly impossible to make long-range predictions based
on simple trends. n167 A further characteristic of flows is that resources
are recycled as they flow between nodes. This allows complex systems to be
more productive for a given initial input of some resource than it would
be if recycling did not occur. n168
Changes in a complex system due to flows, the cooperation and specialization
that occur from tagging, and the co-evolution of agents and their environment
result in substantial diversity in complex systems. If an agent is removed
from the system, "the system [*652] typically responds with a
cascade of adaptations resulting in a new agent that "fills the hole.'"
n169 A new agent or agents will arise to fill the need left by the removal
of the agent, but may perform the tasks in different ways. These new agents
may create new opportunities, or niches, to be exploited by other agents.
n170 Thus, the minor change of removing a single agent from a system can
result in the creation of new agents and changes in roles for existing agents,
leading to greater diversity. This diversity is itself dynamic. When the
diversity of a complex system is disturbed, it eventually settles back down
to a pattern. However, in complex systems, this new pattern of diversity
may be different than the old one. This also leads to further interactions
and new niches. Thus, the diversity in a complex system is due both to adaptation
to individual internal changes, as well as changes in the system as a whole.
n171
This co-evolution of agents occurs within a range of almost limitless possibilities
n172 and a constantly co-evolving environment. As a result, there is no practical
way of "optimizing" a given agent's fitness. Changes only occur based on
the current abilities and surroundings of an agent - in particular those
surroundings which the agent is able to perceive. This limited range of alternatives
may not include the alternative that is "optimal." n173 Thus, agents
attempt to maximize their "fitness" within the range of alternatives (the
"fitness landscape") that are available to them at a given time.
3. Interactions Allow the Formation of Meta-Agents
The cooperation and competition of agents allows the formation [*653]
of "meta-agents," or aggregates of agents. n174 These meta-agents act
as agents at a higher level. n175 The fact of agent aggregation is
basic to all complex systems. The resulting features of the meta-agents,
which arise from the historical interactions of lower-level agents, "are
the most enigmatic aspect of [complex systems]." n176 "The behavior
of these clusters, or meta-agents, is governed by the same principles that
govern the underlying agents that aggregated in the first instance. This
process of aggregation and re-aggregation often repeats numerous, yielding
the hierarchical organization typical of complex systems." n177
The behavior of these meta-agents is different than merely the sum of the
capabilities of the constituent agents. n178 "It is difficult to evolve
a single agent with the aggregate's capabilities. Such complex capabilities
are more easily approached step by step, using a distributed system."
n179
C. Only Short-term Predictions
Although it should be obvious from the discussion of complex systems thus
far, it is worth stating clearly that specific long-term predictions are
not possible for complex systems. This is a result of difficulties associated
with even "tracing the impact of any change even after the fact, let alone
predicting it ahead of time, making the system complex and hard to control."
n180 It is also due to the fact that small changes in complex systems yield
big results. Specifically, small changes in the initial conditions of complex
systems will be spread throughout the system, multiplied and recycled
[*654] through flows. These small changes are thus magnified,
n181 meaning also that any uncertainty in the initial conditions will be
magnified as well. n182 In a complex world, the pretense of long-term
prediction must be rejected. The true consequences of our own best actions
cannot be known. All that can be done is be locally wise, not globally wise.
n183
D. Edge of Chaos
Complex systems are sometimes described as existing "on the edge of chaos,"
or as a phase transition between order and chaos. n184 This is exemplified
in the classes of behavior documented in "cellular automata" by Stephen Wolfram.
n185 Cellular automata are simulated collections of cells programmed to carry
out rules as a group. "This collection of cells ... could be viewed as an
organism, running on pure logic." n186 Professor Wolfram studied the
simplest automata universe - one-dimensional automata arranged in a single
line. The initial state was defined at random, and a variety of local rules
governing the sites on the automata. "The longtime behavior of the cellular
automata" could be classified "into four types, regardless of specific local
rules employed." n187 [*655] In Class I the pattern either
disappears or becomes static. In Class II "the pattern evolves to a fixed
finite size" with continually-repeating patterns. n188 Chaotic states
with "little semblance of regularity" occur in Class III. n189 Finally,
in Class IV complex patterns occur. n190 These classes of behavior
were discovered to bear many similarities to "second-order" phase transitions.
n191 Class I and II states are like the ordered states that occur well below
the transition point. The Class III state is like the random, chaotic behavior
that occurs above the transition point. The Class IV state is like the complex
state that occurs near the transition point. n192
Because ordered and chaotic elements are bound together to create a complex
system, it should be noted that alterations in a complex system could serve
to drive the system toward either the ordered or chaotic states, just as
temperature changes, for example, could lead a system to complete the phase
transition, resulting in a fully ordered or fully chaotic state. n193
Thus, it is worth considering what effects these shifts could have on a system.
Specifically, the benefits of complexity must be considered, and the detrimental
effects of transitions to ordered or chaotic states must be evaluated.
The main consequences of complexity are adaptability and emergence. "Complex
systems constructed such that they are poised on the boundary between order
and chaos are the ones best able to adapt by mutation and selection. Such
poised systems appear [*656] to be best able to coordinate complex,
flexible behavior and best able to respond to changes in their environment."
n194 As described by J.B. Ruhl:
Systems in the complex region thus exist when the qualities contributing
to system sustainability - stability, simplicity, and adaptability - are
in harmonious balance, and chaos, emergence, and catastrophe are collapsed
into instruments of system evolutionary robustness. Moreover, the blend of
attractors needed to promote sustainability necessarily produces emergent
behaviors as a result of interaction between the multiple components. Hence,
a robust, fit, sustainable dynamical system, because of the inherent presence
of some chaos and emergence, necessarily is unpredictable. The key is that
the complex systems have turned that source of unpredictability around and
channeled it into the trait of adaptiveness, allowing the system to transform
disorder into organization. n195
The value of adaptability and emergence can be most clearly seen by comparison
to hierarchical, ordered systems. Such top-down systems of rules of behavior
"tend to be touchy and fragile." n196 "Since it's effectively impossible
to cover every conceivable situation, top-down systems are forever running
into combinations of events they don't know how to handle." n197 Although
linear systems have the characteristic of predictability, it comes at the
price of the emergent properties (the whole being greater than the sum of
the parts) that exists for complex systems. n198 Thus, ordered systems
are less able to deal with future events, and are limited in what they can
achieve to merely the sum of the capabilities of their parts.
[*657] Chaotic systems differ from complex systems not so much in
behavioral procedures, but in the substantive outcomes of these rules of
behavior. Unlike complex systems, "chaotic systems have no memory for the
past and cannot evolve." n199 Thus, the whole of a complex system may
well be different from the sum of its parts, but there is no reason to expect
that it will be greater. n200 With no "memory for the past" the chaotic
system cannot create the mechanisms for rule discovery and prediction, or
develop evolved tags. Left to itself, a complex system can be expected to
maximize its fitness to the extent possible. Chaotic systems can be expected
to change, but in ways that do not necessarily bear any relationship to the
fitness of the system. In short, the chaotic system cannot maximize its position
in the "fitness landscape" - they can change, but not necessarily evolve.
This is not to say that such perturbations into chaos or linearity are necessarily
permanent. Rather, if the system is sufficiently close to the "transition
area" the system may evolve back to a complex state. n201 However,
the complex state is relatively beneficial, and order and chaos are seen
to have relative disadvantages. Thus, it makes little sense to drive the
system away from complexity and toward chaos and order, even if the perturbations
are insufficient to drive the system fully into ordered or chaotic states.
[*658]
III. Open Source Methodology as a Complex System
From the open source projects discussed n202 it is clear that the
open source process develops technically strong code. This is true, despite
the fact that the development is much more distributed, bottom-up than proprietary
methods of development. A consideration of the details of the open source
process will show that all the elements of a complex system are present.
Thus, complexity theory can explain the observed result of the technical
strength of open source projects.
A. System of Agents
The open source process consists of many elements that play the role of
agents. For example, the underlying technology (hardware and software) fills
the role of simple agents. Most obviously, the users, programmers and developers
also act as agents in this system. The aggregates of these individuals play
important agent roles as well. Project-level communities may act as agents
by competing and interacting with other projects. Further, the community
as a whole acts as a norm-setting and norm-enforcing agent to help constrain
the cultural aspects which are important to the open source process.
n203
The performance systems of the most simple hardware and software agents closely
fit the "if-then rule" analogy. n204 Computers, hardware and software
literally obey if-then rules and have a performance system dictated by their
own programming or materials, acting in concert with their environment (other
hardware, computers, programs, users, et cetera). The performance system
of the developers is based on their particular computer skills - knowledge
of programming languages, programming and debugging abilities, et cetera.
The open source community norms provide [*659] project ownership
rules, n205 necessary traits for project leadership, n206 and
norms exist that provide a disincentive to engage in self-promotion.
n207 The more localized "hurdle" norms n208 are examples of norms for
which the relevant community may be a project or group of projects within
the larger open source community. It is interesting to note that, although
in hindsight analysis these rules strengthen the open source process, there
was apparently no centralized effort to develop these rules, as evidenced
by the widespread unawareness of their existence. n209
The credit assignment mechanism for computer hardware and software comes
from the changes that result from testing and evaluation done on the code
by programmers. The credit assignment mechanism for the norms governing individual
and group behavior and rule-choice could be expected to function in a manner
consistent with esteem norms generally. n210 However, this category
of internal characteristic is particularly difficult to determine based on
the information presently available.
The rule discovery mechanism for developers and groups, as with the credit
assignment mechanism, should occur in a manner consistent with norms generally.
However, the rule discovery mechanism for open source software provides a
clearer example of the type of mutation and reproduction typically of complex
systems. Specifically, the recycling of code commonly done by open source
developers n211 will result in the reuse of successful "rules" in combination
with other successful elements of code (reproduction), as well as to serve
as the basis for new code development (mutation).
The reuse of code in open source projects is also an example of a type of
prediction mechanism. By breaking down a task to be performed by software
into familiar parts, pre-existing elements of [*660] code can
be used. The role of the normative training received in the academic setting
n212 provides one example of the prediction mechanism that occurs in the
open source context. The type of behavioral norms learned in the academic
setting get carried over and applied to the new activities that occur in
open source development. Finally, many of the open source projects, notably
Linux, had some basis in existing technology. n213
B. Interactions of Agents
The interaction of agents is one of the most important aspects of complex
systems. Thus, the rules for open source agent interaction will next be investigated.
Further, the systemic changes that are due to these interactions will be
considered. Finally, the means by which open source agents form aggregates
is discussed.
1. Rules for Interaction
There are two main rules for agent interaction in complex systems. Both
tagging and flows are evident within the open source methodology.
a. Tagging
The first aspect of agent interaction is the use of tags. There are many
examples of this behavior in the open source context. One obvious example
is the "OSI Certified" certification mark. n214 This mark is able to
be used only on software that meets the Open Source Definition. n215
Members wishing to use or participate in the development of "true" open source
software can use this "tag" to distinguish open source software from software
that only claims to be open, or which may have only a few open source elements.
[*661] Open source licenses can serve a similar function. Although
they may be less clear than the simple "OSI Certified" label, the terms of
the license can help signal whether a program is truly open source.
Open source community norms also play a substantial tagging role. The norm
against self-promotion could be viewed as an interpretation of the "tag"
of egotistical behavior as representing someone who will not allocate credit
and reputation in the project in a way consistent with community norms.
n216 The norms which serve as barriers to entry help identify individuals
who wish to participate in code development, but would not be desirable as
participants. n217 These norms are tags that allow participants to
identify those with whom it is useful to deal and those with whom it is not.
The "gift culture" norms of the community may serve a tagging mechanism in
a more subtle way as well. Eric Posner has discussed the ways in which gift
giving can have a signaling function that is useful in distinguishing between
two types of market actors - opportunists and cooperators. n218 Specifically,
giving of gifts, when done appropriately, allows cooperators to distinguish
themselves from opportunists in order to pair up with other cooperators.
n219 "Cooperators give gifts as a way of showing that they expect a long-term
relationship; if they expected only a short-term relationship, they would
not obtain a sufficient return to offset the cost of the gifts." n220
This signaling helps to overcome a collective action problem. Although together
programmers could engage in activities that produce a cooperative surplus,
this can only be achieved through a long-term relationship, while substantial
incentives exist to gather short-term benefits and then abandon the relationship.
n221
The use of gift giving as a tag could be true in the open source [*662]
community as well. Initiators of a project give a gift of the initial project
development and its maintenance, and user give the gift of debugging and
development. They signal to one another that they wish to cooperate to take
advantage of the benefits that have been seen to accrue to the open source
development method. Further, the actions of proprietary software companies
claiming to go open source with a program can be observed in this manner
as well. If they do not fully conform to the requirements of the open source
community (i.e., meet the Open Source definition or other standards) this
could help the community recognize a opportunist. Such behavior has been
seen in the context of technical standards, n222 and there is potential
for its occurrence with open source software as well. n223
b. Flows
Flows are apparent in open source software development as well. For example,
maintainers of an open source project distribute programs and in return receive
bug fixes and patches to the program. In return for the work of users, project
leaders often get their improvements implemented in future version of the
program, and have continued access to the source code to make their own changes.
Based on their input, developers receive esteem from other users and group
members as well as from the open source community as a whole. Open source
businesses receive money in exchange for software and support. This, in turn,
may allow for the funding of continued development of open source projects.
Proprietary [*663] software developers may take programs open
source, providing the community with guaranteed access to the source code
of the program, in exchange for the benefit of future modifications and the
publicity that comes from such a move. Proprietary companies may also merely
port programs to the Linux platform, gaining a foothold in the open source
market, in exchange for providing open source software users with a useful
program. Finally, modularity plays an important role in the flows of the
system. Modularity of code allows the work of programmers to be spread throughout
the system. The reuse of modules from prior programs allow the programmer's
work to be spread into future programs. The ease of evaluation and quality
improvement that comes from modularity could be expected to make modularity
valued by peers.
2. Interactions Yield Systemic Changes
The recycling of code is one good example of how flows result in the spreading
of resources throughout the open source system. One piece of code, once introduced
into an open source program, can be recycled for use in unrelated programs.
These programs may be referenced when still other, different, programs are
being written. Recycling might not occur at all for a given piece of code,
or it might occur repeatedly into the foreseeable future. The initial input
of work by the first author may result in the accomplishment of substantial
programming effort when the code's role in future programs is considered.
Part of how flows and tagging create change and diversity in a complex system
is through the creation and filling of niches. This process is clearly at
work in the open source context. As the range of open source applications
increases, niches are created for programs that work with these applications,
for adaptations of these programs for particular settings, or for the development
of more advanced software that these underlying technologies make possible.
External changes, such as those in hardware or standards, also lead to the
extinction of former programs and the need for new software to take its place.
Thus, the range of products that exist and the change that occurs in the
open source community appears consistent with the systemic changes to be
expected in complex systems.
3. Formation of Meta-Agents
The fact that meta-agents occur in the open source community [*664]
has already been noted. n224 The nature of agent interaction allows
for the meta-agents to have capabilities that would be difficult or impossible
to achieve in a single sub-agent. For example, the creation of what is now
known as the Linux operating system would hardly have been as attainable
by Linus Torvalds. Rather, it was the effort of a large number of groups,
project leaders and developers that allowed the operating system to reach
its current level of sophistication. Similarly, by awarding or withholding
esteem based on participation at the aggregate level, critical levels of
reputational benefit may be possible, leading developers to participate when
such incentive may not have been attainable at the individual or even single-project
level.
C. Specific Example - Linux
The development of the Linux operating system provides a good example of
the complex processes of open source development at work. The agents in this
system include Richard Stallman, Linus Torvalds, and others who contributed
to the development of the operating system. n225 Agents also include
the organizational-level actors, such as the GNU project, which helped orchestrate
the development of the specific projects necessary to fill out the operating
system's components. n226
The community guidelines for open source development not only provided a
performance system for the participants in the development of Linux, but
may in fact have been substantially originated (as discernible principles)
in this project's development. These principles came, in part, from the policy
statement n227 and legal constraints n228 imposed by the GPL
developed by the Free Software Foundation for use with GNU software.
n229 This license was [*665] utilized by Linus Torvalds when
distributing Linux, n230 thus constraining the way in which development
could occur. The success of the development of Linux resulted in its development
process being mimicked in later open source projects. n231
Further, the recognized importance of modular code to open source software
may also have had its roots in these projects. n232 Indeed, the fact
that modularity is widely observed in open source projects is a sign of the
success of the credit assignment mechanism. The mechanism credited rules
not only based on environmental feedback, but for stage-setting capabilities
as well. n233 For example, code recycling was facilitated through modularity.
n234 Finally, the choice by Richard Stallman to use Unix as a model for functionality
of the operating system, n235 and the decision of Linus Torvalds to
base his original kernel on the Minix kernel, which is Unix-like, n236
were instances of prediction mechanisms at work. n237
Tagging played an important role in the development of the Linux operating
system. Confusion over the term "free" lead to a false start in Richard Stallman's
attempt to find a free compiler to begin work on an operating system.
n238 The "tag" of the GNU GPL [*666] under which Linux was released,
signaled to GNU that the Linux kernel would be a kernel that would fit with
the goal of a free operating system, not only technically, but ideologically.
The distribution method of Linux - given away for free public download -
may have been the kind of "gift-tag" n239 that would allow GNU to recognize
the potential for a long-term relationship with Linux.
Systemic changes and the formation of niches was also evident in Linux's
development. A niche was perceived by Richard Stallman - the need for a free
operating system. n240 This led to the creation of the GNU Project
as well as Emacs and GNU utilities. n241 These formed a complete operating
system, except for the kernel. n242 The niche for a kernel was filled
by Linux. n243 The existence of the Linux operating system then created
further niches for system utilities, user interfaces, file management tools,
drivers, et cetera. n244 The filling of these niches create still more
niches which must be filled. The existence of these products and a marketplace
of consumers led to the filling of the niche by software distributors who
added value. n245
IV. Results of the Complexity of the Open Source Community
The prior section applied complexity theory to the nature of the open source
development process and revealed that the open source process is, in fact,
a complex. This has several consequences [*667] for open source
software and the development process. First, the complex nature of open source
development means that only short-term predictions are possible, particularly
with regard to specific matters. Second, and more importantly, the complex
nature of open source development makes the high quality software developed
by the open source method not only expected, but the natural outcome of the
system's complexity.
A. Short-Term Predictions
A consequence of the complex nature of open source software development
is that the ability to predict the future of open source software or the
community with any specificity is impossible. Attempts to predict what software
will be developed, what norms will exist, or what the open source marketplace
will look like in the mid-or long-term would be foolish. The systemic changes
that have been seen in the open source movement when coupled with the fact
that small changes in complex systems are magnified through recycling and
feedback make such predictions impossible. Further, any change in the surrounding
environment facing the open source community will affect the co-evolution
of the system in ways not currently predictable.
It is also important to note that the complex nature of a given aspect of
any open source project may not continue infinitely into the future. In the
study of complexity in economic markets, it is known that as markets mature,
they become less complex and more linear. n246 Thus, as some open source
projects mature, and fewer changes need to be made, some elements can be
expected to stabilize. n247 The niches created by such a product's
development can be expected to yield a continued overall complexity, both
at the system level, and more specifically at the project level, as new,
less mature projects are created to fill these niches.
[*668]
B. Co-Evolution and Fitness Maximization
The effect of complex co-evolution of software elements such as, user demand
and background technology, maximizes the "fitness" of a program, group, community,
et cetera, given the constraints of the other elements in the system at that
time. By simply relying on the existing open source process, it can be expected
that the software developed by the process will be the best n248 attainable
given the current position of the open source system in terms of all elements
- users, developers, market share, underlying technology, community size,
et cetera. That the open source methodology should lead to technically sound
products is not unexpected. Rather, it is the natural result of a complex
system. It is not just software quality, however, that can be expected to
be maximized. Community norms, levels of participation and other factors
are regulated by the principles of complexity as well, and can be expected
to maximize their relative fitnesses, as they co-evolve along with the software
and other elements of the open source environment.
Even beyond the descriptive aspects of complexity theory with regard to open
source successes, some general predictions are possible as well. Particularly,
it would be the natural consequence of a complex system, such as the open
source process, to continue to achieve the maximal attainable fitness in
the future. Thus, new versions of existing open source projects, and the
new programs developed in the future, can be expected to maintain a high
level of technical excellence, as long as the open source methodology remains
a complex system of behavior. This should not be mistaken as calling for
rigidity. Rather, this conclusion calls for the recognition that the evolution
which led to the current open source system can be expected to continue,
and that such evolution will result in a system that produces technically
superior products.
V. Open Source on the Edge of Chaos
The conclusion of the last section gives hope for the future of [*669]
open source software. Such a future can only be expected to occur, however,
if the open source approach to software design remains complex. Assuming
that the continued production of high quality software is desirable, future
action must be undertaken with an awareness of the potential consequences
of moving the system from complexity to order or chaos. Short of a complete
move of the system out of complexity, admittedly an extreme result, it still
makes little sense to engage in activities that tend to push the system toward
order or chaos. Although the system will adapt back to a complex balance
in many cases, the counter-productive and ultimately fruitless nature of
the activities indicate that they should be avoided.
A. Linearity
The potential problem for the open source movement from pushes toward linearity
comes from several sources. First, pushes towards centralized leadership,
even in a limited way, can pose problems for the system. Emphasis on moving
open source software into new areas could pose problems as well, if the system
has not developed to a stage where it is ready for such a move. Finally,
the threat of the closed-source development model could be problematic.
1. The Problem of Centralized Leadership
The paradigm of linear modes of software development occurs in the hierarchical
methodologies used by most proprietary software companies. This approach
is highly planned, and implemented in a top-down manner. When the open source
process moves from complexity toward linearity, a particular threat comes
from the natural attraction to centralized explanations experienced by nearly
all people. n249 This causes people to impose the concept of a "leader"
n250 or a "seed" n251 when explaining phenomena, or [*670]
when developing solutions to problems. n252 This tendency may lead
people to push the open source community toward linear, centralized approaches
to functioning, in ways that could push the system toward linearity.
The most dangerous example of this problem comes from those who would directly
impose some hierarchical, top-down leadership on the community. At the moment
it is not clear that any organization is openly arguing that it should have
total, centralized control over the open source community. However, organizations
are arguing for centralized control over certain aspects of the community.
n253 The reasoning behind such an approach comes from a failure to appreciate
the richness of behavior attainable by complex systems. In the view of such
individuals, "there is no place for unintended patterns, arising from decentralized
interactions," but rather, an innovative software design or long term success
must arise "as an explicit goal." n254 This leads to "misintuitions
when people try to make sense of self-organizing systems." n255 In
reality, "in many self-organizing systems, random fluctuations act as the
seeds from which patterns and structures grow." n256 The apparent randomness
in the system actually allows systems to explore alternatives [*671]
in parallel and reach a ""global' optimum." n257 Because the system
behaves differently at different levels of abstraction, n258 such an
optimum may not be apparent, let alone attainable from a top-down perspective.
Thus, an approach that appears good from a linear perspective may be too
fragile to survive, or may miss out on opportunities that arise from nonlinear
effects that are, almost by definition, not predictable by a "leader." Although
it may appear riskier to those unfamiliar with complex systems, leaving innovations
of all kinds to the system itself may be the best approach to preserving
the complexity that has made open source software good.
A natural point of criticism of this argument is the observed importance
of project leaders in the open source process. n259 Indeed, the argument
that linear traits are being discovered in, or proposed for, a complex system
need not immediately signal a problem - complex systems involve balances
of order and chaos. n260 However, the potential "harm" resulting from
a given project leader is limited to the replicability of the project. If
the leader is taking the project in a direction that some nontrivial segment
of users dislike, they may fork the project and create their own version
to compete with the existing project. They could even go so far as to create
an entirely new project. This could be done relatively easily (assuming user
interest) for smaller projects. For larger projects (for example, Linux)
it might be reasonable to expect greater difficulty in "forking" the overall
project, due to the effort required to reproduce an operating system. However,
big projects are often subdivided into smaller projects, which are more susceptible
to forking. It is further worth noting that the difficulty of reproducing
a program of the scope of a large project is far from prohibitive.
n261 Thus, the "linear" nature of project leadership is [*672]
constrained, in part, by the "chaos" of code forking. n262
The norms of the open source community have also evolved to constrain the
role of project leader. n263 These norms regulate the project leader
to require behavior in a manner consistent with the complexity of the open
source system. The means of assigning credit to contributors, norms against
self-promotion and the obligations required before taking over a project
all facilitate the overall process which allows for distributed, complex
behavior.
A further counter-argument that could be raised against the critique of top-down
leadership is that businesses or the government expect, and feel most comfortable
dealing with, such an entity. n264 That businesses and governmental
authorities should have such expectations is not surprising. n265 However,
to simply cave in to those desires evidences a failure to understand and
apply another basic principle of complex systems - that the environment co-evolves
along with the complex system. n266 This gives rise to several points.
First, due to co-evolution, when the open source community creates a centralized
model, the preference in business and government for a centralized model
could have the effect of making the open source community more centralized.
n267 The corollary to this point is that, by using centralized bodies to
deal with government and business groups, the opportunity to force these
bodies to change in order to understand open source development may be lost.
n268 Finally, even if the goal of the open source organization is [*673]
not to be a community leader, but merely to inform business and government
about the merits of open source software, the tendency of business and governmental
bodies to seek centralized explanations will likely lead them to treat the
open source organization as a leader. This will result in an ultimate failure
to understand the true nature of the open source process. n269 Thus,
it is important to weigh carefully not only the effect a leadership organization
would have on the open source community, but the effect it would have on
its environment as well. The environmental effects of today will lead to
the co-evolutionary changes in the open source movement of tomorrow.
2. Problem of Pushing Open Source into New Areas
A failure to understand the co-evolutionary relationship of the open source
community and its environment can lead to other potential threats to the
complex nature of the system. For example, taking for granted the high technical
standards that open source software has thus far been able to attain could
lead to mistaken initiatives. It could lead to initiatives to push open source
software into new forums for which it may not be useful, and in fact, for
which the complex approach may not necessarily be appropriate. Specifically,
attempts to make particular open source programs the standard for everyone
n270 - techies and non-techies alike - may be misguided. n271 Complex
systems are built upon the system's history [*674] - what is
possible in the system now is a result of where the system was at prior points
in time. n272 This means that what will be possible in the future is
dependent upon intervening events. To move the open source system along more
rapidly toward a goal it may not achieve for some time (or may never achieve)
is to reject the complexity that lead to the best qualities of the open source
software.
The potential for mistaken initiatives applies to the issue of linearity
in an important way. To understand how, it is first important to consider
the issue of free riders with regard to open source software. Commonly referred
to as a free-rider "problem," the effects of free riders on open source development
can vary from good to bad. Some level of free riders n273 is good.
The esteem or respect awarded a developer is dependent upon the baseline
of participation. n274 If everyone is participating at a high level,
for the developers to get respect they must participate at an even higher
level. However, they may alternatively choose not to participate at all,
if the esteem is not worth the effort that would be required. If there are
free riders, then the baseline for respect is much lower, and participation
at even low levels will garner peer esteem. Thus, it is reasonable to expect
the system to maintain a rough balance between the number of participants
and free riders. Too many free riders will lower the effort required to get
esteem, leading to more participation. Too much participation will raise
the bar so high that some participants will drop out, increasing the number
of free riders.
The problem in this situation comes from the fact that, while the number
of potential free riders is unlimited, there is an upper limit on the number
of participants. In particular, the non-hackers that are intended to be reached
by the widespread adoption of, for example, Linux, may reasonably be expected
to have little or no capability to participate as developers. Further, these
users have a much lower ability to appreciate good programming, and thus
less [*675] ability to award esteem. n275 This particular
element of the market may be unable to be anything but free riders on the
basic open source model. What these users do have to offer in terms of compensation
is money. Thus, by purchasing software they could fund an open source project
that would create software that met their specific needs. However, this process
(software for money) is much more linear in nature than the complex system
of project leader-user/developer interaction and feedback that leads to the
complexity of the current open source method. Non-techie users would be less
attentive to the tagging mechanisms. Since they would not be making changes
to the source code, they would be less likely to care about the Open Source
certification mark, open source licenses or norms that help distinguish cooperators
from opportunists. It would be reasonable to expect no flow of recycled code,
and they would likely be much less active in the niche-filling that occurs
as the result of new product development.
Having a linear model of software development for these users is only a potential
outcome. There is no empirical evidence of how little these users would contribute,
or how much contribution is actually need. However, two important points
can be derived from the forgoing analysis. First, linear models of software
development may be entirely appropriate for some market segments. n276
[*676] Second, the tendency of the segment toward linear development
models, to the extent it occurs, could needlessly interfere with the complexity
of the regular open source model. It could be preferable to develop this
technology as a separate entity, if possible, to avoid any "pollution" of
the existing, complex, open source approach.
3. The Problem of Closed-Source Development
Although, as noted in the prior section, a linear approach to software development
need not be closed-source, the counter-proposition may be true. That is,
it may be the case that proprietary software development inherently follows
a centralized, linear mode. Much of the ability of proprietary developers
to effectively control use of their copyrighted material comes from limited
access to this material. n277 Thus, the closed-source development model
almost certainly requires a barrier to the user/developer feedback and interaction
typical of the open source model. This will also mean that the recycling
of code is likely to be limited to "in-house" developers, if such recycling
occurs at all. Similarly, the only flows occurring in the proprietary software
system will likely consist of the money-for-software exchanges. Finally,
interactions are much more rarely likely to cause changes in the system.
While customers can kill a product they have no desire for, they have almost
no ability to exert influence on the characteristics of the products available
to them. n278 The centralized control necessary [*677]
to bring about the secrecy critical to protection of intellectual property
points to a linear development model as the natural consequence of proprietary
software development.
4. Intellectual Property Problems
The link between closed-source software development and linearity can pose
problems for open source software, in particular, through intellectual property.
By invoking copyright or patent restrictions in code, n279 proprietary
companies can attempt to impose their centralized model of development on
the open source community by forcing them to go through the proprietary company
for access, or to find some route around the protected code. Further, the
open source movement must be careful to ensure that projects remain open
source through future iterations, and are not cut off from the open source
community at some future date through the use of intellectual property. This
calls for the use of open source licenses, such as the GPL, that do not allow
future versions or modifications to be "taken private."
To ensure that open source projects are not taken private also requires that
the license originally attached to the program "apply to all to whom the
program is redistributed without the need for execution of an additional
license by those parties." n280 The validity of this type of open source
license has not yet been confirmed by any court. n281 Its validity
may be supported by recent cases upholding the validity of roughly similar
"shrinkwrap" licenses. n282 [*678] The outcome of a new
proposed uniform state act, the Uniform Computer Information Transaction
Act (UCITA), n283 may play a substantial role in open source license
validity as well. UCITA supports the validity of mass market licenses generally.
n284 As currently written, if no specific duration of a license is specified,
the default is a perpetual license. n285 This is consistent with the
understanding in open source licenses. However, source code licenses within
the proprietary software community are rarely for a perpetual term. Thus,
the UCITA, if adopted by the states, could help resolve some of the uncertainty
regarding open source licenses.
B. Chaos
Although there are a wealth of problems that could push the open source
model toward linearity, there are also problems that could push it toward
chaos. Specifically, these problems include code forking, the failure of
project leaders and incompatibility of open source licenses.
1. Code Forking
Strong norms against formal code forking n286 exist in the open source
community. n287 However, the marketing of open source software to businesses
stresses the ability of companies to change the source code themselves. Many
of the code changes may be passed on to the seller based on the hope of incorporation
into future releases of the product. There is also the potential for businesses
[*679] to simply keep these changes for themselves. It is not necessarily
the case that they would do so out of a desire to market the product themselves,
but rather, simply because there was no institutional awareness that these
changes should go back to the community, or that there would be any value
to resubmitting them.
If such a tendency were present, over time the products being used by businesses
would develop vast numbers of informal "versions" of the product. Essentially,
the project would no longer have a "memory of the past" or the same ability
to evolve that is expected of complex systems. Rather, as is common in chaotic
systems, the code would develop along one path, with little to no understanding
of the history of development within each of these smaller versions. These
varying versions may propagate as future employees alter their own version
of the software to deal with hardware and software changes, or as the code
is passed between companies through merger or buyout. Typical of chaotic
systems, these programs will change, but not necessarily in an "evolutionary"
manner. Rather, the changes will bear only a limited relationship to the
fitness of the code given the current environment.
To avoid this result, it is important to continue supporting the norms against
code forking. However, more is obviously needed. Sellers of open source products
must also be involved in the code's development. This will allow the feedback
of customers to be incorporated into the formal project, giving businesses
greater incentive to submit code changes, and allowing the project to "learn"
from these changes. Maintaining the quick release rate that is currently
common to open source projects is important as well. The rapid release rate
will help ensure that projects do not have enough time to evolve too far
along different paths in individual companies. It will also encourage businesses
to submit changes to avoid the need to constantly fix and re-fix new version
of the program to deal with their particular environments.
2. Poor Project Leadership
It is important to reiterate the role of project leaders in the success
of open source projects, particularly in light of the criticisms of other
types of leadership in the prior section. Indeed, just as the chaotic nature
of code forking helps balance the potentially linear [*680] nature
of project leadership, project leadership is necessary to balance chaotic
potentials of the open source model. First, there is the obvious potential
for increased code forking due to the absence or inaction of project leaders.
It was noted n288 that a disbelief in the potential for users' changes
to be implemented in new versions of the software could lead the users to
keep the changes to themselves. n289 This was shown to potentially
lead to numerous unique version of the software, resulting in a more chaotic
open source project.
Excessively weak project leadership can lead to failure on the part of users
to resubmit contributions and an increase in the chaotic nature of the system.
Specifically, this could come from a lengthening of the intervening time
between releases. Part of the strength of open source software comes from
the rapid updating of project versions. n290 This was seen to encourage
contribution of users' individual changes back to the project. Failure to
make final decisions regarding disputes over the proper course for the project,
which is part of the leader's role, could slow the release of new project
versions as there is an attempt to achieve some consensus regarding the technical
development. n291 This may be part of the reason why the "benevolent
dictator" model of project leadership is seen to be more stable and less
complicated than the committee model. n292
3. Inconsistent Open Source Licenses
A final problem that could lead to greater chaos in the open source community
is inconsistent open source licenses. "The propagation of many different
and incompatible licenses works to the detriment of Open Source software
because fragments of one [*681] program cannot be used in another
program with an incompatible license." n293 The inability to use a
given program in conjunction with others or as part of a package could result
in several types of problems. First, if the program fills a niche necessary
to the package, it will be necessary to develop a new, equivalent, product.
Essentially, a type of forking must occur to create a product that can be
released under a compatible license. Further, if sufficient software exists
under incompatible licenses, a number of packages might arise, based upon
the number of incompatible open source licenses. Thus, the forking will be
repeated for each of the packages that are available.
Inconsistencies in open source licenses can further lead to an inability
to take advantage of lessons learned in past open source projects. Specifically,
the practice of recycling code from prior open source projects could be substantially
hindered by inconsistent license terms coupled with uncertainty regarding
a potential finding of copyright infringement by a court. n294 This
could discourage the recycling of code from other programs if the license
under which it was issued is inconsistent with the license under which the
current program is to be distributed. n295
[*682] Ultimately, this poses less of a potential problem than the
others in this section. A good open source definition can help ensure minimal
conflict among compliant licenses. It is also unlikely that there would be
a sufficient number of programs within each of the license categories to
lead to competing packages. Nonetheless, there exists the potential for such
a situation to develop, leading to greater chaos in the open source process.
VI. Impact of Complexity on Future Concerns
The prior sections have shown both the benefits that have already been found
as a result of the complexity of open source software development, and the
ways in which this complex nature may be maintained. So long as the practices
necessary for the success of the open source process are continued, there
is every reason to believe that many of the concerns expressed about the
future of open source software are unwarranted.
A. Reaction of Microsoft
One of the biggest issues facing the open source community is the potential
reaction of Microsoft to counteract the success of open source software.
n296 Microsoft can be expected to use all the [*683] tools at
its disposal to fight the open source movement - including code, norms, the
market and law. n297 In the Halloween memos it expressed an intent
to use code by taking highly commoditized, simple protocols and "extending
these protocols and developing new protocols, [to] deny OSS projects entry
into the market." n298 Further, although the memos indicate a concern
that Microsoft's FUD n299 tactics may be ineffective on open source
software, n300 its use of tactics of some kind n301 to get user
and developer mindshare can be expected. Finally, Microsoft may well attempt
to utilize its market position to force software vendors and OEMs to choose
between Microsoft and Linux. n302 The Halloween memos indicate that
law may be used by Microsoft as well, in particular, the use of [*684]
patents and copyright for "combatting Linux." n303
The tactic of Microsoft to de-commoditize technical standards can be successful
only if it achieves sufficiently widespread implementation of its modified
technology to make its version the de facto standard. However, for many of
the technologies for which this would be necessary, Microsoft may not have
sufficient market share to do so. With network technologies, the participants
in the IETF, World Wide Web Consortium (W3C), and other Internet standards
organizations could oppose Microsoft's competing, proprietary "standards."
Other companies will have incentives to fight Microsoft on this front as
well. n304 Thus, at least within the server market, where Microsoft
has less than 50% market share, n305 it is unlikely that sufficient
market presence exists for it to force a de facto standard.
Such an attempt may also have the effect of garnering greater support for
the open source community, given the dim light in which such anti-competitive
conduct is viewed, particularly because of Microsoft's recent antitrust problems.
Although not a necessary trait of the open source community, there seems
to be an [*685] impression that anti-Microsoft sentiment plays
a role in the interest and participation of some in the open source movement.
n306 Further anti-competitive conduct would reinforce the perception that
open source software, and Linux in particular, is a legitimate alternative
to Microsoft. n307 This would also support the conclusion that Microsoft
readily engages in questionable, anti-competitive conduct. Thus, efforts
by Microsoft may well be unable to provide sufficient code constraints to
inhibit open source software, while having the effect of reinforcing pro-open
source opinions.
Efforts to constrain OEMs and software developers through the use of Microsoft's
market position, to the extent it would have an effect, could also be frustrated.
If Microsoft is successful in controlling OEMs and software vendors, this
could drive innovation in the open source community. With no commercial options
available, Linux applications and utilities could be expected to be developed
by the open source movement to fill the gap caused by Microsoft's control.
n308 Further, if Linux is not able to be pre-installed on machines, this
would provide strong incentives for innovation among commercial Linux distributors
to provide better, more user-friendly instillation tools. Alternatively,
feedback effects from the current trend of commercial software application
developers porting software to Linux n309 could lead to increasingly
steep growth in the market. This could lead to a larger market for open source
software, providing revenue to fund more development, [*686]
and further reinforcing the status of the community.
The challenges posed by the use of intellectual property as a weapon clearly
could have serious consequences for the open source community. n310
One outcome of such a challenge would be forcing to the forefront a consideration
of the incentives and motivations for the existence of intellectual property
in the online world. A potential resolution of these issues could lead to
Microsoft's ability to restrict the use of code by open source programmers.
This would test, once and for all, the proposition that the open source movement
is unable to engage in innovation. n311 Complexity theory suggests
that the community would respond by the development of innovative software
technologies that would allow the circumvention of Microsoft's patents and
copyrights. Such innovation may convince outsiders of the full extent of
open source's potential, more than compensating for the loss due to legal
restrictions on code.
An attempt by Microsoft to create its own version of the "open source" concept
could be dealt with by the open source community as well. Attempts to co-opt
the open source term provides both the opportunity to reinforce community
standards regarding open source requirements, as well as educate others through
the forum provided by the media coverage. Indeed, an attempt to dilute the
open source requirements by Microsoft might be more likely to elicit a strong,
immediate response n312 from the open source community than similar
conduct from a less-vilified software developer. Attempts to formally attach
the "Open Source" term to its software could also lead to a trademark suit
against Microsoft, n313 further reinforcing the true requirements of
open source software [*687] and providing yet another forum for
introducing this concept to others. Thus, the response of the open source
community to these attacks could strengthen the movement as a whole.
B. Clash of Norms
Open source cultural norms are critical to the success of open source software.
n314 However, efforts to "evangelize" the open source cause has led to a
clash of norms between what is accepted in an online environment and what
is the traditional behavior in the "real world." This conflict takes two
forms. The first type involves individuals engaged in behavior that is consistent
with the norms of the offline world, but seem violative of certain online
norms. n315 The alternative problem occurs when behavior that is consistent
with online norms is misinterpreted according to the norms of the offline
world. n316 These conflicts could lead to several problems. Notably,
open source community norms could be contaminated by these alternative norms,
n317 or the impression of the [*688] open source community in
the real world could be harmed by the conflict. n318
Adaptation as a result of these norm clashes could occur in a number of ways.
For example, the emphasis courting commercial interests may further embolden
members of the open source community who attach moral significance to free
software to be more vocal about their message. n319 This could provide
an opportunity to reinforce the fundamental norms upon which the community
was built. The offline world could adapt as well. As it gains greater exposure
to the online world, its cultural expectations will change to allow different
interpretations for online behavior than that same behavior would have in
the real world. n320 While the precise changes that might occur are
purely speculative at this time, the adaptive nature of the complex open
source method indicates that the system should successfully n321 endure
future normative challenges.
[*689]
C. Market Competition
As the open source marketplace has developed, and companies have begun to
make money on open source software, fears have begun to arise regarding competition
within this market. Specifically, there are fears that if Linux can de-throne
Microsoft in the operating system market (or some substantial portion thereof)
Red Hat will simply hold the position once held by Microsoft. n322
These concerns seem unwarranted, due to the nature of the open source community.
The first reason why Red Hat will not be able to control the operating system
market in the way that Microsoft has is due to the open source licensing
practices. Consistent with the GPL under which Red Had issues Linux,
n323 they are unable to restrict distribution of Linux. Thus, Red Hat cannot
threaten Original Equipment Manufacturers (OEMs) like Dell or Compaq by requiring
control over the desktop, for example, in exchange for continuing to supply
them with Linux. OEMs could get a technically equivalent Linux operating
system from any of a number of competing Linux distributors. n324 Unlike
Microsoft, which is the only reliable source of Windows, in some sense, Red
Hat is just one of many distributors of Linux. The OEMs could even continue
to use the Red Hat Linux software they already obtained, since the GNU GPL
gives [*690] them the "right to redistribute anything it wants
as long as it continues to make the source code available." n325
However, Red Hat is not just one of many distributors of Linux - it is arguably
the most prominent. n326 Red Had could require OEMs to stop using the
"Red Hat" name with the products that are distributed. Thus, Red Hat could
theoretically leverage its brand equity to try to engage in anticompetitive
activities. However, it is likely that this would only be a viable threat
on the smaller OEMs. Large OEMs, like Dell and Compaq, have substantial brand
equity themselves. And in a relative sense, Red Hat could lose more from
not being distributed with one of these prominent OEMs than the OEMs would
lose from not being able to use the Red Hat name. n327 Thus, the GPL,
by leaving Red Hat with only its brand equity to leverage, seems to provide
fairly strong protection against anticompetitive behavior.
To generalize from the specific example of Red Hat Linux, in order to take
advantage of the benefits that the complexity of open source software brings
to the technical quality of code, businesses must adhere to an open source
license. n328 However, this forces these businesses to put themselves
on equal footing, technologically, with all their competitors. Thus, even
if a market, such as that for operating systems, is a natural monopoly, any
monopoly benefits would accrue to Linux generally, rather than to any specific
Linux vendor. Because multiple vendors can offer equivalent technologies,
competition in other areas, such as customer support, can occur. n329
Flows in the system should tend to make not only technological improvement
spread throughout the system, but economic improvement as well. Thus, increases
in the number of users of Linux generally will flow (although perhaps not
in equal amounts) to the various vendors of Linux, rather than to one particular
[*691] company. n330
The flow of technology to all vendors can further facilitate exploitation
of a larger segment of the potential market through price discrimination.
Customers can get the basic Linux operating system technology (presently)
for as little as $ 0. n331 Customers able to pay more can purchase
essentially the same basic technology, but with greater support, installation
or other benefits. Thus, competition can occur not only in the market generally,
but between vendors targeting the various economic segments of the market.
D. Civil Liability
The issue of civil liability could be important to the future of open source
software. Obviously, since many programmers are giving the software away
for free, the potential costs of defending a lawsuit and paying a judgment
would be prohibitive. n332 This could theoretically discourage participation
in the open source process substantially. n333 Specifically, threat
of lawsuits based on contract or tort theories of recovery exist that could
be problematic for open source software.
1. Contract
Relevant to open source software, the U.C.C. implies warranties of merchantability
n334 and fitness for a particular purpose n335 into [*692]
contracts. n336 Liability for breach of implied warranties occur if
the goods do not meet the standards of these warranties. n337
The current approach taken by open source licenses is to include a term disclaiming
all warranties. n338 This approach would appear to provide a reasonable
likelihood of success in disclaiming implied warranties. Disclaimers of implied
warranties will be upheld where they are conspicuous n339 and nonambiguous.
n340 However, [*693] a disclaimer has been found unconscionable
n341 in such potentially relevant situations as an adhesionary contract,
n342 or where a complex technology is involved, and the buyer has little
knowledge, making them dependant upon the seller to determine suitability.
Further, resellers of a product may not be protected by disclaimers by the
developers. n343
2. Tort
Software developers, including those in the open source community, could
also be liable for negligent n344 or strict liability n345 torts.
n346 Several factors may prevent tort liability for software. First, many
states follow the economic loss rule, disallowing damages that are purely
economic, such as loss of data. n347 Second, strict products liability
generally does not apply to information. n348
[*694]
3. Potential Resolutions
While there are technically numerous ways that this situation could be resolved,
the solutions fall within two main categories. First, the law could tend
to impose civil liability on the open source project leaders and distributors.
Alternatively, civil liability could generally be held to be unavailable
for disclaimed warranties or torts. However, all either of these amount to
is an allocation of risk with regard to problems from open source software.
If, as under the first scenario, the risk is substantially or largely imposed
on the open source community, the community could be expected to adapt in
a manner that would allow it to bear this burden. The primary result of this
adaptation could be expected to be a shift in resources and distribution
away from the free and inexpensive Internet-distributed versions of software
and toward for-profit businesses such as Red Hat and Cygnus. The threat of
lawsuit may deter some potential project leaders due to the potential economic
hardship it could cause. This would mean that development, when it occurs,
would be led by open source businesses who could bear the burden of lawsuits.
It could also lead to non-profit or other organizations that would exist
to facilitate open source development. n349 The likely judgment-proof
nature of individuals distributing software for free may lead customers
n350 to obtain software from vendors that have the resources to pay a civil
judgment. Thus, the organizational structure of the open source community
as a whole could adapt to allow the continuance of the open source community
despite the threat of liability. However, the extent of that change cannot
be reasonably determined at this time. If the potential number of users that
would avail themselves of this liability is substantial, the changes will
be more prevalent than if the number of users who would do so is more limited.
[*695] Without the threat of liability, as under the second category,
little change in the open source community would likely be necessitated.
The market, rather than the law, may nonetheless lead to some changes. In
particular, customers that would prefer not to bear the risk of loss themselves
may create demand for vendors who, for example, do not disclaim the implied
warranties. The magnitude of this demand will determine the scope of changes
that occur as open source vendor policy may change to compete for these customers.
However, the customers may also adapt, by choosing the potentially more efficient
option of insuring against the potential loss due to software problems.
n351 Either way, the open source methodology can be expected to adapt and
remain.
Conclusion
The success of open source software as an alternative to traditional economic
intellectual property incentives result from the complex nature of the open
source development model. However, the only way to ensure that this highly
technical achievement continues is to ensure the continued complexity of
the open source model. While this may provide a general guideline for others
to attempt to replicate this incentive structure in similar contexts, it
also highlights the fact that specific activities can pose a threat to the
beneficial complexity. Ultimately, the open source community and those wishing
to adopt its methods must embrace and encourage the complexity of their situations.
If this is not done, at best, substantial effort will be wasted; and at worst,
the system could be pushed out of its complex state, with resulting loss
of product quality and adaptability.
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.
n142. See M. Mitchell Waldrop, Complexity: The Emerging Science at the Edge
of Order and Chaos 43 (1992).
n143. See id.; see also Peter Coveney & Roger Highfield, Frontiers of
Complexity: The Search for Order in a Chaotic World (1995); John H. Holland,
Hidden Order: How Adaptation Builds Complexity (1995); Stuart Kauffman, At
Home in the Universe 19 (1995). For discussions of complexity geared toward
the legal audience, see J.B. Ruhl, Complexity Theory as a Paradigm for the
Dynamical Law-and-Society System: A Wake-Up Call for Legal Reductionism and
the Modern Administrative State, 45 Duke L. J. 849 (1996).
n144. Restatement (Second) of Agency, 1, comment e.
n145. Holland, supra note 143, at 87.
n146. Id. at 88.
n147. See id.
n148. See id.
n149. See id. at 89.
n150. Holland, supra note 143, at 53. Such a rule would be "if hungry, then
look for area with characteristic X," would be harder to evaluate, because
it does not (necessarily) result in helpful feedback from the environment.
However, if areas with characteristic X are a likely source of food, the
existence of the initial rule would allow the subsequent invocation of the
rule "if you have food, then eat food." Thus, the mechanism must have some
way of rewarding stage-setting rules.
n151. See id.
n152. See Holland, supra note 143, at 90.
n153. This is commonly referred to in the literature as "sexual reproduction,"
but the term "combination" will also be used.
n154. "Chemistry" is a related concept that applies to a wide variety of
complex systems:
The first source of chemistry's power is simple variety - unlike quarks,
which can only combine to make protons and neutrons in groups of three, atoms
can be arranged and rearranged to form a huge number of structures. The second
source of power is reactivity: structure A can manipulate structure B to
form something new - structure C.
Waldrop, supra note 142, at 314.
n155. See Holland, supra note 143, at 34-37.
n156. See id. at 37.
n157. See Waldrop, supra note 142, at 170 (quoting John Holland).
n158. Holland, supra note 143, at 11.
n159. See id. at 103-04.
n160. See id. at 15.
n161. Id. at 23.
n162. See id. at 14-15.
n163. See id. at 23
n164. See id.
n165. Robert Jervis, System Effects 29-32 (1997).
n166. For example, the purchaser of a home pays a contractor, who pays a
tradesman, who in turn buys food, et cetera. At each stage, some of the money
is saved and the rest is used for expenses. The effect of the initial contract
is multiplied when its total effect is traced through the network. See Holland,
supra note 143, at 23-25.
n167. See id. at 25.
n168. John Holland uses the example of a three node system that turns steel
into automobiles. One node supplies the ore, one node processes the ore into
steel, and one node turns the steel into cars. He assumes one unit of ore
produces one unit of steel which produces one unit of car. Finally, he assumes
the steel producer sends half its output to the car manufacturer. If the
cars are driven until they are unusable, then an input of 1000 units of ore
will result in 500 units of cars. However, if 3/4 of the steel from cars
is recycled, the same input of 1000 units of ore from the ore producer, when
added with the units of steel recycled, will allow 800 cars to be produced.
Thus, recycling can substantially increase the resources at each node. See
id. at 25-26.
n169. Id. at 27.
n170. See id. at 27-28.
n171. See id.at 29-30.
n172. This is sometimes referred to as a "fitness landscape." This landscape
consists of "hills" of higher levels of fitness, and "valleys" of lower levels
of fitness. See Kauffman, supra note 143, at 161.
n173. See Waldrop, supra note 142, at 151. An analogy would be trying to
predict every possible move that could be achieved in chess, and from that
determine what the "optimal" course of action. In reality, one can only predict
a limited number of moves in advance, based upon the particular moves of
a particular opponent. See id.
n174. See Per Bak, How Nature Works: The Science of Self-Organized Criticality
1-2 (1996).
n175. See id. at 11.
n176. Holland, supra note 143, at 12.
n177. See id.
n178. This is referred to as "nonlinearity." "Actions often interact to produce
results that cannot be comprehended by linear models. "Linearity involves
two propositions: 1) changes in system output are proportional to changes
in input... and 2) system outputs corresponding to the sum of two inputs
are equal to the sum of the outputs arising form the individual inputs.'"
Jervis, supra note 165, at 34.
n179. Holland, supra note 143, at 31.
n180. Jervis, supra note 165, at 17.
n181. Waldrop, supra note 142, at 45. It should be noted that not only positive
feedback is present in complex systems. Complex systems consist of a mixture
of positive and negative feedback lead to complexity. See id. at 139. Complex
systems, including economies and societies must maintain a balance of order
and chaos. "Like a living cell, they have to regulate themselves with a dense
web of feedbacks and regulation, at the same time that they leave plenty
of room for creativity, change and response to new conditions." Id. at 294.
n182. Id. at 142.
n183. Kauffman, supra note 143, at 29.
n184. See, e.g., Waldrop, supra note 142, at 230-31, 292-94; Coveney, supra
note 143 at, 271-77; Ruhl, supra note 143, at 890-91 (discussing the need
of a complex system for a blend of elements of chaos and order).
n185. This is also indicated by the "sandpile" experiments of Per Bak and
others. He suggests the consideration of a sandpile - first being built on
a flat surface by dropping individual grains of sand, leading to a pile.
Initially, grains stay pretty much were they land, and disturbances in one
area have little effect elsewhere. This is analogous to a linear state. Eventually
the slope of the sandpile stabilizes, as newly dropped grains of sand are
balanced by sand falling off the edge of the pile. This is like a complex
state. Finally, one could imagine dropping sand in such magnitude, or in
the appropriate locations so that an "avalanche" of sand would result. This
could be considered the chaotic state. See Bak, supra note 174, at 50-51.
n186. Coveney, supra note 143, at 91.
n187. Id. at 99.
n188. Id.
n189. Id.
n190. Id.
n191. See Waldrop, supra note 142, at 229-30. First-order phase transitions
are like the familiar transition of water from ice to liquid at 32[su'o']
F. The molecule is either in the solid, ordered state, or the chaotic, liquid
state. Second-order transitions do not impose a sharp either-or choice on
molecules. See id. at 229. Rather, at points near the transition (both above
and below it), there are substantial regions "where order and chaos intertwine,"
- in other words, regions of complexity. Id. at 230.
n192. See id. at 230.
n193. See Ruhl, supra note 143, at 891 ("Too many fixed point and limit cycle
attractors [characteristics of ordered systems] drag the system into stasis.
Too many strange attractors [characteristics of chaotic systems] drag the
system into chaos.") Cf. Waldrop, supra note 142, at 43 (noting that when
industries mature, the tend to be more stable, and amenable to description
by tradition, linear, economic theory).
n194. Stuart A. Kauffman, The Origins Of Order 29 (1993).
n195. Ruhl, supra note 143, at 891.
n196. Waldrop, supra note 142, at 279. Indeed, studies of traffic jams have
found that states with jams of various sizes are better than highly ordered
systems with cars going slowly. The latter state would have a higher throughput
of cars theoretically, but turns out to be "catastrophically unstable," and
"would collapse long before all the cars became organized." Bak, supra note
174, at 198.
n197. Id.
n198. See Coveney, supra note 143, at 329-31.
n199. Bak, supra note 174, at 30.
n200. An example of this "whole is less than the sum of the parts" idea may
occur in the case of fibrillation of the heart. When this occurs, the individual
muscle cells respond to impulses correctly, yet the heart as a whole "is
never all contracted or all relaxed.... The parts of a fibrillating heart
seem to be working, yet the whole goes fatally awry." James Gleick, Chaos:
Making a New Science 283-84 (1987).
n201. See Waldrop, supra note 142, at 295. To return to Bak's use of the
sandpile model, supra note 185, he suggests dropping wet sand on the sandpile.
This will have greater friction than regular sand. Initially, as the wet
sand sticks, there will be smaller, more localized, avalanches. However,
this will cause the sandpile to grow steeper, leading the avalanches to grow.
Eventually, the pile will return to a state with system-wide avalanches,
but with a higher sloped pile. (A similar example could be done with dryer,
rather than wetter, sand. The pile would leave the complex "equilibrium"
for a while, but eventually return to the critical state, only in this instance
with a steeper slope). See Bak, supra note 174, at 51-52.
n202. See supra Section I.A.
n203. This is not intended to be an exhaustive list - other agents could
be added. For example, individuals who do not participate in open source
software could be considered agents as well, for the important role that
they play in the reward system of the open source community. See infra, note
273-274 and accompanying text.
n204. See supra notes 149-150 and accompanying text.
n205. See supra Section I.D.
n206. See id.
n207. See id.
n208. See id.
n209. See Raymond, Ownership and Open Source, supra note 41.
n210. See Richard H. McAdams, The Origin, Development and Regulation of Norms,
96 Mich. L. Rev. 338 (1997) (discussing the development and nature of esteem
norms).
n211. See supra Section I.B.
n212. See supra Section I.I.1.
n213. In the case of Linux, it was initially developed to be like a Unix
operating system. See Torvalds, supra note 12, at 102.
n214. See Perens, supra note 101, at 174 (discussing the creation and use
of the open source mark); The Open Source Page (last modified Apr. 1, 1999)
<http://www.opensource.org/>.
n215. See Open Sources: Voices from the Open Source Revolution, supra note
3, app. B at 253-54 (the Open Source definition, version 1.0); The Open Source
Definition (last visited Jan. 30, 2000) <http://www.opensource.org/osd.html>
(version 1.7).
n216. See supra Section II.D.
n217. See id.
n218. See Eric A. Posner, Altruism, Status, And Trust In The Law Of Gifts
And Gratuitous Promises, 1997 Wis. L. Rev. 567, 579-80 (1997).
n219. See id. at 579.
n220. Id. at 579-80.
n221. See id. at 581.
n222. See Marcus Maher, An Analysis of Internet Standardization, 3 Va. J.
L. Tech. 5 at PP 18-19 (last visited Jan. 30, 2000) <http://vjolt.student.virginia.edu/graphics/vol3/home<uscore>art5.html>
(1998).
n223. Cf. Leander Kahney & Polly Sprenger, Apple's Open-Source Movement
(last modified Mar. 16, 1999) <http://www.wired.com/news/news/technology/story/18503.html>
(discussing Apple's claim to an understanding and the beginnings of going
open source with their software, and the concerns expressed by Bruce Perens
that licenses of IBM and Apple may not fully comport with the Open Source
definition).
n224. See supra Section III.A.
n225. For the roles of various parties, see, e.g., supra Section I.A.3.
n226. See Stallman, Overview of the GNU Project, supra note 14.
n227. The GNU GPL begins with a preamble discussing the justifications for
the GPL. See GNU General Public License, supra note 99.
n228. See supra, Section I.F.1.
n229. See What is the Copyleft? (last modified Apr. 11, 1999) <http://www.fsf.org/copyleft/copyleft.html
#What is the Copyleft?>.
n230. Torvalds states that he chose the GPL because that was the license
under which the GCC compiler was issued. See Torvalds, supra note 12, at
107.
n231. See, e.g., Raymond, The Cathedral and the Bazaar, supra note 28 (noting
that he chose to use (and write about) the open source development process
because of his experience as a contributor to GNU projects, and evidence
from the successful development of the Linux kernel that the process could
be used on a larger scale).
n232. For example, the importance of modularity was recognized by Linus Torvalds,
and built into the Linux kernel, see Torvalds, The Linux Edge, supra note
12, at 108. Richard Stallman also recognized the value of modularity, building
it into, for example, the Emacs editor. See EMACS: The Extensible, Customizable
Display Editor (last modified Feb. 16, 1998) <http://www.gnu.org/software/emacs/emacs-paper.htmlSEC1>.
n233. Modular code not only is of greater quality (direct feedback), but
allows for easier modifications, project maintenence and recycling of code
(stage-setting). See supra Section I.E.
n234. Increased ease of code recycling is a natural consequence of modularity,
due to the greater ease of identifying complete sections of code that perform
a particular function, and greater ease in copying only the useful parts
of the code.
n235. See Stallman, Overview of the GNU Project, supra note 14.
n236. See Moody, The Greatest OS That (N)ever Was, supra note 18.
n237. These programmers used familiar patterns (the look and feel of the
Unix operating system) and used them as a model (either intentionally or
implicitly) for what a good operating system should be like.
n238. Stallman heard about the "Free University Compiler Kit," or "VUCK,"
which was designed to handle multiple languages, including C and Pascal.
However, Stallman discovered that the university was free, but the compiler
was not. See Stallman, supra note 29 at 57. This shows the imperfection of
some tags. The "free" tag was misleading in this case, and has been argued
to be misleading for other reasons as well. This lead to a move (by some)
the open source tag, which is less likely to cause confusion among as large
a group of people. Further advancements may be yet to come.
n239. For a discussion of the signaling function of gifts in the open source
process, see supra Section III.B.1.a.
n240. See Stallman, Overview of the GNU Project, supra note 14.
n241. See id.
n242. See Stallman, Linux and the GNU Project, supra note 11.
n243. See id.
n244. See, e.g., Torvalds, supra note 12 at 110-11 (discussing future developments
needed for future applications of Linux in new settings).
n245. See, e.g., Tiemann, supra note 129; Young, supra note 57 (discussing
their business of adding customer service and support to the Linux operating
system).
n246. See Kauffman, At Home in the Universe, supra note 143, at 295-96.
n247. This is happening with the core elements of Perl. See Larry Wall, Diligence,
Patience, and Humility, in Open Sources: Voices from the Open Source Revolution,
supra note 3, at 127, 140. The same thing is expected with Linux. See Torvalds,
supra note 12, at 110.
n248. This may not mean best in every category potentially applied to the
program. Instead, it means best in an overall sense.
n249. See, e.g., Mitchel Resnick, Turtles, Termites and Traffic Jams 119-44
(1994).
n250. In other words, that a phenomenon came about or should come about through
the efforts of some centralized command or leader.
n251. In other words, that a phenomenon came about or should come about through
growth from some preexisting inhomogeneity or element in the environment.
n252. See Resnick, supra note 249, at 123-24.
n253. See, e.g., Halloween I, supra note 35 (stating that the lack of "visionary
leadership" will hold the open source movement back from true innovation);
David Bollier, The Power of Openness - A Critique and a Proposal for The
H20 Project (last modified Mar. 10, 1999) <http://www.opencode.org/h2o>
("the rich latencies of this Internet-facilitated phenomenon may never develop
if a new kind of networking leadership does not coalesce to assert the important
values that can only flourish in an environment of openness" which, he proposes,
could be filled by a new organization "H2O"). Another variation on this theme
are those who provide a list of ways to make money on open source projects.
See, e.g., The Business Case for Open Source, supra note 129; <http://www.opensource.org/for-suits.html>;
Hecker, Setting Up Shop, supra note 75; Halloween I, supra note 35. While
for the most part, these are merely lists of approaches that have been successful
thus far, there is a danger that, implicit in reading the list could come
the idea that these are the only categories of activity, and one can follow
them, or forget about making money. In reality, any effort to provide some
wooden, formalistic business models, no matter how clever, will be unable
to adapt and evolve to meet future challenges.
n254. Resnick, supra note 249, at 125.
n255. Id. at 137.
n256. Id.
n257. Id. at 138-39.
n258. In other words, meta-agents have different properties than their sub-agents
or the mere sum of these agents, and meta-meta-agents have different properties
than meta-agents, et cetera. See, e.g., id. at 139-41.
n259. For a discussion of the role of project leaders, see, supra Section
I.C.4.
n260. See supra Section II.D.
n261. See, e.g., GNOME Project (visited Apr. 8, 1999) <http://www.gnome.org>
(project to develop a window manager).
n262. For a discussion of code forking as a chaotic system, see infra Section
V.B.
n263. See supra Section I.D.
n264. Indeed, Eric S. Raymond makes almost exactly this argument in support
of his proposed position of "open source evangelist." See Eric S. Raymond,
The Revenge of the Hackers, in Open Sources: Voices from the Open Source
Revolution, supra note 3, at 207, 213-15.
n265. As noted, supra notes 249-252 and accompanying text, the tendency to
look for centralized causes, processes and authority is a learned behavior
common to nearly all people. Indeed, even individuals with substantial experience
researching and studying complexity harbor such tendencies. See, e.g., Resnick,
supra note 249 at 119-20 (discussing such behavior in Marvin Minsky, who
"has though more - and more deeply - about self-organization and decentralized
systems than almost anyone else.")
n266. See, e.g., Waldrop, supra note 142, at 259-60; Holland, supra note
143, at 97; Resnick, supra note 249, at 142-44.
n267. For example, through the creation of the new organizations.
n268. Resnick notes that "being taught a list of rules isn't going to have
much effect on a firmly entrenched centralized mindset." Resnick, supra note
249, at 147-148. Rather, moving beyond the centralized mindset comes from
"participating in a culture that values and encourages decentralized thinking."
Id. at 148.
n269. Resnick refers to a similar experience in the area of the sciences.
"Just as children assimilate new information by fitting it into their preexisting
models and conceptions of the world, so do scientists... "In short we risk
imposing on nature the very stories we like to hear.'" Id. at 122.
n270. See generally, Raymond, The Revenge of the Hackers, supra note 264.
Underlying his statements that the open source community had "failed," or
was "losing," and his goals for the future is the idea that "winning" means
maximized adoption of open source software.
n271. Just as another example, the idea that "freedom" arguments should be
abandoned due to their claimed inability to recruit businesses to open source
software, see, e.g., id. at 212, mistakenly assumes that the open source
culture, which is so important to the success of the process, would unaffected
by the abandonment of the very principles that led many participants to join
the community in the first place.
n272. See Jervis, supra note 165, at 40.
n273. In the open source context free riders will refer to users of open
source software who do not contribute, or those who neither use open source
software nor contribute.
n274. See McAdams, supra note 213 at 365-67.
n275. Since they have no technical knowledge it is difficult for them to
evaluate the product, because they have only a limited baseline of comparison.
Another way of saying this, is that their esteem should be less valuable
(although probably greater than zero) because they do not have the knowledge
necessary to allocate it in the manner consistent with their own best interest
(maximum reward for the programming that is best, and thus helps them, minimal
or now reward for bad programming which does not help them much). Cf. id.
at 361-62 (discussing the importance of the ability to detect norm non-compliance
to the ability to effectively grant or withhold esteem).
n276. This is where the arguments of Richard Stallman, the Free Software
Foundation and others regarding the freedom that comes from open source software
become particularly important. Although the linear method of software development
is commonly associated, even within this paper, with proprietary software
development, it need not be. Linear methods could also follow the same licenses
as open source products, but with little anticipated availment of the source
code access by users. However, the economic focused arguments do not indicate
why open source should be preferred if a linear model can develop as high
quality of software and meet the needs of this market segment. However, if
there are freedom considerations associated with free software, it is worth
pursuing, even in the linear context, where the users have not practical
(i.e., improvement in software quality) benefits from doing so.
It is also interesting to note that Netscape's Navigator may be similar,
from the perspective of complexity vs. linearity, as operating systems. The
Mozilla open source project has had only about 30 voluntary participants
as compared to about 100 paid programmers. The project is also months behind
in its first beta release. See Ben Elgin, Open-Source Mozilla Project Struggles
for External Support (last modified Apr. 5, 1999) <http://www.zdnet.com/pcweek/stories/news/0,4153,1014274,00.html>.
These factors indicate that the Mozilla project may not be reaping the expected
open source benefits. However, the ultimate conclusions that can be drawn
at this point are merely speculative.
n277. Cf. Mark Stefik & Alex Silverman, The Bit And The Pendulum: Balancing
The Interests Of Stakeholders In Digital Publishing, 16 No. 1 Computer Lawyer
1 (1999) (discussing the importance of physical constraints on copying for
effective control of copyrighted material, and the potential role to be played
by trusted systems in the digital world).
n278. See The Customer Case for Open Source (last modified Nov. 28, 1998)
<http://www.opensource.org/for-buyers.htm>.
n279. See, Bruce Perens Preparing for the Intellectual Property Offensive
(visited May 11, 2000) <http://www.linuxworld.com/linuxworld/lw-1998-11/lw-11-thesource.html>.
n280. Perens, The Open Source Definition, supra note 101, at 179.
n281. See id.
n282. See, e.g., Hill v. Gateway 2000, 105 F.3d 1147 (7th Cir. 1997), cert.
denied 118 S.Ct. 47 (1997) (upholding arbitration clause in contract for
hardware and software, presented to the user upon receipt of computer); ProCD
v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996) (enforcement of a shrinkwrap
license included with software); Brower v. Gateway 2000, 676 N.Y.S.2d 569
(App. Div. 1998) (upholding arbitration clause in contract for hardware and
software, presented to the user upon receipt of computer); but see Step-Saver
Systems, Inc. v. Wyse Technology, 939 F.2d 91 (3d Cir. 1991) (shrinkwrap
license unenforceable as not part of contract terms made in an earlier phone
conversation). See also, Ira V. Heffan, Note, Copyleft: Licensing Collaborative
Works in the Digital Age, 49 Stan. L. Rev. 1487, 1509-11 (1997) (arguing
that open source licenses should be found valid under existing law).
n283. See Uniform Computer Information Transaction Act (last modified Aug.
4, 1999) <http://www.law.upenn.edu/bll/ulc/fnact99/1990s/ucita.htm>
[hereinafter UCITA].
n284. See id. 210.
n285. See id. 308(2)(B) ("... the duration of the license is perpetual as
to the contractual rights and contractual use restrictions if:... the license
expressly granted the right to incorporate or use the licensed information
or informational rights with information or informational rights from other
sources in a combined work for public distribution or public performance.").
The GNU GPL, for example, expressly allows modifications of GPL'd programs
to be distributed themselves, or as part of a new program, so long as the
new work is released under the GPL, thus falling within the terms of this
provision.
n286. What is meant by "formal" code forking is the creation of a new, competing
open source project based on the same underlying source code.
n287. See, supra Section I.D.
n288. See supra Section V.B.1.
n289. For example, when one of the GNU tools, GDB, went through a period
with "no strong maintainer," this resulted in GDB fragmenting "with hundreds
of people around the world making their own versions to meet their own needs."
Tiemann, supra note 129, at 79. When this was finally taken over by a Cygnus
engineer he collected 137 versions of the program that required integration.
See id. at 81.
n290. See supra Section V.B.1.
n291. See, supra Section I.C.4.
n292. See id.
n293. See Perens, The Open Source Definition, supra note 101, at 185.
n294. For example, the consequence of translating a program for a new platform
is not entirely certain. Compare Whelan Assocs. v. Jaslow Dental Laboratories,
797 F.2d 1222 (3d Cir. 1986) (holding that translating a program from one
source code to another to allow the program to run on a different platform
was a direct copying copyright infringement) with Q-Co Indus., Inc. v. Hoffman,
625 F.Supp. 608 (S.D.N.Y. 1985) (where a program was written in BASIC, a
program substantially similar in function and screen design written in PASCAL
was not an infringement). Direct or literal copying can constitute infringement
even if only a small portion is copied. See, e.g., Susan A. Dunn, Note, Defining
The Scope Of Copyright Protection For Computer Software, 38 Stan. L. Rev.
497, 512 (1986) (noting that, in one case, SAS Inst., Inc. V. S&H Computer
Sys. Inc., 605 F. Supp. 816, 822, 830 (M.D. Tenn. 1985), infringement was
found due to literal copying of less than one fortieth of one percent of
a program's code). Thus, the translation of an open source program for a
new platform and subsequent release under an incompatible license could be
deemed an infringement, as could the copying of some small portion of code
then used in a program released under an incompatible license.
n295. For example, if code from a GPL-licensed program were used in a program
released under an incompatible license, such use would fall outside the license
and would subject the developer of the later program to potential liability
for copyright infringement. This is true because the user of a GPL program
has a license to use and re-release parts of its code "under the terms of
[the GPL] License." See The General Public License, supra note 99. While
it might also, generally, be necessary to consider whether the license allowed
for the creation of derivative works by anyone other than the owner, the
Open Source definition effectively nullifies this for all open source software
by requiring that Open Source licenses allow for user modifications. See
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.")
n296. Microsoft has itself expressed the view that Linux poses a threat.
See Halloween I, supra note 35 (internal Microsoft memo discussing the nature
and threat of open source software generally); Linux OS Competitive Analysis
(last modified Aug. 8, 1998) <http://www.opensource.org/halloween/halloween2.html>
(hereinafter "Halloween II") (followup to Halloween I, discussing threat
of Linux to Microsoft); Chris Oakes, MS: Open Source is Direct Threat (last
modified Nov. 2, 1998) <http://www.wired.com/news/technology/0,1201,15990.html>
(noting Microsoft's acknowledgment of the validity of the Halloween memos,
and recognizing the threat to Microsoft posed by open source software); Nicholas
Petreley, Take Nothing for Granted (visited May 19, 2000) <http://www.linuxworld.com/linuxworld/lw-1998-12/lw-12-penguin.html>
(stating expectation that, after antitrust lawsuit ends, Microsoft will focus
its efforts to stopping open source software to a much greater extent). But
see Scott Berinato, Microsoft Exec Dissects Linux's "Weak Value Proposition'
(last modified Mar. 4, 1999) <http://www.zdnet.com/pcweek/stories/news/0,4153,1014079,00.html>
(noting the statements of one Microsoft executive that further studies of
Linux indicate it is less of a threat).
Although Linux, rather than open source software generally, would appear
to pose the greatest threat to Microsoft, their own memos indicate an intent
to "target a process rather than a company." See Halloween I, supra note
35.
n297. For a discussion of the regulatory power of these forces see, e.g.,
See, e.g., Lawrence Lessig, The Constitution of Code: Limitations on Choice-Based
Critiques of Cyberspace Regulation, 5 CommLaw Conspectus 181 (1997); Lawrence
Lessig, Constitution and Code, 27 Cumb. L. Rev. 1 (1997) (discussing the
regulatory nature of law, norms, market and code).
n298. Halloween I, supra note 35.
n299. FUD stands for "fear, uncertainty and doubt."
n300. See Halloween I, supra note 35.
n301. Halloween I provides an indication that Microsoft would attempt to
offer some of the "community"-type benefits of open source software, including
"putting out parts of the code base" or "creating community/noosphere," although
not fully embracing the open source concept. Halloween I, supra note 35.
Essentially, this would involve the creation of Microsoft's own, proprietary
"open source" methodology, thus taking a page from their technique of creating
Microsoft's own "standards" in place of true technology standards. Some indication
of this has come from statements by Microsoft that they may be considering
taking their code "open source," but then noting that they had a unique definition
of "open source." See Connie Guglielmo, Microsoft to Open Source? Not Likely
(last modified Apr. 9, 1999) <http://www.zdnet.com/zdnn/stories/news/0,4586,2239301,00.html>.
n302. See, e.g., Petreley, Take Nothing For Granted, supra note 296 (predicting
that, after the DOJ antitrust suit, Microsoft will force vendors to choose
between Linux and Microsoft NT just as they did for Navigator and Internet
Explorer). There is historical precedent for such activity. See United States
v. Microsoft Corp., Complaint, Civil Action No. 98-1232 (visited Feb. 26,
1999) <http://www.usdoj.gov/atr/cases/f1700/1763.htm> at PP 24, 97
(use of market power to control OEM alteration of desktop); id. at PP 75-92
(use of market power to control Internet content providers).
n303. Halloween II, supra note 296.
n304. For example, Sun filed a lawsuit against Microsoft for allegedly engaging
in this type of "decommoditizing protocols" with respect to Java. See Microsoft
Readies Java Appeal (last modified Dec. 17, 1998) <http://www.wired.com/news/news/politics/story/16895.html>;
Will Rodger, Sun, MS Play Java Blame Game (last modified Dec. 10, 1998) <http://www.zdnet.com/zdnn/stories/news/0,4586,2174437,00.html>;
Will Rodger, Java Emerges as Key Antitrust Issue (last modified Dec. 4, 1998)
<http://www.zdnet.com/zdnn/stories/news/0,4586,2172096,00.html>. It
has further been noted that in the Internet market of the future, there will
be a greater diversity of competitors, and the market may not readily facilitate
a single monopoly player. See Eric Nee, Microsoft Gets Ready To Play a New
Game, Fortune, Apr. 26, 1999 at 106.
Additionally, much of the software that provides the functionality of the
Internet is itself open source (for example, Sendmail, BIND and Apache),
and these projects would have incentives to resist changes to implement proprietary
"standards." Indeed, to the extent that the open source licenses under which
these programs are released restrict the licenses of software that it uses,
or with which it can be aggregated, use of these proprietary standards could
be impermissible.
n305. See Stephen Shankland, Linux Shipments up 212 percent (last modified
Dec. 16, 1998) <http://www.news.com/News/Item/0,4,30027,00.html> (citing
statistics from an International Data Corporation study indicating that market
share for Windows NT was about 36%, while Novell Netware, for example, had
about 24%, Linux had about 17%, and Unix accounted for roughly another 17%).
n306. See, e.g., id. (citing anti-Microsoft sentiment as part of the reason
for Linux's growth); Bob Sullivan, Linus Torvalds - Microsoft Killer? (last
modified Feb. 8, 1999) <http://www.msnbc.com/news/239469.asp> (characterizing
Linus Torvalds as the "patron saint of anti-Microsoft forces"); Halloween
I, supra note 35 (stating that the ability to capitalize on anti-Microsoft
sentiment is a strength of Mozilla).
n307. This perception would be reinforced by the fact that Microsoft thought
it was a serious enough threat to bother to attack it with anticompetitive
behavior.
n308. Cf. Behlendorf, supra note 44, at 160 (noting that there is pressure
to bridge gaps in open source software with more open source programs).
n309. See, e.g., Charles Babcock, Database Vendors, Netscape Support Linux
(last modified July 27, 1998) <http://www.zdnet.com/zdnn/stories/news/0,4586,339810,00.html>
(Informix, Oracle and Netscape make software on Linux); Ben Elgin, Corel
Chooses Linux OS for Its NC Prodcuts (last modified May 8, 1998) <http://www.zdnet.com/zdnn/content/smro/0508/314997.html>
(Corel to make network computer products available on Linux).
n310. This is the area of attack with the least certain outcome for the open
source community. For a discussion of the concerns associated with intellectual
property restrictions, see, supra Section V.A.4.
n311. This claim is raised, for example, in Halloween I, supra note 35.
n312. For example, on Slashdot <http://www.slashdot.org>, an open source
news service, Microsoft's statements that it had its own definition of the
term "open source" led to the posting of nearly 300 comments within about
one day. See Microsoft Redefines Open Source (visited Apr. 15, 1999) <http://slashdot.org/articles/99/04/09/1850204.shtml>.
n313. This is due to the fact that the term "Open Source" has been made a
certification mark. See supra note 97.
n314. See supra Section I.D., Section III.
n315. Eric S. Raymond recognized that the publicizing of the open source
movement in traditional media could lead to the appearance that he was violating
the norms of the open source culture. See Raymond, The Revenge of the Hackers,
supra note 264 at 214 ("I'd probably end up... despised as a sell-out or
glory-hog by a significant fraction of [the open source community].")
n316. One situation that may well be an example of this involves the dispute
between Eric S. Raymond and Bruce Perens regarding the consistency of Apple's
open source claims and the requirements of the open source definition, and
subsequent war of words. See Leander Kahney, Open-Source Gurus Trade Jabs
(last modified Apr. 10, 1999) <http://www.wired.com/news/news/technology/story/19049.html>.
While this heated dispute appears like real dissension among these individuals,
Chris DiBona, director of Linux Marketing at VA Research, noted that this
was "a flame war," that "was no more extreme than the kind of bluster that
comes from other public figures in the industry." Id.
n317. See, e.g., Brett Mendel, Will Commercialism Help Or Hurt Linux? (last
modified Apr. 8, 1999) <http://www.cnn.com/TECH/computing/9904/08/linuxsuits.idg>
(discussing the concern "that the cooperative community atmosphere for which
the Linux operating system has been famous is being tainted by commercial
interests."). Cf. Raymond, The Revenge of the Hackers, supra note 264, at
212-13. Raymond mistakenly characterizes the position of the Free Software
Foundation and others as a mere tool for attaining widespread use of free
software, rather than as a legitimate value choice. He argues that these
"freedom" arguments should be abandoned in favor of arguments more pleasing
to corporate ears. See id. However, causing individuals to abandon arguments
that may provide the ideological underpinnings of their involvement in the
community to achieve greater commercial appeal is precisely the type of tainting
by commercial norms that should be avoided.
n318. See, e.g., Kahney, supra note 316 (discussing the concern that the
vocal dispute between Eric S. Raymond and Bruce Perens could negatively impact
corporate America's view of open source software).
n319. An example of this may be seen in the fanaticism with which Richard
Stallman has begun to pursue the issue of the appropriate name of the program
commonly known as "Linux," to be "corrected" to "GNU/Linux." See Richard
Stallman, Richard Stallman - Re: 15 Years of Free Software (last modified
Mar. 25, 1999) <http://linuxtoday.com/stories/4377.html>; Charles Babcock,
Open Source, Closed Minds (last modified Mar. 25, 1999) <http://www.zdnet.com/zdnn/stories/comment/0,5859,2231706,00.html>.
This allows him, indirectly, to raise the importance of the "freedom" aspects
of free software. See Editorial: The "Linux" vs. "GNU/Linux" debate (last
modified Apr. 8, 1999) <http://www.kt.opensrc.org/kt19990408<uscore>13.html#editorial>.
n320. For example "ethical" hacking (or, as open source programmers would
say "cracking") seems to have gained some approval, see Jim Kerstetter, A
Reprieve for "Ethical Hacking' (last modified July 20, 1998) <http://www.zdnet.com/zdnn/stories/news/0,4586,337644,00.html>
(in legislation to update the copyright laws for the Internet cracking for
research purposes would be permitted). Thus, other types of behavior that
is generally condemned by society may come to be accepted in the online context,
based on the difference in online norms.
n321. This may depend upon how "success" is defined, however. If it is defined
as everyone, everywhere using and selling nothing but open source software,
this may be hindered by norms clashes. For example, the real world impression
of conflict in the open source community may limit its acceptance in this
community, at least in the short term, due to concerns about the ability
of the community to continue into the future to develop and support open
source software. However, even in this scenario the open source movement
would continue, if only on a smaller scale, and could be expected to continue
to produce high quality software. Its continued existence would allow for
future attempts to penetrate other markets.
n322. See Nicholas Petreley, Linux And The Monopoly Game (last visited Jan.
31 2000) <http://www.linuxworld.com/linuxworld/lw-1999-01/lw-01-penguin.html>.
n323. See Red Hat Linux 6.1: The Official Red Hat Linux Getting Started Guide
(last visited Feb. 6, 2000) <http://www.redhat.com/support/manuals/RHL-6.1-Manual/getting-started-guide/gpl.
html>.
n324. Other distributors include, in addition to Red Hat, Caldera <http://www.calderasystems.com>,
Debian <http://www.debian.org>, Mandrake <http://www.linux-mandrake.com>,
PowerPC Linux Project <http://www.linuxppc.org>, WorkGroup Solutions
<http://www.wgs.com>, Trans-Ameritech <http://www.trans-am.com>,
Apple Computer / The Open Group Research Group <http://www.mklinux.apple.com>,
Walnut Creek <http://www.cdrom.com>, Stampede <http://www.stampede.org>,
S.u.S.E. Linux <http://www.suse.com>, Pacific Hi-Tech <http://www.pht.com>,
Yggdrasil Computing, Inc. <Http://www.yggdrasil.com>.
n325. Petreley, supra note 322.
n326. In a recent poll by LinuxWorld, with a reader sample size of almost
900 indicated that people, 74% of those polled said Red Hat Linux is becoming
synonymous with Linux. See Petreley, supra note 322.
n327. See id.
n328. See discussion supra Section III.
n329. This is true because, unlike Microsoft, there are multiple reliable
sources for Linux. See supra note 325 and accompanying text.
n330. See, e.g., Young, Giving It Away, supra note 75, at 116-17.
n331. For example, by downloading versions of Linux from <ftp://sunsite.unc.edu/pub/Linux/>
(last visited Jan. 31, 2000)
n332. See Perens, supra note 101, at 181.
n333. See id.
n334. See U.C.C. 2-314 (1997). Where the seller is considered a merchant,
there is an implied warranty that, in relevant part, the goods must (1) "pass
without objection in the trade under the contract description," and (2) be
"fit for the ordinary purpose for which such goods are used." Id. The U.C.C.
defines a "merchant" as "a person who deals in goods of the kind or otherwise
by his occupation holds himself out as having knowledge or skill peculiar
to the practices or goods involved in the transaction or to whom such knowledge
or skill may be attributed by his employment of an agent or broker or other
intermediary who by his occupation holds himself out as having such knowledge
or skill." U.C.C. 2-104(1). The breach of implied warranty of merchantability
may apply to an original manufacturer, even if the buyer purchased the product
from an intervening party. See Pawelec v. Digitcom, Inc., 471 A.2d 60 (N.J.
Super App. Div. 1984); but see Professional Lens Plan, Inc. v. Polaris Leasing
Corp. 675 P.2d 887, 898-99 (Kan. Ct. App. 1984) aff'd, 710 P.2d 1297 (Kan.
1985) (privity of contract required).
n335. See U.C.C. 2-315 (1997). This warranty arises when, "at the time of
contracting [the seller] has reason to know any particular purpose for which
the goods are required and that the buyer is relying on the seller's skill
or judgment." Id. The warranty requires that the goods will be suitable for
this known purpose. See id.
n336. Whether software is a "good," and thus falls under the U.C.C. has been
itself a somewhat ambiguous question, although several courts have found
that it is. See, e.g., Communications Groups, Inc. v. Warner Communications,
Inc., 138 Misc.2d 80, 527 N.Y.S.2d 341 (N.Y. Civ. Ct. 1988) (software system
and equipment designed for a customer's specific needs is a good under the
U.C.C.); Analysts International Corp. v. Recycled Paper Products, Inc., 1
CCH Computer Cases P 45,050 (N.D. Ill. 1987) (an agreement to sell a custom-designed
software system was held to be a contract for a sale of goods); RRX Industries
v. Lab-Con, Inc., 772 F.2d 543 (9th Cir. 1985) (although training, repair
and upgrades were part of the contract for software, it was a contract for
a good). The UCITA would specifically incorporate implied warranties of merchantability
and fitness for software. See UCITA 403 (merchantability), 405 (fitness for
particular purpose). Since the UCITA has not yet been adopted by any states,
discussions here will focus primarily on the related provisions of existing
Article 2 when possible.
n337. See, e.g., Nielson Bus. Equip. Center, Inc. v. Montelone, 524 A.2d
1172, 1175 (Del. 1987) (defendant liable for failure to meet warranties of
fitness and merchantability under lease of computer hardware, software and
services).
n338. See Perens, supra note 101, at 181.
n339. Conspicuous means written so that "a reasonable person against whom
it is to operate ought to have notice of it," U.C.C. 1-201(10) (1999).
n340. See Michael D. Scott, Scott on Computer Law, Vol. 2 (2d ed. 1998 Supp.)
at 7-40.1 n. 162, 7-40.2 n. 168 and cases cited therein. For the relevant
provisions of the UCITA see UCITA 406. The requirements that would be imposed
on open source licenses under the UCITA could be milder than those under
the U.C.C. due to a more favorable definition of "conspicuous." While also
defined as written so that "a reasonable person against which it is to operate
ought to have noticed it," the intent of this phrase is more easily satisfied
under the UCITA. A term will satisfy this definition if it is:
(i) a heading in capitals in a size equal to or greater than, or in contrasting
type, font, or color to, the surrounding text;
(ii) language in the body of a record or display in larger or other contrasting
type, font, or color or set off from the surrounding text by symbols or other
marks that call attention to the language; and
(iii) a term prominently referenced in an electronic record or display which
is readily accessible and reviewable from the record or display...
UCITA 102(a)(15).
n341. See A&M Produce Co. v. FMC Corp., 186 Cal. Rptr. 114, 123-26 (Cal.
Ct. App. 1982) (listing situations where disclaimers are unconscionable).
n342. Like shrinkwrap contracts, open source contracts could be seen as adhesionary,
and thus not entitled to enforcement with regard to unconscionable terms.
Compare Harper Tax Services, Inc. v. Quick Tax Ltd, 686 F. Supp. 109 (D.
Md. 1988) (enforcing limitations in standard from contract for tax preparation
software despite finding that contract was adhesionary) with Vault Corp.
V. Quaid Software Ltd., 655 F. Supp. 750 (E.D. La. 1987) aff'd 847 F.2d 255
(5th Cir. 1988) (shrinkwrap from license not enforceable because it is a
contract of adhesion).
n343. For example, in Barazzotto v. Intelligent Systems, Inc., 1 Computer
Cas. (CCH) P 45,031 at 60,270-71 (Ohio App. 1987) the Ohio court of appeals
held that a shrink wrap license on the package of software disclaiming all
warranties alone did not protect resellers of that software.
n344. To recover for negligence, a plaintiff must show: (1) duty, (2) the
breach of that duty, (3) causation, and (4) damages. See Restatement (Third)
of Torts: Products Liability 1 (Draft 1997).
n345. To recover under strict (products) liability, a plaintiff must show:
(1) the product had a defect when sold or leased to the customer, (2) that
the plaintiff used the product in a normal, intended or reasonably foreseeable
way, and (3) that the defect was the proximate cause of the injury. See Restatement
(Second) of Torts 402A.
n346. This potential liability has become clearer in the context of potential
Y2K problems. See, e.g. David Bender & Adam Gahtan, Legal Aspects Of
The "Year 2000 Problem," 532 PLI/Pat 47 (1998).
n347. See, e.g., Scott, supra note 340, at 15-10 n.34 (listing cases in Maryland,
Florida, Colorado and California allowing purely economic losses, and cases
in Minnesota, Wisconsin, Illinois, Pennsylvania, Florida and California disallowing
economic losses).
n348. See Winter v. G.P. Putnam's Sons, 938 F.2d 1033, 1039 (9th Cir. 1991)
(plaintiffs picked mushrooms based on information in book published by defendants,
and got sick. Court held that the ideas and expressions contained within
a book are not a product within the scope of products liability). By analogy,
software, and particularly source code should not be a "product" for these
purposes either.
n349. For example, an organization could provide an umbrella under which
open source projects could occur, with only such money sought from software
as would be necessary to provide insurance in the case of lawsuits.
n350. This would likely be limited to corporate customers, who could have
substantial losses due to software problems.
n351. Insurance against loss may be, in many cases, preferable to utilizing
the courts once losses have occurred. This is arguably due to the administrative
costs associated with using the legal system. See, e.g., Stephen D. Sugarman,
Doing Away with Tort Law, 73 Cal. L. Rev. 558 (1985); Steven Shavell, Accidents,
Liability, and Insurance (1979).