Chris DiBona, Sam Ockman and Mark Stone (eds), Open Sources: Voices
from the Open Source Revolution, Sebastopol (CA): O'Reilly and Associates,
Inc (1999).
The Open Source Definition
Bruce Perens
The typical computer user owns lots of software that
he bought years ago and no longer uses today. He may have upgraded his
computer or changed brands, and then the program wouldn't work any longer.
The software might have become obsolete. The program may simply not do
what he needs. He may have bought two or more computers, and doesn't want
to pay for a second copy of the software. Whatever the reason, the software
that he paid for years ago isn't up to the task today. Does that really
need to happen?
What if you had the right to get a free upgrade whenever
your software needed it? What if, when you switched from a Mac to a PC,
you could switch software versions for free? What if, when the software
doesn't work or isn't powerful enough, you can have it improved or even
fix it yourself? What if the software was still maintained even if the
company that produced it went out of business? What if you could use your
software on your office workstation, and your home desktop computer, and
your portable laptop, instead of just one computer? You'd probably still
be using the software you paid for years ago. These are some of the rights
that Open Source gives you.
The Open Source Definition is a bill of rights
for the computer user. It defines certain rights that a software license
must grant you to be certified as Open Source. Those who don't make
their programs Open Source are finding it difficult to compete with those
who do, as users gain a new appreciation of rights they always should have
had. Programs like the Linux operating system and Netscape's web
browser have become extremely popular, displacing other software that has
more restrictive licenses. Companies that use open-source software have
the advantage of its very rapid development, often by several collaborating
companies, and much of it contributed by individuals who simply need an
improvement to serve their own needs.
The volunteers who made products like Linux possible are
only there, and the companies are only able to cooperate, because of the
rights that come with Open Source. The average computer programmer would
feel stupid if he put lots of work into a program, only to have the owner
of the program sell his improvement without giving anything back. Those
same programmers feel comfortable contributing to Open Source because they
are assured of these rights:
-
The right to make copies of the program, and distribute those copies.
-
The right to have access to the software's source code, a necessary preliminary
before you can change it.
-
The right to make improvements to the program.
These rights are important to the software contributor
because they keep all contributors at the same level relative to each other.
Everyone who wants to is allowed to sell an Open Source program, so prices
will be low and development to reach new markets will be rapid. Anyone
who invests the time to build knowledge in an Open Source program can support
it, and this provides users with the option of providing their own support,
or the economy of a number of competing support providers. Any programmer
can tailor an Open Source program to specific markets in order to reach
new customers. People who do these things aren't compelled to pay royalties
or license fees.
The reason for the success of this somewhat communist-sounding
strategy, while the failure of communism itself is visible around the world,
is that the economics of information are fundamentally different from those
of other products. There is very little cost associated with copying a
piece of information like a computer program. The electricity involved
costs less than a penny, and the use of the equipment not much more. In
comparison, you can't copy a loaf of bread without a pound of flour.
Analysis of the Open Source Definition
In this section, I'll present the entire text of the
Open Source Definition, with commentary (in italic). You can find the canonical
version of the Open Source Definition at http://www.opensource.org/osd.html.
Pedants have pointed out minor ambiguities in the Open
Source Definition. I've held off revising it as it's little more than a
year old and I'd like people to consider it stable. The future will
bring slight language changes, but only the most minor of changes in the
intent
of the document.
The Open Source Definition (Version 1.0)
Open source doesn't just mean access to the source code.
The distribution terms of an open-source program must comply with the following
criteria:
Note that the Open Source Definition is not
itself a software license. It is a specification of what is permissible
in a software license for that software to be referred to as Open Source.
The Open Source Definition was not intended to be a legal document. The
inclusion of the Open Source Definition in software licenses, such as a
proposed license of the Linux Documentation Project, has tempted me to
write a more rigorous version that would be appropriate for that use.
To be Open Source, all of the terms below
must be applied together, and in all cases. For example, they must be applied
to derived versions of a program as well as the original program. It's
not sufficient to apply some and not others, and it's not sufficient for
the terms to only apply some of the time. After working through some particularly
naive interpretations of the Open Source Definition, I feel tempted to
add: this means you!
-
Free Redistribution
The license may not 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.
This means that you can make any number
of copies of the software, and sell or give them away, and you don't have
to pay anyone for that privilege.
The "aggregate software distribution
containing programs from several different sources" was intended to fit
a loophole in the Artistic License, a rather sloppy license in my opinion,
originally designed for Perl. Today, almost all programs that use the Artistic
License are also available under the GPL. That provision is thus no longer
necessary, and may be removed from a future version of the Open Source
Definition.
-
Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form. Where some form of a product is not
distributed with source code, there must be a well-publicized means of
downloading the source code, without charge, via the Internet. The source
code must be the preferred form in which a programmer would modify the
program. Deliberately obfuscated source code is not allowed. Intermediate
forms such as the output of a preprocessor or translator are not allowed.
Source code is a necessary preliminary
for the repair or modification of a program. The intent here is for source
code to be distributed with the initial work, and all derived works.
-
Derived Works
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.
Software has little use if you can't
maintain it ( fix bugs, port to new systems, make improvements), and modification
is necessary for maintenance. The intent here is for modification of any
sort to be allowed. It must be allowed for a modified work to be distributed
under the same license terms as the original work. However, it is not required
that any producer of a derived work must use the same license terms, only
that the option to do so be open to them. Various licenses speak differently
on this subject--the BSD license allows you to take modifications private,
while the GPL does not.
A concern among some software authors
is that this provision could allow unscrupulous people to modify their
software in ways that would embarrass the original author. They fear someone
deliberately making the software perform incorrectly in a way that would
make it look as if the author was a poor programmer. Others are concerned
that software could be modified for criminal use, by the addition of Trojan
horse functions or locally-banned technologies such as cryptography. All
of these actions, however, are covered by criminal law. A common misunderstanding
about software licenses is that they must specify everything, including
things like "don't use this software to commit a crime." However, no license
has any valid existence outside of the body of civil and criminal law.
Considering a license as something apart from the body of applicable law
is as silly as considering an English-language document as being apart
from the dictionary, in which case none of the words would have any defined
meaning.
-
Integrity of the Author's Source Code
The license may restrict source code from being distributed in modified
form only if the license allows the distribution of "patch files" with
the source code for the purpose of modifying the program at build time.
Some authors were afraid that others
would distribute source code with modifications that would be perceived
as the work of the original author, and would reflect poorly on that author.
This gives them a way to enforce a separation between modifications and
their own work without prohibiting modifications. Some consider it un-aesthetic
that modifications might have to be distributed in a separate "patch" file
from the source code, even though Linux distributions like Debian and Red
Hat use this procedure for all of the modifications they make to the programs
they distribute. There are programs that automatically merge patches into
the main source, and one can have these programs run automatically when
extracting a source package. Thus, this provision should cause little or
no hardship.
Note also that this provision says
that in the case of patch files, the modification takes place at build-time.
This loophole is employed in the Qt Public License to mandate a different,
though less restrictive, license for the patch files, in contradiction
of Section 3 of the Open Source Definition. There is a proposal to clean
up this loophole in the definition while keeping Qt within Open Source.
The license must explicitly permit distribution
of software built from modified source code. The license may require derived
works to carry a different name or version number from the original software.
This means that Netscape, for example,
can insist that only they can name a version of the program Netscape Navigator(tm)
while all free versions of the program must be called Mozilla or something
else.
-
No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
A license provided by the Regents of
the University of California, Berkeley, prohibited an electronic design
program from being used by the police of South Africa. While this was a
laudable sentiment in the time of apartheid, it makes little sense today.
Some people are still stuck with software that they acquired under that
license, and their derived versions must carry the same restriction. Open
Source licenses may not contain such provisions, no matter how laudable
their intent.
-
No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program
in a specific field of endeavor. For example, it may not restrict the program
from being used in a business, or from being used for genetic research.
Your software must be equally usable
in an abortion clinic, or by an anti-abortion organization. These political
arguments belong on the floor of Congress, not in software licenses. Some
people find this lack of discrimination extremely offensive!
-
Distribution of License
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.
The license must be automatic, no signature
required. Unfortunately, there has not been a good court test in the U.S.
of the power of a no-signature-required license when it is passed from
a second party to a third. However, this argument considers the license
in the body of contract law, while some argue that it should be considered
as copyright law, where there is more precedent for no-signature licenses.
A good court test will no doubt happen in the next few years, given the
popularity of this sort of license and the booming nature of Open Source.
-
License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's
being part of a particular software distribution. If the program is extracted
from that distribution and used or distributed within the terms of the
program's license, all parties to whom the program is redistributed should
have the same rights as those that are granted in conjunction with the
original software distribution.
This means you can't restrict a product
that is identified as Open Source to be free only if you use it with a
particular brand of Linux distribution, etc. It must remain free if you
separate it from the software distribution it came with.
-
License Must Not Contaminate Other Software
The license must not place restrictions on other software that is distributed
along with the licensed software. For example, the license must not insist
that all other programs distributed on the same medium must be open-source
software.
A version of GhostScript (a PostScript-rendering
program) requires that the media on which it is distributed contain only
free software programs. This isn't permissible for Open Source licenses.
Fortunately, the GhostScript author distributes another (somewhat older)
version of the program with a true Open Source license.
Note that there is a difference between
derivation and aggregation. Derivation is when a program actually
incorporates part of another program into itself. Aggregation is when you
include two programs on the same CD-ROM. This section of the Open Source
Definition is concerned with aggregation , not derivation. Section
4 is concerned with derivation.
-
Example Licenses
The GNU GPL, BSD, X Consortium, and Artistic licenses are examples
of licenses that we consider conformant to the Open Source Definition.
So is the MPL.
This would get us in trouble if any
of these licenses are ever changed to be non-Open-Source--we'd have to
issue
a revision of the Open Source Definition
immediately. It really belongs in explanatory text, not in the Open Source
Definition itself.
Analysis of Licenses and Their Open Source Compliance
To understand the Open Source Definition, we need to
look at some common licensing practices as they relate to Open Source.
Public Domain
A common misconception is that much free software is
public-domain.
This happens simply because the idea of free software or Open Source is
confusing to many people, and they mistakenly describe these programs as
public-domain because that's the closest concept that they understand.
The programs, however, are clearly copyrighted and covered by a license,
just a license that gives people more rights than they are used to.
A public-domain program is one upon which the author
has deliberately surrendered his copyright rights. It can't really be said
to come with a license; it's your personal property to use as you see fit.
Because you can treat it as your personal property, you can do what you
want with a public-domain program. You can even re-license a public-domain
program, removing that version from the public domain, or you can remove
the author's name and treat it as your own work.
If you are doing a lot of work on a public-domain program,
consider applying your own copyright to the program and re-licensing it.
For example, if you don't want a third party to make their own modifications
that they then keep private, apply the GPL or a similar license to your
version of the program. The version that you started with will still be
in the public domain, but your version will be under a license that others
must heed if they use it or derive from it.
You can easily take a public-domain program private, by
declaring a copyright and applying your own license to it or simply declaring
"All Rights Reserved."
Free Software Licenses in General
If you have a free software collection like a Linux
disk,
you may believe the programs on that disk are your property. That's not
entirely true. Copyrighted programs are the property of the copyright holder,
even when they have an Open Source license like the GPL. The program's
license grants you some rights, and you have other rights under the definition
of fair use in copyright law.
It's important to note that an author does not have to
issue a program with just one license. You can GPL a program, and also
sell a version of the same program with a commercial, non-Open-Source license.
This exact strategy is used by many people who want to make a program Open
Source and still make some money from it. Those who do not want an Open
Source license may pay for the privilege, providing a revenue stream for
the author.
All of the licenses we will examine have a common feature:
they each disclaim all warranties. The intent is to protect the software
owner from any liability connected with the program. Since the program
is often being given away at no cost, this is a reasonable requirement--the
author doesn't have a sufficient revenue stream from the program to fund
liability insurance and legal fees.
If free-software authors lose the right to disclaim all
warranties and find themselves getting sued over the performance of the
programs that they've written, they'll stop contributing free software
to the world. It's to our advantage as users to help the author protect
this right.
The Future
As this essay went to press, IBM joined the Open Source
world, and the venture capital community is discovering Open Source. Intel
and Netscape have invested in Red Hat, a Linux distributor. VA Research,
an integrator of Linux server and workstation hardware, has announced an
outside investor. Sendmail Inc., created to commercialize the ubiquitous
Sendmail e mail delivery program, has announced six million dollars in
funding. IBM's Postfix secure mailer has an Open Source license,
and another IBM product, the Jikes Java compiler, has a license
that, at this writing, tries but doesn't quite meet the intent of the Open
Source Definition. IBM appears to be willing to modify the Jikes license
to be fully Open Source, and is collecting comments from the community
as I write this.
Two internal Microsoft memos, referred to as the Halloween
Documents, were leaked to the online public. These memos clearly document
that Microsoft is threatened by Open Source and Linux, and that MS will
launch an offensive against them to protect its markets. Obviously, we
are in for some interesting times. I think we'll see Microsoft use two
main strategies: copyrighted interfaces and patents. Microsoft
will extend networking protocols, including Microsoft-specific features
in them that will not be made available to free software. They, and other
companies, will aggressively research new directions in computer science
and will patent whatever they can before we can first use those techniques
in free software, and then they'll lock us out with patent royalty fees.
I've written an essay for the webzine Linux World on how to fight
Open Source's enemies on the patent front.
The good news is that Microsoft is scared! In the secondHalloween
document,
a Microsoft staffer writes about the exhilarating feeling that he could
easily change part of the Linux system to do exactly what he wanted, and
that it was so much easier to do this on Linux than it was for a Microsoft
employee to change NT!
Efforts to hurt us from inside are the most dangerous.
I think we'll also see more attempts to dilute the definition of Open Source
to include partially-free products, as we saw with the Qt library
in KDE before Troll Tech saw the light and released an Open Source license.
Microsoft and others could hurt us by releasing a lot of software that's
just free enough to attract users without having the full freedoms of Open
Source. It's conceivable that they could kill off development of some categories
of Open Source software by releasing a "good enough," "almost-free-enough"
solution. However, the strong reaction against the KDE project before the
Qt
library went fully Open Source bodes poorly for similar efforts by MS and
its ilk.
We've escaped Trojan horses so far. Suppose that someone
who doesn't like us contributes software that contains Trojan horse, a
hidden way to defeat the security of a Linux system. Suppose, then, that
this person waits for the Trojan-horse software to be widely distributed,
and then publicizes its vulnerability to security exploits. The public
will then have seen that our Open Source system may leave us more vulnerable
to this sort of exploit than the closed system of Microsoft, and this may
reduce the public's trust in Open Source software. We can argue that Microsoft
has its share of security bugs even if they don't allow outsiders to insert
them, and that the disclosed source-code model of Open Source makes these
bugs easier to find. Any bug like this that comes up on Linux will be fixed
the day after it's announced, while a similar bug in Windows might go undetected
or unrepaired for years. But we still need to beef up our defense against
Trojan horses. Having good identification of the people who submit software
and modifications is our best defense, as it allows us to use criminal
law against the perpetrators of Trojan horses. While I was manager of the
Debian GNU/Linux distribution, we instituted a system for all of our software
maintainers to be reliably identified, and for them to participate in a
public-key cryptography network that would allow us to verify whom our
software came from. This sort of system has to be expanded to include all
Open Source developers.
We have tremendous improvements to make before Linux is
ready for the average person to use. The graphical user interface is an
obvious deficit, and the KDE and GNOME projects are addressing this. System
administration is the next frontier: while linuxconf partially addresses
this issue, if falls far short of being a comprehensive system-administration
tool for the naive user. If Caldera's COAS system is successful, it could
become the basis of a full solution to the system administration problem.
However, Caldera has had trouble keeping sufficient resources allocated
to COAS to finish its development, and other participants have dropped
off the bandwagon due to the lack of progress.
The plethora of Linux distributions appear to be going
through a shake-out, with Red Hat as the perceived winner and Caldera
coming in second. Red Hat has shown a solid commitment to the concept of
Open Source so far, but a new president and rumors of an Initial Public
Offering (IPO) could mean a weakening of this commitment, especially if
competitors like Caldera, who are not nearly as concerned about Open Source,
make inroads into Red Hat's markets. If the commitment of commercial Linux
distributions to Open Source became a problem, that would probably spawn
an effort to replace them with pure Open Source efforts similar to Debian
GNU/Linux, but ones more directed to the commercial market than Debian
has been.
Despite these challenges, I predict that Open Source will
win. Linux has become the testbed of computer science students, and they
will carry those systems with them into the workplace as they graduate.
Research laboratories have adopted the Open Source model because the sharing
of information is essential to the scientific method, and Open Source allows
software to be shared easily. Businesses are adopting the Open Source model
because it allows groups of companies to collaborate in solving a problem
without the threat of an anti-trust lawsuit, and because of the leverage
they gain when the computer-programming public contributes free improvements
to their software. Some large corporations have adopted Open Source as
a strategy to combat Microsoft and to assure that another Microsoft does
not come to dominate the computer industry. But the most reliable indication
of the future of Open Source is its past: in just a few years, we have
gone from nothing to a robust body of software that solves many different
problems and is reaching the million-user count. There's no reason for
us to slow down now.