Chapter 12. 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.
History
The concept of free software is an old one. When computers first reached universities, they were research tools. Software was freely passed around, and programmers were paid for the act of programming, not for the programs themselves. Only later on, when computers reached the business world, did programmers begin to support themselves by restricting the rights to their software and charging fees for each copy. Free Software as a political idea has been popularized by Richard Stallman since 1984, when he formed the Free Software Foundation and its GNU Project. Stallman’s premise is that people should have more freedom, and should appreciate their freedom. He designed a set of rights that he felt all users should have, and codified them in the GNU General Public License or GPL. Stallman punningly christened his license the copyleft because it leaves the right to copy in place. Stallman himself developed seminal works of free software such as the GNU C Compiler, and GNU Emacs, an editor so alluring to some that it is spoken of as it were a religion. His work inspired many others to contribute free software under the GPL. Although it is not promoted with the same libertarian fervor, the Open Source Definition includes many of Stallman’s ideas, and can be considered a derivative of his work.
The Open Source Definition started life as a policy document of the Debian GNU/Linux Distribution. Debian, an early Linux system and one still popular today, was built entirely of free software. However, since there were other licenses than the copyleft that purported to be free, Debian had some problem defining what was free, and they had never made their free software policy clear to the rest of the world. I was the leader of the Debian project, at that time, and I addressed these problems by proposing a Debian Social Contract and the Debian Free Software Guidelines in July 1997. Many Debian developers had criticisms and improvements that I incorporated into the documents. The Social Contract documented Debian’s intent to compose their system entirely of free software, and the Free Software Guidelines made it possible to classify software into free and non-free easily, by comparing the software license to the guidelines.
Debian’s guidelines were lauded in the free software community, especially among Linux developers, who were working their own free software revolution at the time in developing the first practical free operating system. When Netscape decided to make their web browser free software, they contacted Eric Raymond. Raymond is the Margaret Meade of free software: he has written several anthropological articles explaining the free software phenomenon and the culture that has grown around it, works that are the first of their kind and have shown a spotlight on this formerly little-known phenomenon. Netscape management was impressed with Raymond’s essay “The Cathedral and the Bazaar,” a chronicle of a successful free software development using unpaid volunteer contributors, and asked him to consult, under a non-disclosure agreement, while they developed a license for their free software. Raymond insisted that Netscape’s license comply with Debian’s guidelines for it to be taken seriously as free software.
Raymond and I had met occasionally at the Hacker’s Conference, an invitation-only gathering of creative and unconventional programmers. We had corresponded on various subjects via email. He contacted me in February of 1997 with the idea for Open Source. Raymond was concerned that conservative business people were put off by Stallman’s freedom pitch, which was, in contrast, very popular among the more liberal programmers. He felt this was stifling the development of Linux in the business world while it flourished in research. He met with business people in the fledgling Linux industry, and together they conceived of a program to market the free software concept to people who wore ties. Larry Augustin of VA Research and Sam Ockman (who later left VA to form Penguin Computing) were involved, as well as others who aren’t known to me.
Some months before Open Source, I had conceived of the idea of Open Hardware, a similar concept but for hardware devices and their interfaces rather than software programs. Open Hardware has not been as successful as Open Source to date, but it is still operating and you can find information on it at http://www.openhardware.org/.
Raymond felt that the Debian Free Software Guidelines were the right document to define Open Source, but that they needed a more general name and the removal of Debian-specific references. I edited the Guidelines to form the Open Source Definition. I had formed a corporation for Debian called Software in the Public Interest, and I offered to register a trademark for Open Source so that we could couple its use to the definition. Raymond agreed, and I registered a certification mark, a special form of trademark meant to be applied to other people’s products, on the term. About a month after I registered the mark, it became clear that Software in the Public Interest might not be the best home of the Open Source mark, and I transferred ownership of the mark to Raymond. Raymond and I have since formed the Open Source Initiative, an organization exclusively for managing the Open Source campaign and its certification mark. At this writing, the Open Source Initiative is governed by a six-person board chosen from well-known free software contributors, and seeks to expand its board to about ten people.
At the time of its conception there was much criticism for the Open Source campaign, even among the Linux contingent who had already bought-in to the free software concept. Many pointed to the existing use of the term “Open Source” in the political intelligence industry. Others felt the term “Open” was already overused. Many simply preferred the established name Free Software. I contended that the overuse of “Open” could never be as bad as the dual meaning of “Free” in the English language—either liberty or price, with price being the most oft-used meaning in the commercial world of computers and software. Richard Stallman later took exception to the campaign’s lack of an emphasis on freedom, and the fact that as Open Source became more popular, his role in the genesis of free software, and that of his Free Software Foundation, were being ignored—he complained of being “written out of history.” This situation was made worse by a tendency for people in the industry to compare Raymond and Stallman as if they were proponents of competing philosophies rather than people who were using different methods to market the same concept. I probably exacerbated the situation by pitting Stallman and Raymond against each other in debates at Linux Expo and Open Source Expo. It became so popular to type-cast the two as adversaries that an email debate, never intended for publication, appeared the online journal Salon. At that point, I asked Raymond to tone down a dialogue that it had never been his intent to enter.
When the Open Source Definition was written, there were already a large number of products that fit the definition. The problem was with programs that did not meet the definition, yet were seductive to users.
KDE, Qt, and Troll Tech
The case of KDE, Qt, and Troll Tech is relevant to this essay because the KDE group and Troll Tech tried to place a non-Open-Source product in the infrastructure of Linux, and met with unexpected resistance. Public outcry and the threat of a fully open-source replacement for their product eventually convinced Troll to switch to a fully Open Source license. It’s an interesting example of the community’s enthusiastic acceptance of the Open Source Definition that Troll Tech had to make its license comply, if their product was to succeed.
KDE was the first attempt at a free graphical desktop for Linux. The KDE applications were themselves under the GPL, but they depended on a proprietary graphical library called Qt, from Troll Tech. Qt’s license terms prohibited modification or use with any display software other than the senescent X Window System. Other use required a $1,500 developer’s license. Troll Tech provided versions of Qt for Microsoft Windows and the Macintosh, and this was its main revenue source. The pseudo-free license for X systems was meant to leverage the contributions of Linux developers into demos, examples, and accessories for their pricey Windows and Mac products.
Although the problems with the Qt license were clear, the prospect of a graphical desktop for Linux was so attractive that many users were willing to overlook its non-Open-Source nature. Open Source proponents found KDE objectionable because they perceived that the KDE developers were trying to blur the definition of what free software was to include partially-free items like Qt. The KDE developers contended that their programs were Open Source, even though there were no runnable versions of the programs that did not require a non-Open-Source library. I, and others, asserted that KDE applications were only Open Source fragments of non-Open-Source programs, and that an Open Source version of Qt would be necessary before KDE could be referred to as Open Source.
The KDE developers attempted to partially address the problem of Qt’s license by negotiating a KDE Free Qt Foundation agreement with Troll Tech, in which Troll and KDE would jointly control releases of the free version of Qt, and Troll Tech would release Qt under an Open-Source-complaint license if the company was ever purchased or went out of business.
Another group initiated the GNOME project, a fully Open Source competitor of KDE that aimed to provide more features and sophistication, and a separate group initiated a Harmony project to produce a fully Open Source clone of Qt that would support KDE. As GNOME was being demonstrated to accolades and Harmony was about to become useful, Troll Tech realized Qt would not be successful in the Linux market without a change in license. Troll Tech released a fully Open Source license for Qt, defusing the conflict and removing the motivation for the Harmony project. The GNOME project continues, and now aims to best KDE in terms of functionality and sophistication rather than in terms of its license.
Before they released their new Open Source license, Troll Tech provided me with a copy for auditing, with the request that it be kept confidential until they could announce it. In my enthusiasm to make peace with the KDE group and in an embarrassing feat of self-deception, I pre-announced their license eight hours early on a KDE mailing list. That email was almost immediately picked up by Slashdot and other online news magazines, to my chagrin.
Troll Tech’s new license is notable in that it takes advantage of a loophole in the Open Source Definition that allows patch files to be treated differently from other software. I would like to address this loophole in a future revision of the Open Source Definition, but the new text should not place Qt outside of Open Source.
At this writing, proponents of Open Source are increasing exponentially. The recent Open Source contributions of IBM and Ericsson have been in the headlines. Two Linux distributions, Yggdrasil and Debian, are distributing complete Linux system distributions, including many applications, that are entirely Open Source, and several others, including Red Hat, are very close. With the completion of the GNOME system, an Open Source GUI desktop OS capable of competing with Microsoft NT will have been realized.
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 GNU General Public License
Please see Appendix B for the full text of the GPL. The GPL is a political manifesto as well as a software license, and much of its text is concerned with explaining the rationale behind the license. This political dialogue has put some people off, and thus provided some of the reason that people have written other free software licenses. However, the GPL was assembled with the assistance of law professors, and is much better written than most of its ilk. I’d strongly urge that you use the GPL, or its library variant the LGPL, if you can. If you choose another license, or write your own, be sure about your reasons. People who write their own licenses should consider that this is not a step to be taken lightly. The unexpected complications of an ill-considered license can create a decades-long burden for software users.
The text of the GPL is not itself under the GPL. Its license is simple: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. An important point here is that the text of the licenses of Open Source software are generally not themselves Open Source. Obviously, a license would offer no protection if anyone could change it.
The provisions of the GPL satisfy the Open Source Definition. The GPL does not require any of the provisions permitted by paragraph 4 of the Open Source Definition, Integrity of the Author’s Source Code.
The GPL does not allow you to take modifications private. Your modifications must be distributed under the GPL. Thus, the author of a GPL-ed program is likely to receive improvements from others, including commercial companies who modify his software for their own purposes.
The GPL doesn’t allow the incorporation of a GPL-ed program into a proprietary program. The GPL’s definition of a proprietary program is any program with a license that doesn’t give you as many rights as the GPL.
There are a few loopholes in the GPL that allow it to be used in programs that are not entirely Open Source. Software libraries that are normally distributed with the compiler or operating system you are using may be linked with GPL-ed software; the result is a partially-free program. The copyright holder (generally the author of the program) is the person who places the GPL on the program and has the right to violate his own license. This was used by the KDE authors to distribute their programs with Qt before Troll Tech placed an Open Source license on Qt. However, this right does not extend to any third parties who redistribute the program—they must follow all of the terms of the license, even the ones that the copyright holder violates, and thus it’s problematical to redistribute a GPL-ed program containing Qt. The KDE developers appear to be addressing this problem by applying the LGPL, rather than the GPL, to their software.
The political rhetoric in the GPL puts some people off. Some of them have chosen a less appropriate license for their software simply because they eschew Richard Stallman’s ideas and don’t want to see them repeated in their own software packages.
The GNU Library General Public License
The LGPL is a derivative of the GPL that was designed for software libraries. Unlike the GPL, a LGPL-ed program can be incorporated into a proprietary program. The C-language library provided with Linux systems is an example of LGPL-ed software—it can be used to build proprietary programs, otherwise Linux would only be useful for free software authors.
An instance of an LGPL-ed program can be converted into a GPL-ed one at any time. Once that happens, you can’t convert that instance, or anything derived from it, back into an LGPL-ed program.
The rest of the provisions of the LGPL are similar to those in the GPL—in fact, it includes the GPL by reference.
The X, BSD, and Apache Licenses
The X license and its relatives the BSD and Apache licenses are very different from the GPL and LGPL. These licenses let you do nearly anything with the software licensed under them. This is because the software that the X and BSD licenses originally covered was funded by monetary grants of the U.S. Government. Since the U.S. citizens had already paid for the software with their taxes, they were granted permission to make use of that software as they pleased.
The most important permission, and one missing from the GPL, is that you can take X-licensed modifications private. In other words, you can get the source code for a X-licensed program, modify it, and then sell binary versions of the program without distributing the source code of your modifications, and without applying the X license to those modifications. This is still Open Source, however, as the Open Source Definition does not require that modifications always carry the original license.
Many other developers have adopted the X license and its variants, including the BSD (Berkeley System Distribution) and the Apache web server project. An annoying feature of the BSD license is a provision that requires you to mention (generally in a footnote) that the software was developed at the University of California any time you mention a feature of a BSD-licensed program in advertising. Keeping track of which software is BSD-licensed in something huge like a Linux distribution, and then remembering to mention the University whenever any of those programs are mentioned in advertising, is somewhat of a headache for business people. At this writing, the Debian GNU/Linux distribution contains over 2,500 software packages, and if even a fraction of them were BSD-licensed, advertising for a Linux system like Debian might contain many pages of footnotes! However, the X Consortium license does not have that advertising provision. If you are considering using a BSD-style license, use the X license instead.
The Artistic License
Although this license was originally developed for Perl, it’s since been used for other software. It is, in my opinion, a sloppily-worded license, in that it makes requirements and then gives you loopholes that make it easy to bypass the requirements. Perhaps that’s why almost all Artistic-license software is now dual-licensed, offering the choice of the Artistic License or the GPL.
Section 5 of the Artistic License prohibits sale of the software, yet allows an aggregate software distribution of more than one program to be sold. So, if you bundle an Artistic-licensed program with a five-line hello-world.c, you can sell the bundle. This feature of the Artistic License was the sole cause of the “aggregate” loophole in paragraph 1 of the Open Source Definition. As use of the Artistic License wanes, we are considering removing the loophole. That would make the Artistic a non-Open-Source license. This isn’t a step we would take lightly, and there will probably be more than a year of consideration and debate before it happens.
The Artistic License requires you to make modifications free, but then gives you a loophole (in Section 7) that allows you to take modifications private or even place parts of the Artistic-licensed program in the public domain!
The Netscape Public License and the Mozilla Public License
NPL was developed by Netscape when they made their product Netscape Navigator Open Source. Actually, the Open-Source version is called Mozilla; Netscape reserves the trademark Navigator for their own product. Eric Raymond and I acted as unpaid consultants during the development of this license. I tried, unsuccessfully, to persuade Netscape to use the GPL, and when they declined, I helped them compose a license that would comply with the Open Source Definition.
An important feature of the NPL is that it contains special privileges that apply to Netscape and nobody else. It gives Netscape the privilege of re-licensing modifications that you’ve made to their software. They can take those modifications private, improve them, and refuse to give you the result. This provision was necessary because when Netscape decided to go Open Source, it had contracts with other companies that committed it to provide Navigator to them under a non-Open-Source license.
Netscape created the MPL, or Mozilla Public License, to address this concern. The MPL is much like the NPL, but does not contain the clause that allows Netscape to re-license your modifications.
The NPL and MPL allow you to take modifications private.
Many companies have adopted a variation of the MPL for their own programs. This is unfortunate, because the NPL was designed for the specific business situation that Netscape was in at the time it was written, and is not necessarily appropriate for others to use. It should remain the license of Netscape and Mozilla, and others should use the GPL or the or X licenses.
Choosing a License
Do not write a new license if it is possible to use one of the ones listed here. The propagation of many different and incompatible licenses works to the detriment of Open Source software because fragments of one program cannot be used in another program with an incompatible license.
Steer clear of the Artistic License unless you are willing to study it carefully and edit out its loopholes. Then, make a few decisions:
Do you want people to be able to take modifications private or not? If you want to get the source code for modifications back from the people who make them, apply a license that mandates this. The GPL and LGPL would be good choices. If you don’t mind people taking modifications private, use the X or Apache license.
Do you want to allow someone to merge your program with their own proprietary software? If so, use the LGPL, which explicitly allows this without allowing people to make modifications to your own code private, or use the X or Apache licenses, which do allow modifications to be kept private.
Do you want some people to be able to buy commercial-licensed versions of your program that are not Open Source? If so, dual-license your software. I recommend the GPL as the Open Source license; you can find a commercial license appropriate for you to use in books like Copyright Your Software from Nolo Press.
Do you want everyone who uses your program to pay for the privilege? If so, perhaps Open Source isn’t for you. If you’re satisfied with having only some people pay you, you can work that and keep your program Open Source. Most of the Open Source authors consider their programs to be contributions to the public good, and don’t care if they are paid at all.
The table below gives a comparison of licensing practices:
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 second Halloween 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.
Get Open Sources now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
