Table of Contents
I. Introduction
1
A. Open Source Software
2
1. Characteristics
of OSS
3
2. Examples of OSS-Linux
4
B. Computer Program
Copyright Protection
5
II. Proprietary Software
vs. OSS-Differences and Problems
6
A. The Purpose of Copyright
Law and Incentive for Developers 6
1. The Economic Implications
of Copyright Protection
6
2. Incentives for
OSS Developers
7
B. Length of Copyright Protection
8
C. OSS Copyright Infringement
9
1. OSS Model of Development
10
2. OSS Model of Monitoring
and Control
12
3. Copyright Infringement
Suit
12
D. OSS Licensing Problems
14
1. OSS Licensing
14
2. Problems of OSS Licenses
16
III. Solutions to the Problems
in OSS
17
A. Licensing Agreement Terms
18
1. Contract Warranty and
Enforceability
18
2. Resolution-Independent
Internet Entity
19
B. Legislative Regulation
19
IV. Conclusion-the Future
Development of OSS industry 21
With the development
of technology and the widespread use of the internet, open source software
(OSS) has brought a breakthrough revolution in software technology. The
open source movement, which comprises a community consisting primarily
of software developers and organizations interested in the software industry
revolution, poses a profound challenge to the way software is made, reproduced
and distributed. As a consequence, traditional copyright law gives inconsistent
or insufficient protection to open source software compared with that it
gives to proprietary software. How to interpret and update the 1976 Copyright
Act so that it can address and fit into the internet era and open source
movement is the focus of this article. This paper will 1) introduce OSS
and its representative example-Linux; 2) compare the characteristics of
OSS and proprietary software and explore the inconsistency of copyright
protection with respect to OSS; 3) analyze OSS licensing and operation
problems with respect to various kinds of licenses; 4) purpose solution
to OSS problems through contract, government or regulation, the internet
community and copyright law; and 5) predict the future of OSS development.
I. Introduction
A. Open Source Software
Open source software
(OSS), sometimes refers to as Free Software (FS). In summary,
OSS/FS programs are programs
whose licenses permit users the freedom to run the program for any purpose,
to study and modify the program, and to freely redistribute copies of the
original or modified program.1
1. Characteristics of OSS
"Open source" does not mean
merely access to the source code or free distribution. The distribution
terms of open-source software must comply with the following criteria:
1. The OSS license must
not restrict selling or spreading the software as a component of an aggregate
software distribution and must not require a royalty or other fee for such
sale.
2. The OSS program must
include the source code and allow distribution in source code as well as
compiled form. The source code must be the preferred form in which a programmer
would modify the program.
3. The OSS license must
allow modifications and derived works and allow developers to distribute
their programs under the same terms as the license of the original software.
4. The OSS license may restrict
the source code from being distributed in modified form only if the license
allows the distribution of patches with the source code for the purpose
of modifying the program at the beginning.
5. The license must not
discriminate against any specific person or group of persons and must not
restrict any specific reason or group of persons from making use of the
program in a specific field of endeavor.
6. 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.
7. The rights attached to
the program cannot depend on the program being a part of a particular software
distribution.
8. The license must not
place restrictions on other software that is distributed along with the
licensed software.
9. The OSS license must
be technology-neutral, and no provision of the license may be predicated
on any individual technology or style of interface.2
2. Examples of OSS-Linux
To understand the
difference between OSS and proprietary software, it is useful to consider
some prominent examples that have been developed through the open source
process. Some of the most important members of OSS are Apache, BIND,
Mozilla, Perl and Sendmail, but the one most familiar to us is the Linux
operation system. In recent years Microsoft Windows has been threatened
by the breakthrough development of Linux, for this reason a comparison
between Windows and Linux is helpful for us to recognize the glamour of
OSS.
Linux is a freely
distributable version of Unix, which is available for multiple platforms
such as x86, Motorola 68k and Digital Alpha. It is an implementation that
follows closely the POSIX specification that most commercial Unix versions
implement. Linux was created by and named after Linus Torvald in Finland
and announced its first version 0.02 in 1991.3 Thanks to the help of the
internet, many developers have devoted their time to debugging and updating
the Linux system (the latest Linux kernel archive is 2.5.65, which can
be freely downloaded at http://kernel.org). Because of its widespread use,
Linux can be asserted to be the open source project that has probably undergone
the greatest number of publicized tests, reviews and comparisons.4
B. Computer Program Copyright
Protection
The Copyright Act
of 1976 5 presents Congress' most recent major reform of the origin Copyright
Act "which [with some modifications] governs most works today."6 But the
term "computer program" was not included in the copyright law subject matter
until the 1980 amendment7. To fulfill the purpose of the copyright clause
in the U.S. Constitution, "(to) promote the progress of science and useful
arts, by securing for limited times to authors and inventors the exclusive
right to their respective writings and discoveries" (U.S. Const. art. I,
§8, cl. 8), the 1980 Amendment grants copyright protection to both
source codes and object codes of computer programs, as expressions of idea,
are granted copyright protection. There exists dispute on whether it would
be better to protect computer programs by patent instead of copyright law.
Although patent protection is available it is difficult to obtain because
most software is only a new expression of an existing process. Therefore,
the authors of computer programs turn to "original work" copyright protection
as a bottom line. Copyright includes the rights to reproduce the material
object, to make derivative works based on the work, to distribute the work
by selling, leasing and renting it, to make recordings and to perform or
display the underlying work (17 U.S.C. §§106, 1994 & Supp.
IV 1998).
When computer programs
were included in the definition of literary work and thus before a copyrightable
subject in the 1980, the Copyright Act came to be applied to software for
the purpose of restricting the public from accessing the programs. The
consequent effect is that the software developer can make an economic profit
by granting licenses or transferring ownership during the copyright protection
term. With the popularity of the internet, the open source software industry
has developed, and has come under the traditional copyright regulation
even though OSS was never contemplated by the drafters of the 1980 Amendment.
But a variety of open source communities, together with the unique characteristics
of OSS, have raised a lot of new requirements and problems inconsistent
with current copyright law such as the scope of restriction. A detailed
analysis of the difference between proprietary software and OSS can help
illustrate the problems and the possible solutions.
II. Proprietary Software
vs. OSS-Differences and Problems
Linux as an example
of open source software and its competitor Windows as an example of closely
source software-both operating systems are widely used throughout the world
but have been developed throughout completely different processes and have
been put into market with different strategies. For purposes of the article,
one of the greatest differences between them is that Linux users have been
granted a General Public License (GPL) while Microsoft is a strong advocate
of proprietary software. As a result, the developers and users of these
two kinds of software have totally divergent discretion on their copyright
enjoyment so the requirements on different level of copyright protection
are the consequence of the problems coming out from each circumstance.
A. The Purpose of Copyright
Law and Incentive for Developers
1. The Economic Implication
of Copyright Protection
The Framers of the Constitution,
specified two crucial requirements for copyright law. First, the law should
be structured to provide creators with economic rewards for their work,
rather than to provide them with congressional medals or public monuments.
Second, the law should be structured to improve society as a whole, rather
than to aid specific authors, inventors, and artists. The immediate effect
of copyright law is to secure a fair return for an author's creative labor.
But "the ultimate aim is, by this incentive, to stimulate artistic creativity
for the general public good".8
Applying the economic model
developed by Landes and Posner, the economic effect of copyright law on
innovation suggests that authors will continue to develop new works as
long as the expected profit exceeds the expected cost of creating the work.
The cost of creating a work, called the "cost of expression," rises proportionally
with the level of copyright protection because, as copyright protection
rises, authors are less free to borrow from and build on prior bodies of
work.9 Such a model can be applied to predict the author's incentive to
create when the underlying copyrighted work is proprietary software, but
it may seem inconsistent with the unique characteristics of OSS.
2. Incentives for OSS Developers
From an economic
standard, a huge divergence between proprietary software and OSS development
rests on the network economics and industrial standards. In the case of
proprietary software, the legal uncertainty of functional aspects of the
software and market risks will greatly deter its commercial competitors,
who are unlikely to make huge investments in developing and marketing competing
software instead of turning to probably more fruitful software.10 Market
and profit is the major orientation of the developers of proprietary software
and the derivative work copyright owners.
The OSS developers have
different incentives. First, OSS allows the users to have control over
the source code so that the users may change the software to fit their
own needs. This interaction between the program owners and users gives
the users to participate in the modification and improvement of OSS as
an appealing encouragement.
In addition to the altruistic
motive, the fact that every user can immediately enjoy his software update
and debugging patch file is the greatest incentive for users to participate
in the industry of OSS.11 Second, "one's work is one's statement"12 for
many OSS developers. They may merely pursue the enjoyment of programming
and self-esteem in the open source community. Knowing that their names
will appear on the list of developers of OSS, they strive for higher levels
of performance and distribution, which in turn improves the quality of
OSS.
Third, the OSS developers
may have an urge to compete with the existing proprietary software sellers.
By developing free software with less restriction, the OSS developers ultimately
force their counterpart sellers to lower their prices or give some market
profits to the users.
The competition between
Linux and Windows well illustrates the developing trend toward OSS. The
antitrust and anti-competitive problems caused by Microsoft current dominance
of the industry further reinforce the perception that OSS, particularly
Linux, is a legitimate alternative to Microsoft. In February 2003, Linux
vendor Red Hat Advanced Server platform became the first open source application
to receive a key U.S. government certification, the Defense Department's
Common Operating Environment (COE), clearing the way for its use in critical
government applications. This fact dispels yet another myth about the enterprise
readiness of open source software.13
Thus OSS can be seen
as inconsistent with the traditional economic mode for intellectual property
protection, and this regime of intellectual property has been outmoded
by digital technologies. Thus, interpreting intellectual property law narrow
to a balance economic incentive of the owner and the public interest would
harm the open source movement and frustrate the achievement of its goals.
B. Length of Copyright Protection
According to the economic
implications of copyright protection, copyright owners make a profit by
using the bundle of rights accompanying the ownership of the copyright,
mainly by granting licenses to reproduce, copy and making derivative work.
In order to ensure that the copyright owner gets a sufficient economic
reward before the copyrighted work enters the public domain, the Copyright
Act grants the copyright to the original author "for a term consisting
of the life of the author and seventy years after the author's death."
(17 U.S.C. §§302(a), 1994 & Supp. IV 1998) Generally, the
profitable and useful life of software is much shorter than the life of
other works. For example, Windows has undertaken six major iterations since
its release in 1985. That is to say, one version of Windows becomes obsolete
roughly every two years. At the same time, subsequent computer programs
always need to be built on existing works, so from the standpoint of encouraging
the development of the software industry, with regard to proprietary software,
shortening the copyright term would make sense.
OSS licensing appears special
in comparison with its counterpart. The basic implication of OSS licensing
is it "must allow modifications and derived works, and must allow them
to be distributed under the same terms as the license of the original software."14
As a consequence this licensing vest in the OSS user great discretion in
the release of newly added features and debugging patch files, and what
is left for the software kernel copyright owners is merely some nominal
rights. Except for some software companies such as Red Hat and Bluepoint,
which make money from selling the Linux advanced version and its peripheral
products, most of the OSS developers have almost no economic incentive
that is consistent with the purpose and length of the statutory copyright
period. Moreover, because each OSS, such as Linux, is subject to upgrading
and debugging in every user's hand, the useful life of OSS is longer than
that of proprietary software and even some other kinds of copyright subject
matter with less economic prospects for the author. In light of the statutory
purpose of encouraging the development of the software industry, if copyright
law is amended to shorten its protection term for computer programs, OSS
should be treated as an exception and given special consideration different
from that of proprietary software.
C. OSS Copyright Infringement
OSS and proprietary
software have different modes of development, which should influence the
methods of protecting their copyrights.
1. OSS Model of Development
The traditional
process of software development occurs under a centralized leadership with
a hierarchical model. Every project leader plays an important role in a
certain aspect of the software development and does a specific part of
the work. Subsequently the work of the project leaders will be centralized
by others and organized into a certain program. In the debugging process,
some project leaders have the task of handling the logistics of incoming
bug reports and bug fixing patch files from users, selecting among them
and implementing certain reports, then offering choices of solutions to
users. In the highly planned, hierarchical approach to development, finding
and fixing bugs is a long and arduous process, taking "months of scrutiny
by a dedicated few."15
The open source process
takes advantage of its users for program development. Generally, the users
not only offer feedback regarding flaws or shortcomings in the program,
but also are sources of solutions to these problems and potential programmers.
In the initial stage, OSS begins with the desire of a developer to meet
some currently unfulfilled or inadequately fulfilled need. The developer
then writes the program and puts into the internet to be peer-reviewed
by the open source community. Under this decentralized developing model,
users of OSS are encouraged to contribute not only their identifications
of bugs, but also their potential solutions. This model has some advantages.
First, bugs are easier to find and fix within a shorter release interval
than those proprietary software. Second, because the consensus of large
number of developers is more reliable than one or two people's opinion
and debuggers are not always required to conduct significant coordination
and communication, the communication and management costs of the centralized
model can be minimized in the context of OSS development. This cost minimization
also can be obtained in the hierarchical mode if the hierarchical is properly
structured to allow shorter release intervals, and to collect bug reports
frequently from the internet so that the bugs can be corrected in a minimum
time.16 Therefore it can be concluded that the key to ensure software development
is participation and distribution. OSS fits this requirement better than
its counterpart.
2. OSS Model of Monitoring
and Control
Another copyright
related matter is that the monitoring and control model of OSS also differs
from that of proprietary software. The power of government to regulate
and limit the rights to software depends partly on the ownership of the
software's code17 thus whether government can regulate code partly depends
upon who controls the code. When the subject is close code software, ownership
is held by an individual or for-profit organization, so government power
is assured. But OSS makes transparent any control that the code might carry.
As a result the code is outside of the control of any particular person
or companies. Therefore the government's power is limited in the case of
OSS.
The government's
monitoring and control power is of critical significance in the regulation
of the software industry. If software is built with a closed code, the
ability of a user to change its code is much more limited than when it
is open code. The harder it is for the users to change the code, the easier
for the government to set up some standard and regulate through that code.
So when an industry standard or government control is imposed on both open
source and closed source software, it is more likely that the regulation
will be followed by the latter. This gives developers an escape way when
they do not like the government monitoring and control standard: they can
easily avoid the regulation by choosing to use an open code on the software.18
3. Copyright Infringement
Suits
The lack of regulability
of OSS raises some other problems with its copyright protection. If a programmer
writes his own software based upon an existing copyrighted OSS, undoubtedly
this is a derivative work subject to the OSS distribution and reproduction
restrictions of the OSS license.
The first problem is, when
a programmer's distribution infringes an OSS copyright, who is eligible
to bring a suit. Under the 1976 Copyright Act, only the legal or beneficial
owner of an exclusive right under the copyright may sue for infringement.
The legal owner is the person who holds the copyright, and the beneficial
owners are those who have parted with legal title to the copyright in exchange
for percentage royalties based on sales or license fees.19 In an early
leading case Bertolino v. Italian Line20, the court held that in a suit
under the copyright laws, it is axiomatic that only the proprietor (legal
or beneficial owner) of the copyright has standing to sue for its infringement.
But one important feature of OSS licensing is that it must be distributed
solely under a non-exclusive license. This clause, for one hand, restricts
the factual number of possible plaintiffs who have standing to sue for
copyright infringement. In determining whether someone has standing, the
critical question is whether the plaintiff is really the owner of part
of the copyrightable work. On the other hand, relevant evidence of ownership
is hard to collect. Assuming that in a Linux internet community, every
member in it holds a non-exclusive license, the Linux kernel is a patchwork
of copyrights, a combined effort of multiple individuals21 so the ownership
is uncertain among the community. When one of them claims copyright ownership
of an improvement or patch file, the court has a potential problem of facing
multiple suits although the number of factual owners is far less than that
of the plaintiffs.
The second problem is a
procedural one. OSS development is largely related to the internet, which
has erased discrimination, restriction and certainty. Consequently apportioning
damages among those who allege OSS copyright infringement is difficult.
Under the government standard, it is easy to determine whether one's contribution
to proprietary software is sufficient to constitute a derivative work copyright
because the developers must comply with a series of requirements which
are set ahead of time. But for OSS, there is no effective control on the
copyrightability of every patch before its release, both ways that only
protecting the plaintiff disregard of the other contributors or alternatively
splitting damage evenly are unfair to each side. Moreover, when one alleges
copyright infringement for a certain patch of program, not every potential
programmer may have notice to participate in the suit due to the uncertainty
feature of the internet, undoubtedly the damages awarded are subject to
great decrease.
D. OSS Licensing Problems
Setting aside the
inherent inconsistency in the copyright protection of OSS, one unique aspect
of OSS is its non-conclusive licensing. Generally, when the owner of a
work "decides to transfer to one or more people the use and enjoyment of
part or all of his bundle of legal rights, yet wishes to retain ownership
of these rights", he uses a license. The license "defines the nature and
extent of [the granted] permission". Both the original owner and a licensee
may have the right to grant a license.22
1. OSS Licensing
Proprietary software
licensing usually imposes many much restrictions on the licensee. A typical
license requires the software to execute only format and limits the number
of installations allowed per copy of software. Moreover, developers or
developing organizations rarely make the source code available. If they
do release the source code for some limited purpose, an extra charge is
needed to maintain their market share and ensure maximum return.23 In contrast,
as mentioned above, OSS licensing gives more discretion to the users. OSS
licensing criteria prohibit the code from being used in proprietary or
commercial software; require the author of every version of OSS to be recognized
and kept the integrity of the list; and require the future improvements
or modifications to be distributed under the same terms of the OSS licensing,
and so forth.
Here are some examples
of some widely used types of OSS licensing existing on the internet, which
have different licensing terms and restrictions:
Type
Name
Terms
GPL
The GNU General Public License
Allows users to copy and
modify and distribute source code. Users must pass on, unimpaired, to other
users the licensing rights with all derivative versions of the code.
BSD
The Berkeley Software Distribution
License
Resembles GPL but does not
require that any modifications or enhancements of the original code be
contributed back to the open source community.
Aladdin
The Aladdin License
Resembles GPL but provides
additional restrictions.
MPL & NPL
The Mozilla Public License
and the Netscape Public License
A balance between BSD and
GPL. Developers should return their modifications to the open source community
but the owner retain specific rights that allow developers to continue
proprietary development of other packages and maintain existing contracts
with third parties.
SCSL
Sun's Community Source License
Sun requires and enforces
compatibility among released versions of the software, and allows proprietary
modifications and extensions to the software.
2. Problems of OSS Licenses
As shown in the chart
above, because of the diversity of internet development, there exist several
types of OSS licenses in the open source communities. "The propagation
of many different and incompatible licenses works to the detriment of OSS
because fragments of one program cannot be used in another program with
an incompatible license."24 This inconsistency of OSS licenses poses many
problems.
Technically, the incompatibility
may lead to a number of patches or packages for one OSS in order to make
it compatible with some other types of license, which is a potential economic
ineffective and time-consuming work. A further technical problem is the
OSS developers are more unlikely than those of proprietary software to
take advantage of the experience learned in the prior open source programs
because of the inconsistency among different license. Legally, the developers
of OSS could be deterred by potential copyright infringement suits. For
example, their retention of enhancement of OSS as derivative works may
be allowed by BSD, but such retention infringes the copyright of original
OSS developers under the terms of GPL. For this reason the uncertainty
of copyright infringement from the standpoint of derivative software owner
is a huge encumbrance of OSS communication in the internet. So a good OSS
license should ensure minimal conflict among the existing software licenses
and avoid the chaos in the OSS.
Setting aside the OSS licensing
inconsistency problem, one other problem exists in the terms of OSS license.
The license fundamentally plays the role of an agreement between the original
developers and users. Comparing the GPL terms of Linux with license terms
of Microsoft Windows, it can be found that the greatest difference between
them is the warranty clause. Linux GPL is "without warranty of any kind"
for any amount of time25; Microsoft warrants the software on condition
that the software will "perform substantially in accordance with the accompanying
written materials for a period of ninety days..."26. Microsoft allows use
of a product on only one computer at a time and disallows reverse engineering
and disassembly to remove any component part. So beyond the warranty clause,
there is no warranty. The main reason that OSS vendors tend not to provide
warranties for their products is that no single person or group as a member
in the internet open source community can be responsible for the defects
in OSS. This is also due to the lack of control as discussed above. Such
difference in the licensing terms has both positive and negative aspects:
for one hand, OSS users have to burden the risk of potential bugs and security
problems that always happen in software development. On the other hand,
OSS users at least have the privilege of modifying the source code when
certain bug arising from their usage of software.
In summary, the problems
existing in the copyright protection of OSS are multifaceted, but the focus
is the inconsistency between traditional copyright law protection and the
unique requirement of OSS in the internet era.
III. Solutions to the Problems
in OSS
Related to the above
analysis, there are several alternative ways to resolve the copyright protection
problems existing in the OSS industry. Generally, some important ones are
agreement, government control, the internet open source community standard
and copyright regulation.
A. Licensing Agreement Terms
1. Contract Warranty and
Enforceability
Mutual agreement
between the OSS original developers and users is the most direct way to
resolve the warranty problem inherent in OSS development. This can be seen
as the result of free negotiation and better off between these two parties
in the software market. More and more internet and OSS users are used to
the fact that there is no warranty and no single person can be responsible
for OSS and even proprietary software license sometimes bears no warranty
in the terms. And open source development is more interactive and transparent
between the developers and users than the case of proprietary software.
Although users have no warranty, they are compensated by more security
and frequent updated patch files.
In addition, the
OSS licensing provisions lead a license enforceability problem. Even though
the OSS license is binding between the parties, it still is not as enforceable
as that of proprietary software. The Copyright Act grants derivative work
authors copyright not extended to preexisting works, and relevant use beyond
this scope constitutes copyright misuse. But OSS license, such as GPL for
Linux, requires that OSS provision extend to independent work that does
not totally come from the open source code, the result is that the independent
work should be licensed back to the licensor. This provision makes the
derivative software authors easy to conduct copyright misuse and infringe
the copyright of the licensor. But because such provision is inconsistent
with the requirements in Copyright Act, the licensor should recognize the
potential danger that his license clause is lack of copyright enforceability
and he has to face the risk that the relevant provisions in the OSS license
may be unenforceable.
Even though assuming
all the clauses in OSS license are enforceable, such license still cannot
fully prevent certain modifications from being taken as private. Many types
of OSS licenses such as GPL and BSD permit modifications provided certain
conditions are met. But the premise is the derivative codes and the original
codes are distributed under notice of the same license. If the code is
modified under a different license, "then the right to create modifications
is lost or never arose due to the failure of the condition. In other words,
for any work you distribute, the right to modify is only valid if you distribute
the work under the GPL."27 So no matter the license of the original OSS
code is enforceable or not, the coexistence of a variety of licenses makes
licensor burdens the risk of insufficient copyright protection all along.
2. Resolution-Independent
Internet Entity
Beyond the contractual relationship
between developers and users, market provides almost no further solution
to the guaranty of OSS quality in contractual concerns. There are some
alternative ways to resolve this problem related to market. The most persuasive
one is forming a separate, non-profit entity in Cyberspace to verify application
compatibility. One role of the entity is offering independent verification,
and also can test new OSS products on criteria based on compatibility with
other products, platforms or devices. Another role of the entity is operating
on the user end as more of a report and information collecting center of
the bugs related to software compatibility and enforceability standard.
In order to ensure the impartial standard and independence of the entity,
internet provides a best anonymous space in the current world.
B. Legislative Regulation
Imposing governmental
authority on regulating OSS internet community and copyright licensing
is another possible way. With legal regulation, the whole OSS development
may goes more orderly with more certainty. Compared with the law for financing
and contract of sale of goods, which is compiled in Uniform Commercial
Code, the various licenses concerning the right transfer of OSS are far
less settled while it is hard to put OSS license into any existing legal
doctrine. For example, if we apply fair use doctrine to OSS, a lot of problems
may arise from the application. Fair use is a very vague doctrine which
authorizes certain socially beneficial uses of copyrighted material that
would otherwise constitute an infringement. Whether a certain conduct is
fair use should be determined case by case upon some criteria.28 When a
infringer wants to apply fair use doctrine to his modification or reproduction
of the original open code to assert his conduct is protected by the copyright
law, as analyzed above, the problem of inconsistency between OSS license
provision and copyright law becomes a tough issue to resolve.
The most straightforward
way to change the situation is that, government can consider setting up
a set of direct regulation concerning distribution, monitoring and norms
of OSS. The feasibility can be inferred from the difference between proprietary
software and OSS such as Windows and Linux in some way. It should be very
difficult for law to regulate the former because even government basically
has no chance to access the source code of Windows and trace every distribution
and modification during the life of OSS and such a regulation may be unnecessary
for close and commercial software. But on the other hand, government or
organization can always freely access Linux in the internet and recognize
exactly how OSS is modified every time so that the necessary evidence is
sufficient for legislators to set up certain norms particularly in regulating
one kind of OSS such as Linux.
Another theory supporting
the feasibility of such regulation is public choice theory, which holds
that broad, diffuse groups, like OSS developers and internet open source
communities are less likely to be effective in achieving a certain goal
than a centralized interest group, like proprietary software developers.29
Based upon the existing huge user and developer basis of OSS development,
if OSS are directed and protected by legal certainty, the future improvement
will be more efficient and cost saving. One other important benefit of
legislation is its enforceability, so the unenforceability problem inherent
in OSS licensing is more likely to be resolved by this way.
IV. Conclusion-the Future
Development of OSS
Cyberspace provides
OSS the widest improvement possibilities, the largest developer and user
basis and the fastest updating speed. The features of OSS determine that
OSS has much more advantages and developing space than proprietary software.
The trend that OSS might
step into and occupy more market of proprietary software can be seen from
some important recent events. One of them is that from the year 2002, Microsoft
has opened its Windows source code to systems integrators in a move to
appease both large customers and a federal judge. This is a move that analysts
say is more symbolic than material. Microsoft allows customers and partners
to view the source code without changing it or sharing the code with others.
The goal of Windows is to provide them with more in-depth knowledge of
Windows and to let users troubleshoot problems more quickly.30 Another
impressive event is Microsoft is predicted to add its proprietary software
into Linux environment by the year 2004. Facing the threat that by 2007,
45 percent of new servers will use Linux instead of Windows-based applications,
Microsoft would change its pricing structure to become more competitive
with Linux, including repricing Windows or separating the operating system
into a "kernel" with "add-on" components.31
If some more appropriate
vehicles of protection such as copyright provision and internet independent
entity standard can be applied on OSS, it will become a better encouragement
of OSS development through the internet open source communities. Consequently,
the competition between OSS and proprietary software will ultimately benefit
the public software users and improve the software industry.
ENDNOTES
1 See http://www.dwheeler.com/oss_fs_refs.html
2 See http://www.opensource.org/docs/definition_plain.html
3 See http://www.linuxfocus.org/English/November1997/article1.html
4 Marcus Maher, Open Source
Software: the Success of an Alternative Intellectual Property Incentive
Paradigm, 10 Fordham Intell. Prop. Media & Ent. L.J. 619, 623 (2000).
5 17 U.S.C. §§101-1332,
1994 & Supp. IV 1998.
6 Robert P. Mergeset AL.,
Intellectual Property in the New Technological Age, 323 (1997).
7 See Pub. L. No. 96-517
§10(a), 94 Stat. 3028 (1980) (amending §101 of the Copyright
Act).
8 A. Michael Warnecke, The
Art of Applying the Fair Use Doctrine: the Post-Modern Art Challenge the
Copyright Law, 13 Rev. Litig. 685, 695-696 (1994).
9 On the application of
economic analysis by legal scholars to specific copyright law doctrines,
see William M. Landes & Richard A. Posner, An Economic Analysis of
Copyright Law, 18 J. Legal Stud. 325 (1989).
10 See Stephen M. McJohn,
The Paradoxes of Free Software, 9 Geo. Mason L. Rev. 25, 36 (2000).
11 See Marcus Maher, supra
note 4, at 633-634.
12 Eric S. Raymond, Homesteading
the Noosphere: The Value of Humility,
http: tuxedo.org/esr/writings/homesteading/homesteading-11.html
13 See Red Hat Gets Thumbs-Up
from U.S. Government, http://www.newsfactor.com/perl/story/20742.html
14 See Bruce Perens, supra
note 4.
15 Eric S. Raymond, The
Cathedral and the Bazaar: The Importance of Having Users, http://www.tuxedo.org/esr/writings/cathedral-bazaar-3.htm.
16 See Eric, supra note
15, and see Eric S. Raymond, The Cathedral and the Bazaar: Release Early,
Release Often, http://www.tuxedo.org/esr/writings/cathedral-bazaar-4.htm.
17 See Jerome H. Saltzer
et al., End-to-End Arguments in Systems Design, in Integrated Broadband
Networks, 30 (Amit Bhargava ed., 1991).
18 See Lawrence Lessig,
The Limits in Open Code: Regulatory Standards and the Future of the Net,
14, Berkeley Tech. L.J. 759, 765-766(1999)
19 See 17 U.S.C §501,
201 (1994).
20 Bertolino v. Italian
Line, 414 F. Supp. 279, 284 (S.D.N.Y.1976)
21 Shawn W. Potter, Open
up to Open Source, 6 Rich. J.L. & Tech. 24, 68 (2000).
22 Natasha T. Horne, Open
Source Software Licensing: Using Copyright Law to Encourage Free Use, 17
Ga. St. U. L. Rev. 863, 871 (2001)
23 See Richard P. Gabriel
& William N. Joy, Sun Community Source License Principles, http://www.sun.com/981208/scsl/principles.html.
24 See Bruce Perens, The
Open Source Definition, in Open Sources: Voices from the Open Source Revolution,
185 (Chris Dibona et al. eds., 1999).
25 See GNU General Public
License, http://www.opensource.org/licenses/gpl-license.html.
26 See Microsoft Corporation,
Microsoft End User License Agreement (EULA): Windows 98-Online, http://www.linuxmall.com/misc/refund/eula/online032698.html.
27 Christian H. Nadan, Open
Source Licensing: Virus or Virtue? 10 Tex. Intell. Prop. L.J. 349, 370
(2002)
28 See 17 U.S.C.§107
(1994).
29 For a detailed analysis,
see Stephen, supra note 10, at 64-66. And see Lawrence Lessig, Open Code
and Open Society: Values of Internet Governance, 74 Chi.-Kent L. Rev. 1405,
(1999)
30 See Tiffany Kary, Microsoft
extends shared-code effort , http://news.com.com/2100-1001-841933.html.
31 See Lisa Gill, Research
Firm: Microsoft Will Use Linux by 2004, http://www.newsfactor.com/perl/story/20210.html.