There are many licenses with slight variations, which might be overwhelming sometimes. Personally, I have been always confused about them. However, since I am a software developer, it is clear to me that comprehending licenses is a crucial thing to become a sufficient programmer. In this work, I would like to review the main licenses, highlight the differences, cases where to apply them, and how to properly place them in a project.
A software license tells others what they can and can’t do with a programmer’s source code.
No one is under obligation to choose a license. However, without a license, the default copyright laws apply, meaning that the creator retains all rights to the programmer’s source code and no one may reproduce, distribute, or create derivative works from the creator’s work. Well, if you distributed an open-source, at least legally they cannot reproduce
For starters, there are five main software license categories or types used to cover different kinds of software and various business arrangements. The five categories are Public Domain License, Permissive, The Bridge (LGPL/Eclipse), CopyLeft, Proprietary.
Public Domain License. The most flexible license of all of them. Anyone can modify and use the software without restrictions.
Permissive. Permissive licenses are similar to public domain licenses but are marginally more restrictive as they may contain some stipulations regarding intellectual property protections. Users don’t have to republish any changes they make and typically only have to give attribution to the original authors in the form of a comment within the code.
LGPL/EPL. It allows a programmer to link to open source libraries in their software. If a programmer simply compiles or links an LGPL-licensed library with your own code, you can release your application under any license you want, even a proprietary license. But if you modify the library or copy parts of it into your code, you’ll have to release your application under similar terms as the LGPL.
CopyLeft. Commonly known as reciprocal licenses or restrictive licenses, allow users to modify code and distribute derivative work with the stipulation that users distribute adaptations under the CopyLeft license.
Proprietary. It is the most restrictive type of software license available. The owner can restrict the use, inspection of source code, modification of source code, and redistribution.
Because the main focus of this work is on the Open Source Licenses, I will consider every category except for Proprietary.
There are hundreds of open-source software licenses, with different terms, support agreements, and restrictions. As a regular GitHub user, I will review all licenses which are offered there. In total, there are 13 most popular licenses on GitHub:
Apache License 2.0, MIT License, BSD 2-Clause “Simplified” License, BSD 3-Clause (the most popular variant) “New” or “Revised” License, Boost Software License 1.0, Creative Commons Zero v1.0 Universal, Eclipse Public License 2.0, GNU Affero General Public License v3.0, GNU General Public License v3.0 (GPLv3), GNU General Public License v2.0, GNU Lesser General Public License v2.1 (LGPL), Mozilla Public License 2.0, The Unlicense.
Despite the overwhelming amount, not every license is highly used by the developer community. The most popular open-source licenses are MIT, Apache 2.0, GPL 3.0, BSD 2.0
Thus, it is possible to categorize the licenses into the right categories. It will give a better overall understanding of what each type of license represents.
Public Domain License include The Unlicense, CC Zero v1.0 Universal
Permissive licenses include the MIT license, Apache License 2.0, and the BSD 2, 3 Licenses, Boost Software License 1.0
Copyleft licenses include the GPL v2 and GPL v3, GNU Affero General Public License v3.0, Mozilla Public License 2.0.
Something in the middle:
As Eclipse foundation claims “Bridge between permissive and strong copyleft licenses include Eclipse Public License 2.0”. Similar claims are made for the GNU Lesser General Public License v2.1 (LGPL)
It is worth mentioning that all mentioned licenses explicitly state that they do NOT provide any warranty and liability.
On the other hand, all mentioned licenses allow the licensed material to be modified and used for private, commercial purposes.
The Unlicense. A license with no conditions whatsoever which dedicates works to the public domain. Unlicensed works, modifications and larger works may be distributed under different terms and without source code.
CC0. It is exactly as The Unlicense, with the additional specifications: This license explicitly states that it does NOT grant any rights in the patents of contributors, trademark rights. Though, it is a much longer license than The Unlincense license.
What stands out about the public domain is copyright notice inclusion is not required what cannot be said about permissive licenses.
MIT license. MIT is the most recommended permissive license: short and very popular (probably the most used worldwide). It says: “You can do whatever you want as long as you include the original copyright, license notice in any copy of the software, and don’t blame me for any damages the software may do”.
Apache 2.0. Same as MIT, but with little less permissive and more words. Notably, if you change any Apache-licensed code, you must state so. There are also rules about the usage of the project name:
“This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.”
The Apache license is notable among open-source licenses for including language dealing with patents:
“If You institute patent litigation against any entity … then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.”
BSD 2. It is equivalent to MIT. What is mentioned under MIT is implied by the BSD license. So, it could be considered more ambiguous than MIT
BSD 3. Requires your permission before mentioning your name for any work built on top of your software. “Neither the name of the [organization] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.”
Boost Software License 1.0. It is the same as the MIT but it benefits by explicitly specifying that binary forms do not require attribution. So, it could be considered less ambiguous than MIT
GNU Lesser General Public License v2.1 (LGPL). This license is mainly applied to libraries. You may copy, distribute and modify the software provided that modifications are described and licensed for free under LGPL. Derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use the library don’t have to be.
Eclipse Public License 2.0 (EPLv2.0). A notable difference between the LGPL (Lesser General Public License) and other weak copyleft licenses is that the LGPL does not allow users to sublicense binaries under other terms, while this license does allow. It also has no obligation on its linking to libraries
GPL v2. You may copy, distribute and modify the software as long as you track changes/dates in source files. Any modifications to or software including (via compiler) GPL-licensed code must also be made available under the GPL along with build & install instructions.
GPL v3. GPLV3 to the GPLV2 has more clarity on patent licenses, mostly on the wording of the license as it cannot be interpreted as “too broad.” It also applies to the protection of the patents, unlike the GPLV2. They addressed specifically what happens if the license is violated and the cure of violations
GNU Affero General Public License v3.0. it was built for network software. You can distribute modified versions if you keep track of the changes and the date you made them. As per usual with GNU licenses, you must license derivatives under AGPL. It provides the same restrictions and freedoms as the GPLv3, but with an additional clause that makes it so that source code must be distributed along with web publication. Since websites and services are never distributed in the traditional sense, the AGPL is the GPL of the web.
A product may be under many licenses, even completely contradictory licenses. When a programmer dual licenses something the recipients get to choose which license they will accept the work under. They only choose one, so it does not matter if another license would give them contradictory rights.
A great example is this file https://github.com/docopt/docopt.rs/commit/11b5ff3d3939b7d4ba0e09e457f802a37bb5c5dc
The authors of docopt.rs have probably done this because in some jurisdictions it is difficult or perhaps even impossible to put work in the public domain. By dual licensing with the very permissive MIT license, they solve that problem by providing a license that is valid everywhere.
It all depends on how the software will be used. If the code will be a part of a bigger ecosystem, there more likely have been already a license. Thus, a programmer has to take it into the consideration.
In other cases, a developer shall think about how others should use their software. If it is a library that others will use to create their software, the creator should think if they want their code to be disclosed public (Copyleft license), or to get attribution (Permissive), or nothing (Public Domain License)
Many open-source licenses dictate how or if the software can be used in commercial applications. One can choose if companies can use their libraries in commercial applications and the requirements and restrictions under which they can do so. Be mindful of the target audience. A large enterprise company with lots of intellectual property within its application may not want to use the library if it means it cannot keep its code under wraps. Or they may shy away from using your software if it prevents them from distributing their software commercially. For example, Chris Anderson, former Editor-in-Chief of WIRED, developed his project under the GPL v3 Copyleft licenses. When his team decided to commercialize, no tech company wanted to use it. Indeed, it’s rare that investors would like to buy something that they’re forced to open-source.
Another thing is simplicity. No one would want to hire a lawyer and spend hours agonizing over the license that a programmer attached.
If a programmer is afraid that their software will not be widely used, a lengthy strict license may even push away people from using the programmer’s code. MIT type of license is short, so that should be ok, but the Apache and GPL are long.
To be specific, in my opinion, these programmer’s needs will be satisfied with the following licenses:
The Unlicense/CC0 — if one simply doesn’t care much about the usage of their code
BSD 3 — If you’re publishing a piece of code that you want to distribute as much as possible, maybe having other people help you with the code, making sure you’re not going to be sued as well as making sure that your name or your company’s name are not going to be used by others without your approval,
MIT/BSD2/Boost — if you’re afraid of nobody using your software, because of the length and permissiveness of your license. There is something to the ambiguity, thus, review each separate license mentioned above.
Apache — if you’re afraid of legal ambiguity and patent trolls. Some lawyers/corporations prefer Apache 2 over MIT/BSD/Boost because of that
LGPLv2.1 — if you want to protect your libraries from the modifications
It is important to keep in mind. if you choose to change the copyright license in the future “a” release, say, to MIT, everyone would be able to modify the software starting from the “a” release
Eclipse Public License 2.0. — if you do not care about linking and sublicensing binaries under other terms.
GPL v2/v3 — if you want to stop everyone unfairly using your work (e.g. making money on your back bothers you). If they use your software, they will have to use the same license as you (i.e. probably open-source it).
GNU Affero General Public License v3.0. — if you enjoy GPL licenses, and want to have similar, but for the network software
To make things even simpler, consider this decision diagram to choose the proper license
The decision diagram; accessed on 12.02.2022 — https://digitizor.com/free-software-licenses/
In most cases for both a new and existing project, one may place the license at the root of your project source. However, if it is an existing project, probably a good idea will be to place the license in the new release/tag. This is because such an event tells everyone: “Starting with version x.y, my software is distributed under the license z.” Here is an example where I placed the license in my repo:
Also, if you use GitHub, you may easily generate a license with built-in features. To do so, simply go to the repository, press on add file → create new file → name it “license”, then you will see many License templates available.
A good practice shows, it is a great decision to place a copy of the license in the README.md file under a License section.
If the license is very lean (for example MIT or BSD ), it is recommended to also add it at the beginning of all your source code files. when the license is lengthy, you may simply want to add at the beginning of each file the name of the license with a link to the full license (i.e. the LICENSE file at the root of your project). Here is an example of what you could add at the top of each of your source file:
Copyright (c) (year), (copyright holder)
All rights reserved. This source code is licensed under the BSD-style license found in the
LICENSE file in the root directory of this source tree.
Yet, nothing is preventing you from putting it in a logical place. If there is a convention, it is to place the file in the root of the application folder. If you have a large number of licenses, then you may want to create a folder underneath your application called “Licenses” and list all of the applicable licenses.
Accessed on February 9, 2022:
Software Licenses Explained
Licenses
JLA – Find and compare software licenses
Licensing a repository – GitHub Docs
What is a software license? 5 Types of Software Licenses | Snyk
How to Choose the Right Open Source License – FOSSA
Comparing Open-Source Software Licenses
How to Apply a License to Your Open Source Software Project – FOSSA
What you need to know to choose an open source license.
Top open source licenses and legal risk | Synopsys
Appendix
Accessed on February 12, 2022:
What’s the difference between Apache v2.0 and MIT license? What are the major consequences of using Apache software over MIT?
Difference Between GPLV2 and GPLV3
GNU Affero General Public License v3 (AGPL-3.0)
Program 01 Analyzing There is no possibility for a user to change the password without…