Following our recent blog post on what are open source licenses, their types, and their limitations, in this post, we will dive into the risks for being a non-compliant business, and how an organization may remediate such risks.
The problem
Many developers falsely believe that OSS (open source software) is freely available without any restrictions attached to it when using it in their development process. That is completely wrong. Each OSS’s license states the terms & conditions that have to be filled in order to use it for commercial uses. Not following and applying these conditions may introduce a certain risk to the organization which can lead to unwelcomed, critical consequences.
The risks
#1 Being forced to share modifications to the public:
In case you are using an OSS that uses a “copyleft” type of license, such as GPL, LGPL, AGPL, EPL, or MPL in your code, your software development might be governed by the respective OSS license and therefore, the ownership of your software will not be exclusive.
Your software must comply with the same requirements that are applicable to the OSS you used, for example, a GPL license. In the case of you releasing a modified version to the public in some way, this requires you to make the modified source code publicly available for anyone, since part of its conditions are to disclose the source code and make sure modifications are released under the same license. Not doing so means you have violated the GPL license conditions.
#2 Being exposed for a lawsuit:
Legally, companies using OSS in their applications must comply with licenses for each component to maintain the rights to modify and distribute their technology. Any violation attached to the license may lead to a potential lawsuit against the company and/or the client using the uncompiled software.
One of few examples is the ongoing lawsuit that Elastic has filed against Amazon, in order to prevent Amazon from using its service to distribute Elastic-built software from Amazon Web Services. In the case of a non-compliance company, you might also face penalties and restrictions on selling your company’s software product until compliance is met. In most cases, responding to a claim ends up costing more than if your company complied in the first place.
#3 Businesses risks:
In case there is a failure to comply with licenses, a company may be exposed to business disruption, due to the fact that some licenses may automatically terminate because of the company non-compliance status. An injunction may prevent distributing a product until the source code is released. The later a problematic dependency is discovered the more costly it will be to resolve in the software development process.
#4 IPO killer:
Lack of audit and plan to address open source license issues will not only slow down a potential IPO preparation process, but also may depress an IPO value, both in the short term and at any point of a public company life cycle.
#5 Prohibition of commercial distributing:
Some OSS licenses have policies that do not permit any commercial distribution of software that uses their licenses. Therefore, in the case when you are using OSS containing these licenses, you will not be able to sell or rent any deliverables that fall under these licenses. For example, Jason Hunter, Java Enterprise Edition, and Oracle licenses are part of these restrictive licenses.
But there is more, a non-compliance transitive consequence might be:
- Negative effect: Non-compliance companies may suffer from negative coverage & press
- Reputation: Damage or complete loss of reputation with customers and clients
- Credibility: Damage or complete loss of credibility with the open source community
- Resources: Consuming more resources (time + money) to remove a component/detect & fix the issue.
Research
Checkmarx has conducted research on the legal risk factors in open source packages. The goal was to scan a high number of open source dependencies, determine how many of them contain a legal risk, and what is the severity of such risk in order to prioritize these risks and their fixes.
To make this research authentic, we used well-maintained packages as well as poorly maintained packages (50:50) that were part of GitHub OS projects that were filtered by using the open-source tool scorecard project (by OSSF). We fetched interesting metrics using an automated SCA tool, and the results were the followings:
- ~5.3% of the open-source packages have a license that contains “legal risk”. According to GitHub State of the Octoverse Report, “Open-source projects have an average of 203 package dependencies” – which means that on average, each project a developer uses contains 10 packages that use licenses with legal risk.
- The vast majority of these legal risks are considered high risk/medium risks, which means they have to be addressed in order to make your product safe and compliant.
So, what should you do?
Every organization has to make sure they are properly managing their open source licenses risks. Managing your open source dependencies (and their transitive dependencies) and their risk can be a very tedious, overwhelming challenge due to:
- The high amount of open source dependencies (and their transitive dependencies) your organization use on the code
- Challenge of collecting each license you are using
- Categorizing these licenses into risks
- Prioritizes these license’s risks
- Fixing the compliance issues
To help manage open source license risk, Checkmarx SCA enables your organization to address license issues earlier in the SDLC, and cuts down on manual processes by scanning your code, identifying the license type, and the risks it contains, so you can deliver secure and compliant software faster and at scale. Below is an example of the information Checkmarx SCA provides.
For a free demonstration of Checkmarx SCA, please contact us here.