| Next: Choosing a License Up: The Open Source Definition Previous: Analysis of the Open |
To understand the Open Source Definition, we need to look at some common licensing practices as they relate to Open Source.
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.''
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.
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 Q t. 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 Q t. 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 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 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.
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!
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.