This section is intended to be a very quick, very rough guide to choosing a license. Read Chapter 9, Legal Matters: Licenses, Copyrights, Trademarks and Patents to understand the detailed legal implications of the different licenses, and how the license you choose can affect people's ability to mix your software with other software.
There are a great many free software licenses to choose from. Most of them we needn't consider here, as they were written to satisfy the particular legal needs of some corporation or person, and wouldn't be appropriate for your project. We will restrict ourselves to just the most commonly used licenses; in most cases, you will want to choose one of them.
If you're comfortable with your project's code potentially being used in proprietary programs, then use an MIT-style license. It is the simplest of several minimal licenses that do little more than assert nominal copyright (without actually restricting copying) and specify that the code comes with no warranty. See the section called “Choosing a License” for details.
If you don't want your code to be used in proprietary programs, use the GNU General Public License, version 3 (https://www.gnu.org/licenses/gpl.html). The GPL is probably the most widely recognized free software license in the world today. This is in itself a big advantage, since many potential users and contributors will already be familiar with it, and therefore won't have to spend extra time to read and understand your license. See the section called “The GNU General Public License” for details.
Once you've chosen a license, you'll need to apply it to the software.
The first thing to do is state the license clearly on the project's front page. You don't need to include the actual text of the license there; just give its name and make it link to the full license text on another page. That tells the public what license you intend the software to be released under — but it's not quite sufficient for legal purposes. The other step is that the software itself should include the license.
The standard way to do this is to put the full license text in a
file called LICENSE (or
COPYING) included with the source code, and then
at the top of each source file put a short notice in a comment, naming
the copyright date, holder, and license, and saying where to find the
full text of the license.
There are many variations on this pattern, so we'll look at just one example here. The GNU GPL says to put a notice like this at the top of each source file:
Copyright (C) <year> <name of author>
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.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>
It does not say specifically that the copy of the license you
received along with the program is in the file
COPYING or LICENSE, but
that's where it's usually put. (You could change the above notice to
state that directly, but there's no real need to.)
In general, the notice you put in each source file does not have to look exactly like the one above, as long as it starts with the same notice of copyright holder and date,[28] states the name of the license, and makes clear where to view the full license terms. It's always best to consult a lawyer, of course, if you can afford one.
[27] There actually are some minor differences between the sets of approved licenses, but they are not significant for our purposes — or indeed for most practical purposes. In some cases, one or the other organization has simply not gotten around to considering a given license, usually a license that is not widely-used anyway. There are also a few rarely-used licenses that have clauses that formally conflict with the letter, if not the spirit, of one or the other definition. For example, the OSD requires the license to allow redistribution under the exact same terms the software originally came with, instead of just under some set of OSD-compliant terms, whereas the FSD goes the other way on this question. These differences are exotic edge cases, however. For any license you are likely to be using, the terms "OSI-approved" and "FSF-approved" can be treated as implying each other.
[28] There is some leeway on exactly what the dates should indicate, and of course this book does not provide legal advice. The strictest legal interpretation I've heard is that the date should show the years in which the file was modified for copyright purposes. In other words, for a file modified in 2012, 2018, and 2021, you would write "2012, 2018, 2021" — not "2012-2021", because the file wasn't modified in most of the years in that range. Some projects just use a range anyway, with one end being the file's creation year and the other end being the year of most recent modification, as that's so much shorter and easier.