Developers often ask us which license we recommend for their projects. We have already published texts on this topic, but the information is scattered among essays, frequently asked questions and comments on licenses. This article collects all that information in a single text for the purpose of making it easier to consult.
These tips are for projects designed to carry out practical tasks, such as programs and documentation. Artistic works and works that express a subjective point of view constitute a separate issue; the GNU Project does not place any particular release conditions other than making their execution possible without the use of non-free software (in particular, without DRM). However, you may decide to follow these tips for artistic products that are accompanied by a program.
These tips apply to the case in which you have to choose a license for a project you created, both a modification to an existing project and an original project. They do not address the problem of combining existing and released material under different licenses. If you are looking for information to do so, please check out our frequently asked questions about LPG.
Once you have finished reading our recommendations, if you need further help you can write (in English if possible) to email@example.com. It may take weeks for the licensing team to respond; if you do not receive a reply within a month, always send a reminder to the same address.
Contribute to an existing project
When contributing to an existing project, it is recommended that you release your modified versions under the same license as the original project. It is good to cooperate with the project maintainers, and releasing changes under another license often makes cooperation very difficult. You should only do this in those special cases where it is highly justifiable.
One case where using a different license is justifiable is when substantial changes are made to a project released under a non-copyleft license. If the version you created is significantly more useful than the original, it is understandable to release it under a copyleft license, for the same reasons we recommend copyleft. If you find yourself in this situation, we recommend that you follow the recommendations below to apply a license to a new project.
If you choose to release your changes under a license other than the original, you must be sure that the original license allows the use of the material under the license of your choice. In the name of honesty, explicitly mark which parts of your project have been released under what license.
For most programs, we recommend using the latest version of the GNU General Public License (GPL) for your projects. It is a strong copyleft license that includes numerous safeguards for user freedoms, appropriate for all types of software. We recommend that you give permission to use future versions too, that is, in other words, to indicate that your program is covered by GPL version 3 or later.
Additional tips are available on how to release a GNU GPL licensed program.
Here are some exceptions, cases in which it is better to use other licenses instead of the GNU GPL.
Using copyleft for a small program isn’t always the best choice. We put 300 lines of code as a limit: when a program is shorter, the benefits offered by copyleft become too small to justify the inconvenience of making sure that the software is always distributed with a copy of the license.
For those programs, we recommend the Apache 2.0 License, a non-copyleft license that has the benefit of preventing contributors and distributors from filing complaints for infringing patents. This does not make software immune to patent threats (a license does not have this power), but prevents those who hold patents from creating “baits” which consist in releasing the software under free terms on condition of accepting non-free terms in the license of the patent.
Of the permissive licenses, Apache 2.0 is the best; if you have decided for any reason to use a permissive license, this is the one we recommend using.