When considering open source risk, you immediately think of vulnerabilities that have led to high-profile breaches like Equifax’s. Though open source license violations grab fewer headlines, they still present a significant risk on their own. This blog defines what an open source license is, identifies the two main types of licenses, and highlights why you should always know what type of license you’re using. We’ll also look at some of the key characteristics of several popular open source licenses so you can understand more about what you’re using.
This blog is intended for informational purposes only and should not be taken as a substitute for legal advice.
What Is an Open Source License Anyway?
Many people think that because open source is free to use, that it isn’t licensed. The truth is that open source, like most software, is subject to licensing agreements.
Open source licenses are designed to address intellectual property laws that restrict the modification and sharing of creative work like software. They use existing copyright laws to facilitate the use of open source by protecting the freedoms that promote sharing and collaboration.
Open source licenses define how you can use, modify, and distribute a specific piece of open source software. Because some licenses are more restrictive than others, it is important to understand their differences.
Open Source Licenses: Copyleft Versus Permissive
Open source licenses fall into two main categories: copyleft and permissive. In general, copyleft licenses place more restrictions on the use of open source code than permissive licenses do.
Copyleft Licenses
A hallmark of the open source movement is its transparency. Anyone who wants to can inspect lines of code to understand how that code works or to troubleshoot a problem. In this spirit of visibility and reciprocity, copyleft licenses allow anyone to use, modify, and share a work as long as the derivative work is also made open for others to use. With copyleft licenses, derivative works inherit the original open source code’s license terms.
While this collaborative approach has created many notable open source projects, it can be problematic for software companies that want to create proprietary derivative work.
Copyleft licenses are often called restrictive licenses because they restrict the creation of proprietary derivative works. This means that if you’re developing an application that uses open source libraries with a copyleft license, the license often requires you to make your codebase open source as well.
Common copyleft licenses include the GNU General Public License (GPL), the Affero GPL (AGPL), the Eclipse Public License (EPL), and the Mozilla Public License (MPL).
Permissive Licenses
Permissive open source licenses guarantee the freedom to reuse, modify, and redistribute open source code. They also allow for proprietary derivative work. Under a permissive license, using open source components while building a proprietary solution does not require you to make your entire codebase open source.
This type of license is appealing for organizations that want to sell proprietary applications that contain open source components. Given that modern applications are about 80% open source, knowing that you’re using components with permissive licenses is imperative. Note that permissive licenses do vary in the amount of freedom to modify and redistribute code with some having fewer requirements than others.
Common permissive licenses include the Apache License, the MIT License, and the Berkeley Source Distribution License (BSD).
Open Source Licenses
The most common open source licenses are identified below. Note that there are more than 80 different open source licenses in regular use.
Apache License
Permissive, Low Risk
Released by the Apache Software Foundation (ASF), the Apache License is currently one of the most widely used open source licenses, recently edging out the ubiquitous GPL in popularity for new open source components. The Apache License allows you to freely use, modify, and distribute any Apache licensed product. While it does require license notifications and copyrights on distributed works, derivative works are allowed to carry different licensing terms. Source code in derivative work is not required to be open.
Berkeley Source Distribution License (BSD)
Permissive, Low Risk
The Berkeley Source Distribution License allows you to freely modify and distribute your software in source code or binary format. It does require you to retain a copy of any copyright notices, list of conditions, and disclaimers. This license has several variations, including the Simplified BSD License (2-clause) and the Modified (or New) BSD License (3-clause). The Modified BSD license has more requirements related to reusing code, making it slightly more restrictive.
Eclipse Public License (EPL)
Copyleft, Medium Risk
The EPL is most often used for business software. Software developed using EPL, non-EPL, and even proprietary code can be combined and sub-licensed as long as any non-EPL elements reside independently as separate objects or files. Modifications are allowed under the EPL license, but they must be released under the same terms. The EPL protects the author from liability or damages caused if a company uses a component in a commercial product. Finally, the EPL offers a patent grant.
Gnu General Public License (GPL)
Copyleft, High Risk
The GNU General Public License is the most used open source license. Because it is a copyleft license, any software based on a component with a GPL license must be released as open source. GPL has two main versions – GPLv2 and GPLv3. The two licenses have many differences, for example over the coverage of patents, and they are not compatible with one another.
Gnu Affero GPL (AGPL)
Copyleft, High Risk
The AGPL was written to close the cloud services loophole in the GPL licenses, and the two licenses have many similarities. It is a free, copyleft license specifically designed to ensure that derivative source code remains open in the case of network server or SaaS software that is not explicitly distributed.
MIT License
Permissive, Low Risk
Named after the Massachusetts Institute of Technology where it was created, the MIT License is one of the most permissive open source software licenses available. The MIT License is popular because it is short and very easy to understand. Under the MIT license, developers are free to use, modify, and distribute code as long as the original MIT license and copyright notices are included. The MIT License removes liability from authors. It does not explicitly contain a patent grant.
Microsoft Public Licenses (Ms-PL)
Copyleft, Medium Risk
The Ms-PL License allows for the distribution of original or derivative works of any software licensed under the Ms-PL license. However, you may not use any contributor’s name, logo, or trademarks when doing so. The Ms-PL License protects authors from liability by explicitly denying any express warranties or guarantees. The license requires that all copyright, patent, trademark, and attribution notices in the original software are retained in derivative work. Additionally, if you distribute any portion of the software in its source code form, you may do so only under the Ms-PL by including a complete copy of this license. Any portion of the software in its compiled or object code form may only be distributed using a license that complies with Ms-PL.
Mozilla Public License
Copyleft, Medium Risk
The Mozilla Public License (MPL) is the least restrictive copyleft license. The MPL allows users to modify or use code in proprietary software as long as any code licensed under the MPL is kept in separate files that are distributed with the software and copyright notices are retained. The MPL also includes patent grants.
The Unlicense
Permissive, Low Risk
The Unlicense is probably the least restrictive open source license available because it essentially gives the open source to the public domain. No conditions apply, meaning these unlicensed works can be distributed without source code and under different terms and licenses.
The Risk of Open Source Licenses
Organizations may be violating open source software license requirements if they aren’t actively monitoring the licenses associated with the open source components they are using in development. Failing to adhere to licensing requirements puts you in violation of copyright law. Copyright violations could result in a lawsuit costing millions of dollars. It could also require you to open source your proprietary code.
For example, using an open source component with a GPL license requires an organization to make its entire software solution open source. This is problematic for any software vendor that plans to sell its software.
Given the gravity of the risk, monitoring open source licenses to protect your intellectual property should be a baseline requirement for every business. In addition, as Software Bills of Materials (SBOMs) become the standard for doing business, more companies will require you to know what’s in your software. This includes both open source libraries and open source licenses.
Which Open Source License Is Right for You?
When you consider how much of modern codebases are open source, you quickly realize the importance of understanding the impact of open source licenses. Even understanding the basic differences between copyleft and permissive licenses will help you protect your intellectual property from future copyright infringement claims.
With the speed of modern development lifecycles and the volume of open source components in play, automating the management of open source license policies is a necessity. Software composition analysis (SCA) solutions, which help you identify open source vulnerabilities, can also help you manage your open source licensing obligations. The best solutions allow you to create custom policies that prevent any restrictive or user-defined non-compliant licenses from being merged into your codebase.
Learn More About Cycode SCA
Cycode provides a comprehensive next-gen Software Composition Analysis (SCA) solution that identifies open source license policy violations. Not only that, but our solution scans for known open source vulnerabilities both in application code and throughout the development pipeline. For example, we look for known open source vulnerabilities in build files, Jenkins Plugins, GitHub Actions, IaC templates, and more. Cycode is also able to identify the path of vulnerable components from source code through to production environments so you can respond quickly to zero-day threats.
Want to learn more? Book a demo now.
