Today’s internet is built on open-source software, thus it’s natural to build your startup with it too. However, to be sure that you are not breaking the law by the way the software under open-source licenses is used in your project or app.
In our previous article, IP rights in software development, we stated why not transferring Intellectual Property rights for the software developed to the client is unreasonable. Also, we shared some best practices and our experience in IP rights transferring. Continuing the topic, in this article, we outline specifically how to adopt the most popular free and open-source licenses in your project.
1. Open-source software vs Free software vs Freeware
The ground notion is that “open-source software”, “free software”, “freeware” and “public domain” are different concepts. These definitions do NOT refer to the types of the software, but to the values lying underneath. They might intersect in various manners and refer to the same set of licenses. For example, the majority of free software licenses are also considered open-source software licenses, like well-known Linux, Ubuntu, MySQL, to name a few.
Look at the table below to evaluate similarities and differences between free and open-source software, public domain and freeware, and some examples of known relevant software:
Thus concluding: a choice of terminology may imply a different emphasis in underlying values.
Open-source license criteria focus on the availability of the source code and the ability to modify and share it, while free software and public domain focus on the user’s freedom to use the program, to modify it, and to share it. Freeware (examples are Skype and Adobe Acrobat), in its term, is mostly aiming commercial goals and potential monetization often used as a “freemium” product.
2. Copyright vs Copyleft vs Permissive vs Creative Common
These terms are used to compare legal attributes of open-source and free software and other content publicly available licensing to proprietary licenses.
Permissive licenses place minimal restrictions on software users. Often they only require that the original creators are attributed in any distribution or derivative of the software or source code.
For example, the software under permissive license may be incorporated into the other proprietary software without disclosing the source code, and this newly created software may be distributed. Because of their origins, permissive open-source licenses are sometimes called “academic” licenses and frequently used by academic institutions.
To guarantee unlimited open-source access to their work software developers employ the concept of “copyleft”.
Copyleft uses copyright’s legal framework to ensure continued open access to software and its source code. The core requirement that any derivative work must be distributed under the same licensing terms as the original. Because of this requirement, copyleft licenses are considered “restrictive” licenses, though these restrictions guarantee open access.
Creative common is most commonly applied to various content that used along with software i.e. images, videos, texts, etc. There are 6 Creative common licenses, which we will not cover in this article.
3. MIT vs BSD vs Apache vs GPL vs LGPL vs AGPL
Although there is an enormous amount of various licenses on the market, we will cover only a few most popular ones, which we at Moqod frequently use for developing projects for our clients.
Here are the most popular open-source licenses in a simplified comparative table and a brief outline one by one:
Apache 2.0 is the most modern and balanced among permissive licenses. It is written clearly regarding the modern copyright usage rules, in particular, patent relationships. Apache-licensed software can be used in your commercial project for free. The only restriction is trademark use:
- don’t name your project like it is an endorsement from Apache
- don’t use their famous feather logo anywhere in your project or documentation.
BSD – Berkeley Software Distribution – is often mentioned interchangeably with MIT due to very similar language and terms that accomplish largely identical goals.
The BSD License allows releasing proprietary software and incorporating this software into proprietary products as long as the original copyright and license requirement is fulfilled.
MIT is a mythical license, as there is a myth that there is a license called MIT. This is because Massachusetts Institute of Technology initially used a lot of different licenses, like the Expat and the X11.
This license is permissive without copyleft and, as we already mentioned, is similar to BSD. It permits reuse within proprietary software with including a copy of the MIT License terms and the copyright notice. The mall size is an advantage of this license. The disadvantage is an inability to regulate patent relationships.
GNU GPL – General Public License – is the most known among open source licenses. Not because it is the easiest to understand, but mostly due to multiple mentions and references. As they call it “open license,” many think that the code delivered under GPL may be used in any possible way and programs made with it are entirely free of charge. However, statements are not valid.
The GPL is a copyleft license, meaning that any derivative works must be open-source and distributed under the same license, which makes it inappropriate to use in the proprietary software. As we already mentioned above, this is the most significant distinction to permissive free software licenses like BSD and MIT, widely-used less-restrictive examples. There are also GPLv2 vs. GPLv3.
GNU LGPL – the “Lesser GPL” – is a copyleft license, very similar to the GPL, from which it is derived, but with weaker copyleft requirements. It allows software being applied in a proprietary project under certain circumstances and to some parts of the project’s code. The LGPL is usually considered as a compromise between the strong copyleft licenses like GPL and permissive licenses like the BSD or MIT.
GNU AGPLv3 – Affero General Public License Version 3 – is also a copyleft license. Its terms are almost identical to terms of GPL with the additional paragraph, which allows users, interacting with the licensed program online to get the source code of the program. Thus usually it is not recommended to apply GNU AGPL for any commercial projects performing online.
4. Licenses compatibility
In case of collective, combined or aggregated work the concept of licenses compatibility arises.
License compatibility is a characteristic of a license according to which the code distributed under this license may be integrated into a bigger software that will be distributed under another license.
For example, copyleft license’s demand that any derived work combined from code under various licenses is applied to the copyleft license.
The widely-used licenses mentioned above tend to be compatible, but with some nuances, which could make it sometimes legally impossible to mix them. Thus we recommend investigating closer and be aware of license compatibility, before adopting them.
5. Conclusion and useful links
Surprisingly, while the majority of commercial licenses aimed to bound the user contain precise instructions, the most open-source software licenses, intended to guarantee freedom of usage, are written in an extremely complicated manner. We hope that our overview will help you to see the big picture on the licensing topic and will serve you as a crib. Here are some useful links for further research :
- About licenses popularity: https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions
- A great shortcut on the open licenses true\false: https://www.codeproject.com/info/Licenses.aspx
- A useful resource where pros and cons of each license outlined: https://www.slant.co/topics/1141/~best-open-source-licenses
- About licenses compatibility: https://www.gnu.org/licenses/license-list.en.html