New FDA cybersecurity guidelines are out. Join the webinar to learn more.
New FDA cybersecurity guidelines are out. Join the webinar to learn more.

Licensing Open Source Software: the Double-Edged Sword

Licensing Open Source Software: the Double-Edged Sword

Open-source software libraries are the backbone of modern software development and a critical piece of the software supply chain. Engineers don’t need to recreate existing functionality; instead, development efforts can be accelerated using open-source software (OSS) libraries. These days, almost 98% of applications use open-source libraries.

Using open-source libraries does bring unique risks. Beyond security risks related to  vulnerabilities from unpatched and unmaintained code, using OSS carries specific risks from the variety of licenses associated with each piece of open-source software used. Left unmanaged, these could lead to significant legal risks that carry over into any software developed with them.

This blog post explores the special risks of OSS licensing and how to safely and effectively manage those risks for your development process to reap the myriad of OSS benefits.

Open Source Libraries: The Backbone of OSS

Even though OSS can be used free of charge, a wide range of stipulations might apply when incorporating OSS libraries into a product. Each piece of software comes with specific licensing requirements that vary based on the type of license and the use cases for the final product.

Understanding these requirements and their potential impact is crucial to making informed decisions about appropriate OSS usage in your products.

License Type Matters: Knowing the Risks

When working with OSS, there is a significant risk related to licensing – the risk of copyright infringement. There are numerous license types, and each one dictates how your company can utilize the software. Some licenses can include language explicitly preventing commercial use that can lead to legitimate copyright infringement claims.

The risk is that some licensing models can compromise your intellectual property’s proprietary nature. The copyleft model in software licensing allows the OSS to be freely used as long as derivative works also open their entire codebases and rely on the same license to be freely copied and used.

Using OSS with this type of license can compromise development efforts by transforming previously proprietary and private codebases into publicly available software.

Fortunately, not all OSS software is risky. There are permissive licenses that grant broad rights with very few if any restrictions. Permissive licensing embraces the original open-source ideals of being free to share and open for investigation and improvement. These licenses are optimal for businesses as they are as close to free and have no strings attached.

Examples of Common Licenses
License Key Risks/Benefits
GNU GPL Copyleft license that requires disclosing the source code of derivative works.
LGPL A “weak copyleft” license that allows developers to use and integrate a software component released under LGPL into their own (even proprietary) software without releasing the source code of their own components. However, any modification to an LGPL component must be released under the same LGPL license.
Apache A permissive free software license allowing utilization of the software for any purpose, including distribution and modification without concern for royalties.
MIT MIT licensing is free for utilization but requires including a copy of the MIT licensing file as well as the copyright notice.


These licensing challenges stem not only from OSS that is directly incorporated into your product codebase but also in software and hardware components incorporated into your product.

Incorporating software components that contain undisclosed copyleft licensing agreements can lead to a chain reaction of disclosures. Not only is the element being used subject to the license, but so is your software. This can create a licensing nightmare if left undiscovered before final production.

Your Next Challenge: Tracking Licenses

In a modern development environment, tracking the different licenses in use across all products is a major challenge. Attempting to do so manually is a futile effort – it will not solve the problem, but only waste time by expending significant work conducting tedious inventory and analysis. This “point-in-time” view will rapidly become out of date as new product development occurs and additional libraries are added to the mix, requiring additional rounds of review and assessment.

To keep up with the fast-paced development needs, automation is the only efficient solution. Automated software solutions can assess what libraries are utilized by your organization as well as sub-dependencies in OSS that are being used. This information can quickly be assessed, reported and used to create and enforce licenseing policies.

With automated solutions, you can consistently keep up and improve your licensing posture without wasting valuable resources.

Multiple Licenses = Multiple headaches

Developers are encouraged to use open source components, however, OSS packages may come with different licensing terms. Combining different licenses can pose a compatibility problem as the conditions, permissions, and requirements of different licenses can conflict.

Combining open source components is not a problem as long as the terms and conditions in the licenses are compatible, but how can you know if they are? Unfortunately, this is a tricky question, since the answer depends on the type of licenses and their hierarchy in your application.

