Compliance & Risks
How to navigate open source licensing risks
Vulnerabilities aren't the only risk that comes with open source software use. Learn how you can best mitigate licensing risks to ensure your team is meeting all legal requirements while building with open source code.
Save to Folio
In alignment with the acceleration of digital transformation, the use of open source code components is exploding thanks to the speed, flexibility, extensibility, and quality they offer application development teams. The sacrifice, however, is an expanded attack surface with new risks like increased legal and intellectual property exposures.
Open source software innately falls under intellectual property protections, specifically copyright laws. Once a developer uses open source software in their application build, their organization is obligated to meet any terms or conditions specified in the associated license. This is why many organizations that are further along in their cloud migration have specific open source legal resources on retainer or on staff.
So why aren’t more businesses keeping a closer eye on their application development team’s use of open source components and risk mitigation? Let’s look at some scenarios.
I am assured my organization’s dev teams are not using open source code extensively, what’s the big deal with open source licenses?
Well, simply put, if an organization releases an application containing open source software without meeting the requirements of the license, they are committing intellectual property infringement and are legally liable. According to Snyk, at least 80% of any given application is open source nowadays. Organizations need to be more aware of any shadow open source use. Not only can the copyright owner sue the organization for infringement, but there are also non-profit organizations, like the Software Freedom Conservancy that monitors the use of open source software and will file lawsuits when violations are committed. These lawsuits not only result in monetary damages, but they can create customer and public relations nightmares!
A footnote acknowledgement is all that is needed for open source licenses, right?
It is important to know what you are dealing with so that your organization can follow the best conduct. There are two main types of open source licenses. Permissive licenses follow basic copyright concepts and mainly just require the attribution to the original developer, and not much else. Whereas Copyleft licenses (meant to be the opposite of copyright) fall back to the traditional software freedom concept and build this into the license requirements to promote code sharing.
Permissive licenses are the more business friendly of two, due to their simplicity and ease of use. As such, it is no surprise that they represent most open source licenses, accounting for 76% in 2020. A commonly used permissive license is the MIT license, often chosen for its short and simple nature. This license gives the users full permission to reuse the software, with the only requirement that the license text and copyright notice must be included upon distribution of the software.
Copyleft licenses, usually versions of General Public License (GPL), create risks when used in a commercial software application codebase, as it can result in issues to the overall application’s intellectual property. As such, many organizations pre-set the associated risk level of any GPL licenses in their system to high.
Recently, as the result of many open source license proliferations, as large corporate organizations take open source code and release it as a commercial service, intercepting the monetization of the open source, a new category has emerged. This third type is called source available, and although it is like open source, it is different technically because of the added restrictions needed to prevent corporations from capitalizing on it. Essentially, it gives the author the ability to share their code openly for collaboration purposes but prevents it from being used as a commercial service.
When a developer builds off open source code that has a possible licensing conflict it calls for risk investigation. The team must then decide if they can mitigate the liability to the application code or if it needs to be altered to remove this section. However, the result is increased time before release. For this reason, organizations’ legal teams often have pre-set guidelines for open source licensing.
What about open source software without a license, is that free?
In short, no. By default, the software is protected under exclusive copyright, and without a license, is illegal to use, even if it is being called open source. It is the license that provides the permission to use, copy, distribute, or modify the software without infringement risk pending the terms are met.
Customized Open Source Licenses
Developers sometimes write their own licenses or alter terms from a standard license. Although often well intentioned, they can increase ambiguity. There are some pretty wild licenses out there, like the Beerware License, that basically says if you like the software, in return you should buy the author a beer, or drink in their honour. Another is the Chicken Dance License that creates the alternative to the standard GPL requirement of sharing your code by sharing a video of you performing the chicken dance instead.
Another example of one that alters a standard license, is the JSON License for JavaScript Object Notation which is a popular component for data interchange. It modifies the standard permissive MIT license with one added term “The Software shall be used for Good, not Evil.” Definitely well intentioned, but many companies choose not to approve this license as the words “good” and “evil” are considered open to interpretation.
Every company must decide for themselves what their risk tolerance is, and as such what licenses they will allow. But often the vaguer a term, the more concern there is from the legal perspective. As such these customized licenses are often frowned upon, or blatantly banned from use in company open source policies.
Shouldn’t Developers know the laws of the code they are using?
Developers are not hired for their legal expertise. Their purpose is to be innovative, build well, and build fast.
It is important to remember that the misconception that open source code is “free” has been long lived, dating as far back as 1985, making it hard to overcome. Originally, it was called “Free Software” coming from the free software movement that pushed for the freedom to understand and modify software.
So, it is understandable that developers may carry this misconception. They just want to build, and this is what they know, not the legal requirements surrounding it. Furthermore, businesses may not have the training on site or knowledge that open source code is being used as many companies ramp up their in-house application development.
The licenses are often not straight forward either. Take the JSON example – a developer might think it is fine since they are just building commercial software, not malware or anything “used for evil,” and it is quickly dismissed. However, a lawyer would be able to identify the risk from the ambiguity of the term, and properly associate the risk profile of the license. To help mitigate licensing risk, many organizations do have their developers undergo open source law training.
The paradox of open source licenses in dependencies
With the speed at which developers are building these days, using a myriad of code resources, it seems virtually impossible to keep up with managing the risks and liabilities. Not to mention the low visibility that security teams have into the development pipeline. An increased difficulty that accompanies the use of open source libraries is the lack of visibility into the indirect dependencies. What happens when a developer uses an open source component, that is built with multiple indirect dependencies from other open source codes? It can seem like a bit of an infinity paradox effect, right? Since not only are you liable for the license terms of the direct dependency, but also any indirect dependencies that is open source code used to in the building of the larger open source component.
Open Source Licensing Impacts the Integrity of Your Software Supply Chain
Supply chain attacks are top of mind for many IT teams, and an important piece of the puzzle is ensuring its integrity. Compliance is a key part of this, and as a result, organizations like the Linux Foundation sought a solution. The OpenChain Project was created as an effective certification for open source license compliance in the software supply chain. What it essentially does is strengthen the whole chain and ensure each section can be trusted and meets the standard of compliance set to earn the certification. The most recent OpenChain Specification is the ISO/IEC 5230:2020 which “specifies the key requirements of a quality open source license compliance program in order to provide a benchmark that builds trust between organizations exchanging software solutions comprised of open source software.”
So how can you keep up and mitigate the legal risks?
There are programs that have databases of licenses with pre-populated risk profiles. Legal teams can set up automation, so any open source code with licensing conflicts are flagged. These programs are powered by a database of open source libraries containing thousands of licenses and license families. These programs also help keep track of the licenses your organization is using and can then create a report with all of these licenses to include with application distribution. Training developers on the laws of open source software is also an important mitigation as this can help decrease the conflicts that arise.
Trend Micro Cloud One – Open Source Security is powered by the Snyk database of thousands of open source libraries and their associated licenses. This solution bridges the two common risks of open source – vulnerabilities and licenses – so you can control and mitigate all your open source risk from one console. This brings essential value to security and operations teams in order to manage risk and liabilities for open source software use by further increasing the visibility into the functional codebase of the developer pipeline. Cloud One – Open Source Security helps security and legal teams identify risks earlier in the software development lifecycle, saving time and expenses in costly fixes that may be discovered later once the application is published and available to customers.
Cloud One – Open Source Security is the first solution of its kind to extend visibility from the right.