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:

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!
  1. Free Redistribution
    2.  
    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.

     
  2. Source Code
    3.  
    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.
  3. Derived Works
    4.  
    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.

     
  4. Integrity of the Author's Source Code
    5.  
    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.
     

  5. No Discrimination Against Persons or Groups
    6.  
    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.
  6. No Discrimination Against Fields of Endeavor
    7.  
    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!
  7. Distribution of License
    8.  
    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.
  8. License Must Not Be Specific to a Product
    9.  
    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.
  9. License Must Not Contaminate Other Software
    10.  
    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.

     
  10. Example Licenses
    11.  
    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.