This is where your licensing policy comes into place – your legal team will be able to create one for you, taking into account the possiblity of incompatible licenses, and how to handle such situations.

No License = No Rights

Another easy-to-make mistake with open source software is assuming that software that does not explicitly state a license falls under the umbrella of open source.

While this may be true in some instances and appear to be an optimal scenario, the fact is that the license is what makes it open source. The license explicitly grants rights and specifies its use, allowing legal utilization without copyright infringement.

The lack of a license is not an open-ended permission to use a piece of software, but instead makes appropriate use of the library unclear and can create a significant legal risk.

Like licensing compatibility challenges, the lack of licensing in components can trickle up into your product, leaving you in an unclear position regarding appropriate use. In these scenarios, the only suitable choice is not to use the library in any capacity if it is not clearly licensed.

Digging Into Open Source Licensing

Using open-source is a worthwhile undertaking if done safely. Open-source components can save organizations money and speed up development by not wasting resources re-creating functionality someone else has already developed.

Reviewing the different licenses for all software in your organization can be daunting. Manual efforts are tedious and do not scale to meet the speed and size of today’s development projects. Manual tracking of open-source licenses can potentially overlook libraries in use or dependincies, that could have far-reaching legal consequences.

Implementing the right automated tools to integrate license evaluation and  into the build process will help alleviate this burden and keep your organization safe.

Getting Licensing Right

A successful OSS licensing validation process begins with identifying which licenses are appropriate for your organization. This involves assessing the many popular OSS licensing types to identify which are appropriate for your business and which should not be used. While many software licenses are not suitable for use in commercial products, plenty are very friendly toward that purpose.

By creating licensing policies that specify clearly which licenses are acceptable and which are not, which licenses could be used together, and which licnese combinations are problematic, you will streamline the assessment process and set firm boundaries to protect your organization.

Yet, a policy without enforcement isn’t very useful.

This is where automated solutions can help, scanning your software and alerting R&D and legal team of non-conforming licenses found in OSS, thus effectively enforcing your licensing policy.


One of the biggest challenges in developing a product is gaining visibility into what OSS is incorporated in it. Not every component utilized in a product will be transparent to developers. In these instances, your organization will have to work backward and discern what libraries might be in use and what their licensing is using binary code analysis.

While some vendors might openly disclose their incorporated OSS, there is always the potential for inaccuracies in the disclosure. Simply missing some software packages can lead to licensing problems (and security issues as well…). The inverse of this is also relevant as false positives or packages listed that are not part of the project can waste valuable time evaluating and resolving potential issues that are nonexistent.

This is where binary software composition analysis (SCA) tools are crucial for creating visibility. Without needing access to the actual source code, they investigate the binaryto determine the underlying software components and libraries. When done manually, this process is time-consuming. SCA tools efficiently remove the guesswork as to what libraries might be included, allowing informed decisions regarding utilization.

SBOMs & Licensing Compliance

Device manufacturers can provide visibility and help their customers understand both the security and licensing risks in their products by providing a software bill of materials (SBOM). An SBOM streamlines the process of detecting licensing of OSS. A list of software packages used in the product is supplied, along with version and license information. Sometimes though, an SBOM is not provided and SCA tools can bridge this gap by generating SBOMs with licensing information.

SBOMs come in various standards, such as SPDX or CycloneDX, but all contain a minimum set of elements that they must include to comply with the latest regulations and standards. In most cases, these elements include seven primary fields that explain who the supplier is and the definitive versions and dependencies for all OSS in a product. Knowing this information makes it easier to work with components and make informed decisions about them.

Next Level Open Source Software License Management

Cybellum is a leader in helping organizations take control of their OSS licensing. Integrating SBOMs and vulnerability monitoring support, Cybellum gives your company visibility and control of your software security and license compliance risks from design to post-production.

Cybellum’s proprietary Cyber Digital Twins™ technology creates a blueprint of your software, eliminating the black box of binaries. It generates detailed SBOMs that exceed the minimum NTIA requirements to pinpoint vulnerabilities and licensing challenges for remediation.

Our experts can show you how. Talk to us or schedule a demo.