By far the sharpest dividing line in licensing is that between proprietary-incompatible and proprietary-compatible licenses, that is, between the GNU General Public License and everything else. Because the primary goal of the GPL's authors is the promotion of free software, they deliberately crafted the license to make it impossible to mix GPLed code into proprietary programs. Specifically, among the GPL's requirements (see http://www.fsf.org/licensing/licenses/gpl.html for its full text) are these two:
Any derivative work—that is, any work containing a nontrivial amount of GPLed code—must itself be distributed under the GPL.
No additional restrictions may be placed on the redistribution of either the original work or a derivative work. (The exact language is: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.")
With these conditions, the GPL succeeds in making freedom contagious. Once a program is copyrighted under the GPL, its terms of redistribution are viral—they are passed on to anything else the code gets incorporated into, making it effectively impossible to use GPLed code in closed-source programs. However, these same clauses also make the GPL incompatible with certain other free licenses. The usual way this happens is that the other license imposes a requirement—for example, a credit clause requiring the original authors to be mentioned in some way—that is incompatible with the GPL's "You may not impose any further restrictions..." language. From the point of view of the Free Software Foundation, these second-order consequences are desirable, or at least not regrettable. The GPL not only keeps your software free, but effectively makes your software an agent in pushing other software to enforce freedom as well.
The question of whether or not this is a good way to promote free software is one of the most persistent holy wars on the Internet (see “Avoid Holy Wars” in Capítulo 6, Communications), and we won't investigate it here. What's important for our purposes is that GPL compatibility is an important issue when choosing a license. The GPL is by far the most popular open source license; at http://freshmeat.net/stats/#license, it is at 68%, and the next highest license is at 6%. If you want your code to be able to be mixed freely with GPLed code—and there's a lot of GPLed code out there—then you should pick a GPL-compatible license. Most of the GPL-compatible open source licenses are also proprietary-compatible: that is, code under such a license can be used in a GPLed program, and it can be used in a proprietary program. Of course, the results of these mixings would not be compatible with each other, since one would be under the GPL and the other would be under a closed-source license. But that concern applies only to the derivative works, not to the code you distribute in the first place.
Fortunately, the Free Software Foundation maintains a list showing which licenses are compatible with the GPL and which are not, at http://www.gnu.org/licenses/license-list.html. All of the licenses discussed in this chapter are present on that list, on one side or the other.