When choosing a license to apply to your project, use an existing license instead of making up a new one. And don't just use any existing license — use one of the widely-used, well-recognized existing licenses.
Such licenses are familiar to many people already. If you use one of them, people won't feel they have to read the legalese in order to use your code, because they'll have already read that license a long time ago. Thus, you reduce or remove one possible barrier to entry for your project. These licenses are also of a high quality: they are the products of much thought and experience; indeed most of them are revisions of previous versions of themselves, and the modern versions represent a great deal of accumulated legal and technical wisdom. Unless your project has truly unusual needs, it is unlikely you could do better even with a team of lawyers at your disposal.
Below is a list of licenses that in my opinion meet these criteria; in parentheses is the standard formal abbreviation[138] for each license. If you have nothing else to guide you and you want a copyleft license, then choose either the GPL-3.0 or the AGPL-3.0 — the difference between them will be discussed below — and if you want a non-copyleft license, choose the MIT license. I've put those licenses in boldface to reflect this.
This list is not in order of preference, but rather in roughly descending order from strong copyleft at the top to completely non-copyleft at the bottom:
GPL-3.0)AGPL-3.0)MPL-2.0)LGPL-3.0)EPL-1.0)Apache-2.0)MIT)BSD-2-Clause)The exact provisions of each license differ in various interesting ways (except for MIT and BSD, which differ only in uninteresting ways and are basically interchangeable). There isn't space here to explore all the possible ramifications of each license for your project, but many good discussions of that sort are easily findable on the Internet; in particular the Wikipedia pages for these licenses tend to give good overviews.
Note that there are some arguments for choosing the Apache License 2.0 as a default non-copyleft license, and they are nearly as compelling as those for choosing MIT. In the end, I come down in favor of MIT because it is extremely short, and both widely used and widely recognized. While the Apache License 2.0 has the advantage of containing some explicit defenses against misuse of software patents, which might be important to your organization depending on the kind of project you're launching, the MIT license is fully compatible with all versions of the GNU General Public License, meaning that you can distributed, under any version of the GPL, mixed-provenance works that contain MIT-licensed code. The GPL-compatibility situation for the Apache License, on the other hand, is more complicated — by some interpretations, it is compatible with GPL version 3 only. Therefore, to avoid giving your downstream redistributors the headache of having to read sentences like the preceding ones, I recommend the MIT license as the default non-copyleft license for anyone who doesn't have a reason to choose otherwise.
The mechanics of applying a license to your project are discussed in the section called “How to Apply a License to Your Software”.
If you prefer that your project's code not be used in proprietary programs, or if you at least don't care whether or not it can be used in proprietary programs, the GNU General Public License, version 3, is a good choice.
When writing a code library that is meant mainly to be used as part of other programs, consider carefully whether the restrictions imposed by the GPL are in line with your project's goals. In some cases — for example, when you're trying to unseat a competing, proprietary library that offers the same functionality[139] — it may make more strategic sense to license your code in such a way that it can be mixed into proprietary programs, even though you would otherwise not wish this. The Free Software Foundation even fashioned an alternative to the GPL for such circumstances: the GNU Lesser GPL[140] The LGPL has weaker reciprocity requirements than the GPL, and can be mixed more easily with non-free code. The FSF's page about the LGPL, https://www.gnu.org/licenses/lgpl.html, has a good discussion of when to use it.
The GPL has a well-known optional recommendation that you release software under the current version of the GPL while giving downstream recipients the option to redistribute it under any later (i.e., future) version of the license. The way to offer this option is to put language like this in the license headers (see the section called “How to Apply a License to Your Software”) of the actual source files:
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
(Emphasis added.)
Whether you want to offer this option depends largely on how likely you think the Free Software Foundation is to make GPL revisions that you would approve of. I think the FSF has done a good job of that so far, and I generally do include that option when I use the GPL. That way I don't have to be responsible for updating my software's licenses forever — which is good, since I won't be around forever. Others can do it, either just to keep the software license up-to-date with legal developments, or to solve some future license compatibility problem that couldn't have been anticipated now (for example, see the compatibility discussion in the section called “The GNU Affero GPL: A Version of the GNU GPL for Server-Side Code” below).
Not everyone feels the same way, however; most notably, the Linux kernel is famously licensed under the GNU GPL version 2 without the "or any later version" clause, and influential kernel copyright holders, especially Linus Torvalds, have expressed clearly that they do not intend to move its license to version 3.0.
This book cannot answer the question of whether you should include the option or not. You now know that you have the choice and that different people come to different conclusions about it.
In 2007, the Free Software Foundation released a variant of the GPL called the GNU Affero GPL. Its purpose was to bring copyleft-style sharing provisions to the increasing amount of code being run as hosted services — that is, software that runs "in the cloud" on remote servers owned by someone other than the user. This is software that users interact with only over the network and that therefore is not directly distributed to its users as executable or source code in the normal course of usage. Many such services use GPLed software, often with extensive modifications, yet could avoid publishing their changes because they weren't actually distributing code.
The AGPL's solution to this was to take the GPL (version 3) and add a "Remote Network Interaction" clause, stating "...if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network ... an opportunity to receive the Corresponding Source of your version ... at no charge, through some standard or customary means of facilitating copying of software." This expanded the GPL's enforcement powers into the new world of remote application service providers. The Free Software Foundation recommends that the GNU AGPL 3.0 be used for any software that will commonly be run over a network.
Note that the AGPL-3.0 is not directly compatible with GPL-2.0, though it is compatible with GPL-3.0. Since most software licensed under GPL-2.0 includes the "or any later version" clause anyway, that software can just be shifted to GPL-3.0 if and when you need to mix it with AGPL-3.0 code. However, if you need to mix with programs licensed strictly under the GPL-2.0 (that is, programs licensed without the "or any later version" clause), the AGPL3.0 wouldn't be compatible with that.
Although the history of the AGPL-3.0 is a bit complicated, the license itself is simple: it's just the GPL-3.0 with one extra clause about network interaction. The Wikipedia article on the AGPL is excellent: https://en.wikipedia.org/wiki/Affero_General_Public_License
One common misunderstanding is that licensing your software under the GPL or AGPL requires you to provide source code to anyone who requests it under the terms of the license. But that's not quite how it works. If you are the sole copyright holder in a piece of software, then you are not bound by the copyright terms you chose, because (essentially) you can't be forced to sue yourself for copyright infringement. You can enforce the terms on others, but it's up to you to decide whether and when those terms apply to you. After all, because you had the software originally, you never "distributed" it to yourself and thus are not bound by the redistribution requirements of the license.
Of course, this only applies to situations where you own the whole copyright. If you include others' GPL- or AGPL-licensed code in your project and then distribute the result, you are no longer the sole copyright holder, and so you are as bound by the original terms as anyone else who uses and redistributes that code, either unmodified or as part of a derivative work.
One consequence of choosing the GPL (or AGPL) is the small possibility of finding yourself or your project embroiled in a dispute about whether or not the GPL is truly "free", given that it places some restrictions on how you redistribute the code — namely, the restriction that the code cannot be distributed under any other license. For some people, the existence of this restriction means the GPL is therefore "less free" than non-reciprocal licenses. Where this argument usually goes, of course, is that since "more free" must be better than "less free" (after all, who's not in favor of freedom?), it follows that those licenses are better than the GPL.
This debate is another popular holy war (see the section called “Avoid Holy Wars”). Avoid participating in it, at least in project forums. Don't attempt to prove that the GPL is less free, as free, or more free than other licenses. Instead, emphasize the specific reasons your project chose the GPL. If the recognizability of license was a reason, say that. If the enforcement of free licensing on derivative works was also a reason, say that too, but refuse to be drawn into discussion about whether this makes the code more or less "free". Freedom is a complex topic, and there is little point talking about it if terminology is going to be used as a stalking horse for substance.
Since this is a book and not a mailing list thread, however, I will admit that I've never understood the "GPL is not free" argument. The only restriction the GPL imposes is that it prevents people from imposing further restrictions. To say that this results in less freedom has always seemed perverse to me. If the retention of monopoly is somehow a freedom to be protected, then the word "freedom" is no longer meaningful.
[138] The Software Package Data Exchange (SPDX) project maintains a canonical list of licenses abbreviations, along with whether the given license is OSI-approved, FSF-approved, or both, at https://spdx.org/licenses/.
[139] Once again, the report Open Source Archetypes: A Framework For Purposeful Open Source (https://opentechstrategies.com/archetypes), mentioned in Chapter 1, Introduction, may be worth consulting if you want a strategic view of potential purposes for an open source project and how purpose affects structure.
[140] Originally named the GNU Library GPL, and later renamed by the FSF.