{"id":75132,"date":"2022-04-13T07:23:49","date_gmt":"2022-04-13T11:23:49","guid":{"rendered":"https:\/\/checkmarx.com\/?p=75132"},"modified":"2024-07-28T06:32:04","modified_gmt":"2024-07-28T06:32:04","slug":"open-source-licenses-understanding-the-risk-factors","status":"publish","type":"post","link":"https:\/\/checkmarx.com\/blog\/open-source-licenses-understanding-the-risk-factors\/","title":{"rendered":"Open Source Licenses – Understanding the Risk Factors"},"content":{"rendered":"
Following our recent blog post<\/a> 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.<\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n In case you are using an OSS that uses a \u201ccopyleft\u201d 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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. 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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<\/a> (by OSSF). We fetched interesting metrics using an automated SCA tool, and the results were the followings:<\/p>\n\n\n\n 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:<\/p>\n\n\n\nThe problem<\/strong><\/h2>\n\n\n\n
The risks<\/strong><\/h2>\n\n\n\n
#1 Being forced to share modifications to the public:<\/h3>\n\n\n\n
#2 Being exposed for a lawsuit:<\/h3>\n\n\n\n
One of few examples is the ongoing lawsuit that Elastic has filed against Amazon<\/a>, 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\u2019s 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.<\/p>\n\n\n\n#3 Businesses risks:<\/h3>\n\n\n\n
#4 IPO killer:<\/h3>\n\n\n\n
#5 Prohibition of commercial distributing:<\/h3>\n\n\n\n
But there is more, a non-compliance transitive consequence might be:<\/h3>\n\n\n\n
\n
Research<\/strong><\/h2>\n\n\n\n
\n
So, what should you do?<\/strong><\/h2>\n\n\n\n
\n