Well, if you don’t, you end up in a situation similar to Vizio, a major television manufacturer that 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 third-party components to dramatically speed up the development process and reduce time to market. When businesses use open-source software (OSS) to develop 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 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!
Learn more about common OSS licenses here.
OSS IP licensing requirements - what you should know
Not all open-source licenses are the same. 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 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 the code is up to date, teams may be stuck for direction. With so many license types, there is a definite need to have formal identification, documentation and compliance mechanisms in place.
Beware of “copyleft” in OSS licensing
Let’s consider the example of GNU GPL, a widely used open-source software license. GPL is “copyleft” licensed. Copyleft in OSS licensing mandates that the developer must 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 that 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 as red so that developers can choose another option (like a BSD or other common license) that doesn’t currently include copyleft requirements. These license policies can be customized by the organization within the product, if so desired.
OSS licensing risks and costs
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 intellectual property licensing requirements.
How can businesses reduce OSS licensing risks?
The first step to managing OSS licensing risks is to use an SCA product 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.
SHARE