License Compatibility: Combining Open Source Licenses
Free and open source software (FOSS) components have become the basic building blocks of our software products, helping today’s developers build and ship innovative products faster than ever before. Many developers tend to forget that while open source licenses are free, they still come with a set of terms and conditions that users must abide by. You got it folks, we’re talking about open source licenses, and license compatibility is a concern that anyone harnessing the power of open source needs to address.
Why is open source license compatibility important?
Every open source project, whether it’s a couple of code snippets to support your API or your favorite browser, comes with a license. An open source license is what makes a component open source. It is a contract between the creator and the user of a software component, which allows the software to be added to commercial applications as long as the user abides by certain terms and conditions.
While the open source community encourages developers and organizations to use open source components, combining a number of licenses can be a challenge since different licenses’ permissions, requirements, and conditions can conflict with each other. Sometimes a developer will combine multiple components licensed under different open source licenses with direct dependencies or transitive dependencies. This raises the legal concern of whether their licenses are compatible.
How open source license compatibility can get complicated
There are currently over 70 OSI (Open Source Initiative) approved open source licenses, and each one offers a different set of terms and conditions. Each open source license has its own unique set of limitations, conditions, and permissions. Usually, the licenses address issues like:
- What kind of recognition is given to the code’s creator?
- What permissions are granted to the project’s users?
- How should the source code be distributed and made available to other developers?
- Are there conditions under which users aren’t required to distribute the source code?
- Under what conditions can users distribute their software commercially?
Combining two or more different open source components is not an issue as long as the terms and conditions in the licenses are compatible, but how can you know if they are? Unfortunately, this is a tricky question, since the answer depends on the type of licenses and their hierarchy in your application.
License compatibility basics: Permissive vs. Copyleft
Open source licenses vary based on the obligations they require of the users and the permissions they grant. Based on these parameters, open source licenses are divided into two main types: permissive and copyleft.
A copyleft license allows users to use, modify, and share the work under the condition that the reciprocity of the obligation is maintained. Components with a copyleft license require users to make their code open for use by others as well.
On the other side of the spectrum are the permissive open source licenses, which give users the freedom to use, modify, and redistribute, and allow proprietary derivative works, while placing minimal obligations or restrictions on users.
Image source: David A. Wheeler
Permissive open source licenses compatibility
In general, permissive licenses are compatible with each other. That’s because they have no requirements when additional code added to the program, enabling the merging of the open source components into a proprietary software product. In this case, the application should be able to carry all open source licenses.
In most cases, permissive licenses are also compatible with copyleft licenses. There are two exceptions to this rule: The Apache 2.0 license and the original (4-clause) BSD license. The Apache 2.0’s license partner rights make it incompatible with GPL v2, but it is compatible with GPL v3. The 4-clause BSD license’s advertising clause makes it incompatible with all copyleft licenses. The modified (3-clause) BSD license doesn’t include the problematic advertising clause, so it is compatible.
GNU GPL and Copyleft license compatibility
The most problematic practice is combining two copyleft licenses. As a rule of thumb, copyleft licenses are incompatible unless they have explicit compatibility provisions.
As Richard Stallman, creator of the GNU GPL license explains: “If license A says extended programs must be under license A, and license B says extended programs must be under license B, they have an irreconcilable disagreement; the license of the combined program would have to be A, and it would have to be B.”
License compatibility is key to open source license compliance
60%-80% of all software consists of open source components. This goes for proprietary software, as well as open source projects that are built using other FOSS components. As open source components become an integral part of software development, ensuring open source license compliance must also be regarded as part of the process.
Clearly, we can’t expect developers to know the ins and outs of open source licenses terms and conditions and check their compatibility when using open source components. The best way to manage license compatibility is by leveraging a DevOps tool that automatically tracks open source components’ licenses, restricting incompatible licenses.
Open source license compatibility is a complex business. As software development organizations step up their DevOps practices, it’s important to adopt tools that can also address regulatory and compliance issues. Automated tools can help organizations cross the dreaded license compatibility issues off their list of troublesome tasks.
*Disclaimer: This post is not legal advice, it is for informational purposes only. If you need legal advice, you should consult with an attorney who has reviewed all relevant facts and applicable law.
