Not all free and open source (OS) software licenses have been created to achieve the same goals, and failure to understand the differences can have dire consequences. Some OS licenses are business-friendly in that they allow the code to be combined with proprietary code without imposing OS licensing requirements on the resulting combination. Others do not allow such combinations in any circumstances (at least if the developer wishes the products to remain proprietary), and some licenses fall somewhere in between these two extremes. Here is the minimum you need to know about OS license types before incorporating OS code into software you develop.
Some Background on Open Source Licensing Paradigms
“Copyleft” OS licensing arose from the free software movement, which is premised on the ethical belief that all software should be free (i.e., free as in “freedom”, not price). Therefore, copyleft licenses are intentionally designed to prevent downstream works from being licensed on a proprietary closed source basis. In contrast, permissive licensing is more commercial-friendly because it arose from the open source software movement, which is focused on the pragmatic business case for OS software rather than ethical imperatives. For a more in-depth discussion about how OS license types evolved from the free and open source software movements, see A Brief History of Open Source Software, Part 2: OSS Licenses and Legalities.
What All Open Source Licenses Have in Common
All licenses that comply with the Open Source Definition will grant recipients of the software the freedoms to use, run, study, modify, and redistribute the OS software in source code or compiled form for any purpose. These are considered “essential freedoms” within the free and OS software movements. Additionally, almost all OS licenses also contain notice and attribution requirements that you must comply with. This is where the commonalities of OS license types end. Their differences are greater and, from a commercial perspective, far more consequential.
Permissive vs. Copyleft
Permissive licenses, such as Apache License v.2.0, the MIT License, the BSD License (both the 2-clause and 3-clause versions), grant all of the “essential freedoms” described above, but do not require that these freedoms be maintained in downstream works. In other words, you can modify permissively-licensed OS code and incorporate it into a larger program that you create, and you are free to distribute the modified version or the larger program under license terms of your choice. Thus, you would be free to distribute your downstream work as proprietary closed source software, or you could distribute it under the same or different open source license terms of your choice. Because permissive licenses don’t tie your hands with respect to downstream works, there’s not much of a downside to using permissively licensed OS software in any application or for any business use case.
In contrast, copyleft licenses require that downstream works be licensed under the same copyleft license terms to ensure that downstream recipients also have the essential freedoms to access the source code and use, modify, and redistribute it for any purpose. Downstream works based on copyleft components cannot be distributed on a closed source proprietary basis, or even under permissive OS license terms. For this reason, copyleft licenses are also referred to as “restrictive” OS licenses. Copyleft licenses vary in how broadly they apply to downstream works, and for this reason are broken down into subcategories of “strong copyleft,” “weak copyleft,” and “stronger copyleft,” discussed below.
The GNU General Public License (GPL), the most commonly used copyleft license, is often referred to as “strong copyleft” because it applies not just to modifications you make to OS code licensed under the GPL, but also to any downstream work “based on” such code, including a program that includes only a few lines of GPL’ed code or that merely links to a GPL’ed component or library. For example, if you incorporate a GPL-licensed component into a larger software program, the entire combined software program would be subject to the terms of the GPL, and you could not distribute it as proprietary closed source software. Thus, before incorporating copyleft-licensed OS code into a product you distribute or an outward-facing service, you should first consider whether the downstream restrictions it imposes are aligned with your business goals and intended use case.
Some OS licenses are considered “weak copyleft” because they permit some types of interaction between a copyleft component and a larger combined work without requiring that the larger combined work be licensed under the same copyleft terms. For example, the GNU Lesser General Public License version 3.0 (LGPL) allows you to link an LGPL’ed library with a larger work without requiring the entirety of the combined work to also be licensed under the LGPL, so long as you provide sufficient access to the library’s source code and the larger work’s object code to enable the recipient to modify the LGPL’ed library and relink it to the larger work.
In the other direction, the GNU Affero General Public License (AGPL) is considered a “stronger copyleft” license because it closes what is often referred to as the “SaaS loophole” in the GPL. The GPL’s requirement to license downstream works under the same terms is only triggered when the downstream work is “distributed.” In today’s world, many software programs are offered as a cloud-based services rather than “distributed.” Therefore, it is possible to modify a GPL-licensed component and include it in an outward-facing service without having to license its source code under the GPL. The AGPL was developed to close this loophole. If you modify an AGPL-licensed component and allow others to interact with it remotely through a computer network, you must make the source code of the modified version available under the terms of the AGPL.
A Few Words of Practical Advice
There is little or no downside to using permissively licensed open source software for almost any business use case, including outward-facing services and products you distribute. You would still need to comply with the notice and attribution requirements of the permissive licenses, but the benefits of using the OS code are probably well worth the minimal compliance obligations.
Copyleft-licensed open source software can also be used for commercial applications, but requires careful evaluation of whether the license restrictions are aligned with your intended use case and business objectives. Some companies allow use of copyleft-licensed code for some use cases but not others. For example, some companies allow the use of copyleft-licensed code internally for development and testing, but prohibit their use in outward-facing services and distributed products. Other companies evaluate proposed uses of copyleft code on a case-by-case basis.
The circumstances under which your company allows, encourages, or restricts the use of OS code made available under various license types should be aligned with the company’s business model, strategic goals, and operational objectives, and be clearly documented in an open source usage policy that is developed with input from your engineering, developer, product, legal, compliance, and executive leadership teams. It is also recommended that your company provide all developers with training in how to comply with its open source usage policy.