After we made the decision to release the source code to NTXShape, there was one other important decision to be made: which license to use. There are a wide range of licenses in common use for open source development. At one end of the spectrum of licenses are the BSD and MIT licenses, which are very permissive and allow the recipient a great deal of flexibility in what they can do with the software, to the point where the software can distributed in proprietary commercial applications without providing source code. At the other end of the spectrum is the GNU General Public License, which places strong restrictions on what can be done with the software, but these restrictions are structured mainly to prevent you from placing stronger restrictions on what can be done with the software. In the open source community there is room for both of these extremes and many variations in between.
In some cases, after looking at all of the existing licenses, a company or person may feel that none of them precisely meet their interests, and might decide to create a new custom license and use that. We considered doing that. However, even in a custom license, there are trade-offs. The advantage of a custom license is that you get to help choose the trade-offs. The disadvantage is that you or your lawyer might get it wrong.
By using one of the standard, commonly-used licenses, you have the advantage that the license has already been scrutinized by many eyeballs, and any holes in the license may have already been spotted and discussed in publically archived forums. In addition, some of these licenses have been drafted and revised through a community review process, so the initial license may be more balanced to your needs and contain fewer bugs than a "custom" license that you might otherwise hire a lawyer to write.
Another distinct advantage of the commonly-used licenses is their value as a communication tool. The common licenses have worked their way into the jargon (or the lore) of the open source / hacker community. So, if your software is licensed under GPL, a hacker will at a glance have a very good idea of what he/she can and cannot do with it. If you're using a less common license or a custom license, they may need to read pages and pages of legalese, and (because hackers aren't lawyers) will still not have as good a picture of their rights as they would get from those three letters "GPL" (or another well-known license).
This communication advantage can be very important when marketing the project, i.e. when attempting to generate interest and enlist developers to participate in your project. Later on, I will come back to this notion and call it "project marketing".
So then we looked at the various open source licenses that have been certified by the Open Source Initiative, and of those, focused on the ones that are explicitly meant to be used for a variety of software, not just for some particular software application, and not just for the software of one corporation. For example, the Jabber public license is out because it's just for Jabber, and the IBM Public License is out because it's just for IBM.
The Q Public License is also out because, although it does comply with the Open Source Definition in a strict sense, it is so out of touch with hackers' expectations, and makes code-sharing so inconvenient that it tends to damage the credibility of projects that use it. Heck, it almost killed Qt itself within the open source community; and KDE (which is itself covered by GPL) was damaged heavily in the early days by mere association and linkage with a QPL-licensed library.
The licenses that we looked at included (from strongest to most permissive) GPL, Lesser GPL, Mozilla Public License, and the BSD and MIT Licenses. Of these the GPL had to be discarded because it would impose technical limitations on our software that outweighed the technical benefit of being able to link with other GPL software. Although we've used MIT-style licenses in other projects, the BSD and MIT licenses are just too permissive for this one. We want all enhancements to the NTXShape core to be published as open source; the BSD and MIT licenses do not require that.
So, for us, this leaves the Lesser GPL and the Mozilla Public License.
The Lesser GPL used to be called the Library GPL. For historical reasons this license still refers to the software application as "the Library" which can be confusing for licensees. Also, a licensee is allowed to convert the Lesser GPL to a full GPL, after which their enhancements could not be incorporated back into our version of the software. So, for us, LGPL is out.
The final license that we considered for the open source release of NTXShape was the Mozilla Public License (MPL) version 1.1. This license strikes a good balance between making the source code available for use in commercial situations, while at the same time requiring that modifications / enhancements be published under the same license (thereby enabling all good enhancements to find their way back to us). The Mozilla Public License was written and revised through a community review process, is widely used in projects outside of the Mozilla umbrella, and has value as a communication / project marketing tool when enlisting support for the project. This license is not a perfect fit for all software, but it is a very good fit for NTXShape.
The Mozilla Public License does have a mechanism for alternative licensing - that is, you can combine it with another license to offer the licensee a choice of terms. The Mozilla project itself has licensed much of their software under dual or even triple licenses with MPL, GPL, and Lesser GPL. Many other authors using Mozilla Public License also offer GPL as an option. Although we have no philosiphical objection to the GPL, NTXShape will not do this.
There are a wide variety of "Mozilla clone" licenses based on the Mozilla Public License with
varying degrees of changes. These include the Sun Public License, the Apple Public Source License,
the Interbase Public License, and others. Sometimes the only difference is the name (this change
allows a different company to control revisions to the license); other times (e.g. Apple) there
are some changes in the license terms. The only way to know what has changed is to read these
licenses carefully; therefore the "Mozilla clone" licenses do not have the same communicative
value as the "real" Mozilla Public License. Therefore I suggest you think twice before creating
your own "Mozilla clone" license. I would also recommend against using someone else's "Mozilla
clone" license - Mozilla and Netscape are invested in bazaar style development, and are sure
to be very careful about community reaction when publishing updates to the license, in order
to keep from alienating their developers. The other companies that publish clone licenses might
not be so responsible - Borland/Interbase has already burned many of their open source bridges.
(That said, I think Sun has been a good open source citizen up to now.)
There is one other license that we might have considered: the Common Public License, used for some projects on IBM's developerWorks site. It looks much like the IBM Public License, except that it is not "hard-coded" for IBM, and is is intended for general use. These licenses, both published by IBM, seem to strike a balance similar to that of the Mozilla Public License, but are easier for a human (as opposed to a lawyer) to read.
However, the Common Public License bears a version number of 0.5. It is not a widely used license, perhaps because its version number implies instability. As a result it is not as well known as the licenses mentioned above, and has not entered into the open source vernacular. So, although it looks promising, this license does not have the same communication / project marketing value as the better known, more widely used licenses.
IBM needs to release a 1.0 version of this license, and do a better job of marketing this license to developers, so that the license itself can help market IBM developerWorks' open source projects. Until they do those things, I doubt this license will get very much mindshare outside of IBM's developerWorks.