Many small businesses, organizations, and independent developers create applications, software packages, websites, mobile applications and other products that require an open source license. Open Source Software (OSS) licensing allows organizations to open up their projects to the public for submissions, contributions, modifications, repair, or to build on top of the existing software code. Many organizations or developers do not have a positive understanding of the differences between the various OSS licenses and how to go about selecting one that fits closely with their software project, nor are they well-informed of how they want the project to be open for public involvement.
Mobile applications built by web development teams for platforms such as iOS and Android would also benefit from OSS collaboration, and equally require a licensing strategy. How does a development team go about selecting an OSS license for their projects?
This is not a discussion about the pros and cons of OSS development, but it is a guide for those who currently develop in the open community and for those who wish to learn more about the various licensing options that are available for OSS. You will also want to consult with a legal expert before adopting any software license for your projects.
Why a license?
You want to put your OSS project out there for everyone to collaborate, so why would you need a license to go along with the software? In laymen’s terms an OSS license allows the licensor/author (original owner) to grant the licensee (collaborators) the right to copy, modify, and possibly redistribute the source code or content of the software project. This also sets in place the original copyright of the work which typically means that the original author retains the ownership of the copyrights, and is allowing the licensee to simply use those rights as granted in the license as long as they maintain the conditions of the license. For more details on legal aspects of OSS licensees see the reference list at the end of this post.
Types of OSS
There are dozens of licenses out there to choose from, and for the most part, are divided among the three major classifications which are MIT License, Apache License, and GNU General Public License (GPL). While the Creative Commons Licenses can also be used for open software projects, they typically are relegated to design projects, and are not as open source as the others. These also include several layers that can be added on top of each other, but I will not review these in this piece. Each type of license has a specific purpose and use depending on your type of project and the software you intend on sharing for open development.
Probably the shortest and clearest type of license, the MIT License was originally developed by the Massachusetts Institute of Technology (MIT), and is a permissive free software license. This means that you allow anyone to do anything with your software code as long as they attribute the original work back to the original source, and you can not be held liable.
Usage - When using this type of license you must include a copy of it within the root of your source code or as a text file and include the current year and full name or names of the creators/authors.
Acceptance – Typically the MIT License is suitable for commercial use, modification, distribution, and sublicensing. However, it is forbidden for licensees to hold the licensor/author liable for any issues or outcomes. A sample MIT License is available from Choose a License, and is displayed in Figure B below.
If your organization is concerned about patents, then you might consider the Apache License, which also allows similar permissive agreements as the MIT License; however, you can also provide precise grants of patent rights from contributors and users of the software or code. A sample of the Apache License is available from Choose a License, and is displayed in Figure C below.
Usage – You must create a text file which is typically named “License” or “license.txt” for example, and it must be included in the root of the source code, and you must state any changes or version control as part of the code or documentation of the code. There is also a recommendation from the Apache Foundation that a boilerplate statement be placed within the header of each source file stating the nature of the Apache License.
Acceptance – Most use cases of the Apache License are suitable for commercial use, modification, distribution, sublicensing, and patent grants. And like the previous license, users are forbidden from holding anyone liable; however, in addition, users are prohibited from attaching a trademark for any use of the project or software code.
GNU General Public License (GPL)
There are two versions of the GPL license, V2 or V3, which take the licensing a step further and also require users /licensees/collaborators to disclose any changes they make if they redistribute the code in a source code or binary form. And the V3 license is further restricting in that it bans the use of the software in hardware that would forbid any software alterations. A screen capture of the GPL license that WordPress uses is displayed in Figure D below. Choose a License also has two sample GPL licenses for public use, V2 and V3.
Usage – As with the other license forms, at a minimum, a text file must be included within the root of the source code that contains the license document, and similar to the previous license, Free Software Foundation recommends a boilerplate notification placed at the top or header section of each file within the software.
Acceptance – These licenses are typically permitted for commercial use, modification, distribution, and patent grants. However, users /licensee/collaborators are not permitted to hold anyone liable, nor are they permitted to sublicense the work. Everyone is permitted to copy and distribute verbatim copies of the GPL license documents, but changing them is not allowed.
If you are not sure that any of these licenses fit your specific software project, you might consider checking out the list of featured and other licenses provided by Choose a License, which includes fourteen different licenses and each of their associated requirements, permitted uses, and forbidden uses. A screen capture of several of them is displayed in Figure E below.
References and for further reading about open source licenses check out the links below:
Ryan has performed in a broad range of technology support roles for electric-generation utilities, including nuclear power plants, and for the telecommunications industry. He has worked in web development for the restaurant industry and the Federal government.