Best Practices of Software Licensing

I am nowhere near being an authority on software licensing. However, the recent release of GPLv3 with all the online discussions, all the attempts to exploit statements of the old version 2 of the license in order to achieve automatic license renewal for all the projects that were released under GPLv2 made me re-evaluate, not only the license itself, but also the methodology that should be used when licensing even a single line of code.

Here folows a list of what I believe are the best practices when licensing software:

Study the license’s legal code; not just read it, study it. It contains the terms under which your software will be released. Never let trends interfere with the selection of the license and, of course, make sure you do not choose a license just because you think you cannot find a more suitable one. Note that, when it comes to software licenses, the point of no return is the release of the software. If you change your mind about the license after a version of the software has been released, then it is impossible to invalidate previously released versions. Anyone, who has obtained a copy of the software with the old license, will be able to use it according to the terms of that license.
Include a copy of the license inside the distribution package of your software. Also, keep a local copy of the license on a web site that you fully control and link to it when necessary. If you have to link to the license’s original web page, make sure you use a URI that includes at least the name and version of the license, eg .../gpl-v2.html. Avoid linking to URLs that might be redirected to different documents over time. For example, a URI like .../gpl.html will probably be redirected to the latest version of the license whenever the latter is released, so it might bring confusion to the users of your software or to developers who wish to use the code. If the organization that issues the license has taken care, so that the license URI contains the license name, version and the general rights – like it happens with the Creative Commons version 3 licenses -, then I guess it is safe enough to use such URLs for linking.
Keep in mind that you, the developer of the software, are the one who will decide the terms under which the software will be released. If one of the existing licenses is satisfactory enough, then it is highly recommended that you use it. Otherwise, feel free to modify one of those licenses by adding or removing conditions in order to create a license that suits your software’s needs.
It is highly recommended that you remove any statements that expressly state or imply the automatic renewal of the license when a new version of it is released. Such statements can lead to serious trouble and confusion. Automatic license renewal is irrational when it comes to computer software. [Update: it is suggested to include a notice which indicates the removal of such statements inside the software’s distribution.]
Software that is released under the General Public License (GPL) is free open-source software. On the other hand, software does not have to be released under the GPL in order to be FS/OSS. If your software is meant to be FS/OSS, there are numerous licenses that can be used in order to give your users the necessary rights to use, copy, distribute, build on it etc. See the OSI approved licenses by category.

This list may not be complete, but it outlines some general rules that can be followed in order to avoid getting into trouble with your software’s license.

Related Articles