Well, if you don’t, then you end up in a situation similar to Hancom Office, a South Korean software company which has been battling a copyright infringement lawsuit.
Today, it is rare for organizations to develop 100% original software code. They regularly use open source frameworks and 3rd party components to dramatically speed up the development process and reduce time to market. When businesses use open source software or OSS to develop their code, they agree to certain licensing conditions and terms of the OSS. These licensing conditions detail how the code can be used and distributed, determine whether or not the software supplier needs to grant a patent license to users and developers, dictate whether or not the business has to offer the source code free to public, or simply state that the code is free to use.
Some of the issues that could arise if businesses are not careful about open source licensing include:
Having to make commercially developed software free and open source
Being sued or having to settle a legal dispute
Incurring significant cost to remediate a piece of software to remove a component with risky license requirements
Did you know that an average application uses over 200 open source components? Most organizations are surprised when they realize that they are using 20 times more OSS in their software development than they estimated. And, most businesses do not even realize that they are out of compliance!
Not all open-source licenses are the same, and with the pressure to roll out and ship the product, developers often don’t take the time to learn the details. There are some risky license types to look out for, especially for those who develop code that contains many open source components.
SPDX lists over 350 commonly found licenses and exceptions that are used in open-source software. However, the most common license types you should become familiar with include:
For most development teams, it is far too impractical to comb their code and find all instances of open-source usage. Many hands will touch code and if they don’t document where they got the open-source code, how it was used, what kind of licensing agreement it was, and whether or not the code is up to date, teams may be stuck for direction. With so many license types, there is a definite need to have a formal identification, documentation and compliance mechanism in place.
Let’s consider the example of GNU GPL, a widely used open source software. GPL is “copyleft” licensed. Copyleft in OSS licensing mandates that the developer has to maintain terms similar to the license agreement, preserve the license itself on the newly created product, or even publish the code and thus enrich the community of any modification on the component. If a software company is using a component within its products that has a copyleft license, it may require that the entire product becomes free and open source. If not, the business will face a licensing violation which can cost millions of dollars and negate the work done by the company on said product.
GNU General Public Licenses (GPL) commonly include "copyleft" language. When using CAST Highlight’s Software Composition Analysis (SCA) dashboard, this type of license gets flagged “red” so that developers can choose another option, such as a BSD or other common licenses, which do not currently include copyleft requirements. These license policies can be customized by the organization within the solution, if so desired.
Development teams need to be judicious in choosing open source components to use. The cost of having to remediate a piece of software to remove a component with risky license requirements is extremely high. The hours worked by the development team and the time put into testing may have all been wasted as teams have to start over. Overall costs can also skyrocket as more companies are being sued over the use of open-source code. The worst-case scenario is that the commercially developed product will have to be released for free and made open-source code.
Companies of all sizes and scopes face OSS licensing risks - Tesla and Samsung are but two of the many high-profile companies that have fallen victim to the legal risks caused by IP licensing requirements.
The first step to managing OSS licensing risks is to use an SCA solution to automate the process of identifying the software components and potential IP licensing risks. The ideal solution should include the following core capabilities:
Customizable license policies based on the organization’s unique needs
Portfolio level analysis enabling rapid insights across the entire enterprise’s application stack
Business context metrics to help prioritize the most important applications to focus on first; and
Additional SCA data such as security vulnerabilities and obsolete components.