The sharpest dividing line in licensing is that between proprietary-incompatible and proprietary-compatible licenses, that is, between the copyleft licenses and everything else.
The canonical example of a copyleft license is the GNU General Public License (along with its newer descendant, the Affero GNU General Public License or AGPL, introduced later in this chapter in the section called “The GNU Affero GPL: A Version of the GNU GPL for Server-Side Code”), and one of the most important considerations in choosing the GPL (or AGPL) is the extent to which it is compatible with other licenses. For brevity, I'll refer just to the GPL below, but most of this section applies to the AGPL as well.
Because the primary goal of the GPL's authors is the promotion of free software, they deliberately crafted the license to prevent proprietary programs from being distributed with GPLed code in them. Specifically, among the GPL's requirements (see https://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 exercise of the rights granted or affirmed under this License.")
Through these two conditions, the GPL makes freedom contagious. Once a program is copyrighted under the GPL, its terms of redistribution are reciprocal[137] — 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, by encouraging them to use the GPL.
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 the section called “Avoid Holy Wars”), and we won't investigate it here. What's important for our purposes is that GPL compatibility is something to consider when choosing a license. The GPL is a popular open source license, and some important open source packages are licensed under it. If you want your code to be able to be mixed freely with GPLed code, 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 https://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.
[137] Some people use the term viral to describe the GPL's contagiousness; they do not always mean this pejoratively, but I still prefer "reciprocal" because it's more descriptive and less connotative of disease.