Properly license your program for free software's sake

For years, the free software movement has been defending its done toward a more free and just society. The antagonists of this movement, on the other hand, would rather operate in a world in which free software does not exist, but they can't. They can't because, along with free programs and other free licenses, the GNU Project and the GNU General Public License (GPL) have earned us this victory for software freedom. What the antagonists of freedom can do, however, is keep software freedom under constant attack -- which, to their shame, they have chosen to do. We urge you to respond to their attacks by taking the time to properly apply a free license to a program, which is an important way to make software freedom stronger. Freedom itself is at stake.

Applying a GNU license like the GPL to your software is a piece of cake!

The good news is that properly licensing a program is simple -- so simple that I'm going to be able to provide a brief overview in this very short article. If you would like more details, you can visit our recommendations on "How to use GNU licenses for your own software." If you have any questions, you can send them to licensing@fsf.org. Licensing a program is not difficult, but because there is no "official" way to do it, we unfortunately don't see enough consistency across the tens of thousands of free programs available. We developed and maintain a set of GNU licenses that serve the purpose of protecting the freedoms, each with a specific scenario in mind. You can learn more about each of them at https://www.gnu.org/licenses/. When you choose a GPL for your work you are sending a message to the world that you want your program to be free -- and to stay free -- for all its future users. This is how the free software movement gains strength. To be sure, our guides and recommendations are not legal advice, and you should consult a lawyer if you want to make sure how to take advantage of copyright and licensing in your particular situation.

So, without further ado...

First and foremost, you must be certain that you are the copyright holder and that nobody can make a claim on your work. Both employers and universities may be in a position to make such claims based on an employment agreement or university policy. Like any legal document, it is wise to read those and, if you have doubts as to the status of your work, to consult legal counsel before signing. Optimally, you should ask your university or employer to sign a copyright disclaimer.

Per our recommendations, every source code file should contain the following in its header:

1. The name of the program and a short description of what it does.

2. The copyright notice with the year the file was created or modified and the name of the author, e.g. "Copyright 2023. Craig Topham."

3. The copying permission statement, which is a clear message that the software is freely available under the GPL, AGPL, or LGPL. This would include not only which version it is under, but whether it is only this specific version of the license or any later version the FSF might publish, e.g. "GPLv3 or later."

4. A disclaimer that there is no warranty or fitness for a particular purpose. (Alternatively, you may offer a warranty at your discretion. Doing so may be used as a strategic option for businesses who develop and sell free software.)

5. Finally, a note specifying that the recipient should have received a copy of the GPL so that they know their rights.

Including all five of these important pieces of information in your source file headers makes it clear that the program is free software. With every source code file, it helps for people to see the words "free software," so they understand those words have meaning and that those words matter. This is why we reject the term "open source." We want to talk about freedom, and if you do too, then we urge you to put that message first. The reason to provide the notice on every file is so that this vital message and the necessary licensing information is not lost, even when the file is separated from the rest of the source.

Optionally, if you really want to spread the message of freedom and the GPL, you can also include these notices to be visible when the program starts up. This would reach a larger audience of users who might not be looking at source code files.

With the file headers in place, we are almost done. The next important step is to place a copy of the GPL in the source code's main directory. Not only is it useful for recipients, it is a requirement of the GPL. Naming the file COPYING makes it clear to anyone that, if they plan to make copies of the program, they should read this file. If you are using the GNU LGPL, we recommend you name the file COPYING.LESSER.

Finally, besides having the file headers, it is helpful to recipients to offer a central location where the copyright and licensing information can be found. This is best done in a README or ABOUT file located in the source code's main directory.

In summary, if you care about software freedom, a properly applied GPL to a program furthers that cause. Anything less denies users the opportunity to learn more about free software.