How Does Open Source Licensing Work?

To explain open source licensing, we must start with the definition of license for software. It relates to the universal concept of copyright; for software, copyrights extend to the code and execution of the software — in other words, the source code and binary code (executable). The authors of the software hold the copyrights, consequently possessing legal authority over the software as well as any derivative work. 

A proprietary software license grants permission or rights to someone other than the copyright holder to use the software under certain legal terms and conditions.In contrast, open source licenses explicitly grant the rights to not only use, but modify, or distribute the source code, executable binary code, and modifications.  

Open source permissive licenses grant users freedom in using, modifying, and distributing the software. They allow developers to incorporate open source code into their projects including proprietary software, and do not impose obligations on attributions or alternative licensing use.  

Examples of permissive licenses include the 3-Clause BSD license, the MIT License, and the Apache 2.0 License. 

The second type of open source software license is the copyleft license. These are known for their reciprocity clauses and require any derivative works to be distributed under the same license as the original software, which includes making the source code available under that license. This means that copyleft licenses limit the ability to use other license models, such as permissive or proprietary, for derivative software.  

The GNU General Public License (GPL) family of licenses are examples of copyleft licenses: GPLv2, GPLv3, LGPLv2, LGPLv3, and AGPL among others. They grant the right to copy, modify, and distribute the software under the condition that the resulting software is again distributed under the identical GPL license and the source code must be shared. Some copyleft licenses include exceptions to that condition to allow the use of their software for specific use cases. 

The GPLv2 license for Linux distributions was recently a topic of discussion due to Red Hat’s public restriction of RHEL source code availability that happened in June 2023.  

The answer to this question depends on a few different factors, but the key consideration is what you want to allow other people to do with your code:Do you want to keep it open source or you agree to have your code as part of proprietary or commercial software? You also have to consider if you want to credit yourself as the author as part of the license (attribution). 

Here are a few things to consider when deciding what open source license to select for your open source software: 

• Reflect on whether you’d feel at ease with someone else developing, hosting, selling, or distributing a version of your open source project. If you are comfortable with that scenario, a permissive license would be a good fit and then you can select one based on minor differences between MIT, Apache, or other permissive licenses. 

• If you prefer to ensure that modifications to the source code remain open source, consider a copyleft license. 

For open source at your workplace, you should consult with a lawyer or legal expert on copyright and open source licenses. A legal team should be able to recommend the license that is best suited for your organization.

Organizations of all sizes and in all industries should establish a systematic approach for identifying and monitoring the presence of open source components in all software to maintain open source compliance. Organizations should define polices to stipulate that no open source component is integrated or used by other software without a prior identification of its origin, version, and open source license.  

As previously described, copyleft licenses can present restrictions if the software is going to be commercialized. Organizations should generate a software bill of materials (SBOM) that includes open source license information. This process ensures transparency and compliance with open source licensing requirements within your software development practices. 

Watch video >> Open Source Software Compliance

Sometimes an open source community and maintainers of an open source project decide to switch to a different license. This is not a common practice but it does occasionally happen. Changing from an open source license to a non-open source license is always newsworthy, and has an impact on other open source projects and organizations that commercialize or depend on the software that is no longer open source.   

HashiCorp’s decision to move its popular open source projects (Terraform, Consul, and Vault) to a Business Service License (BUSL) caused a stir because this "source available" license prohibits commercialization. Under this license, activities such as reselling, hosting as-a-service, or bundling with commercial software are not allowed. This is clearly no longer an open source license. When a license change like this happens, it is not unusual for a project to fork; in this case, OpenTofu, a Terraform fork, is already gaining traction and is backed by the Linux Foundation.  

Individuals and organizations must have a long-term view with regards to open source license selection. To maintain positive relationships with contributors and customers, organizations must choose a license at the outset — permissive, copyleft, or non-opensource — and not change course. Altering from an open source license to a closed one can result in unfavorable publicity, tarnishing the organization's reputation and affecting the broader open source community. 

Teams should do their homework before selecting an open source project; the size of the community, release life cycles, and the number and origin of its contributors are important criteria to consider. Open source projects driven by a single, for-profit organization have a higher risk not only changing license terms, but also making unilateral decisions in the architecture and roadmap of the open source project. 

Author's Note: There were many sources and publications that inspired this blog post, including the Linux Foundation’s “Introduction to Open Source License Compliance Management” course and the book Open Source Law, Policy and Practice, edited by Amanda Brock. 

One Vendor For All Your Open Source Software

For more than two decades, OpenLogic has partnered with organizations to support open source software in their infrastructure. Today, we provide technical support and LTS for more than 400 open source technologies, and professional services including migrations and training. Connect with us to learn more! 

TALK TO AN EXPERT