Synopsys Enters into Definitive Agreement for Sale of Application Security (Software Integrity Group) Learn More

close search bar

Sorry, not available in this language yet

close language selection


Any company that creates software almost certainly includes code created by others. This code can be libraries, code snippets, functions, frameworks, and sometimes even an entire application. Use of this software code comes with both rights of use and obligations. The specifics detailing the rights of use and obligations are called a license.

Most of these third-party components are open source, meaning they are free of cost. But it’s important to not assume that “free” code and software is free from license restrictions; it is simply controlled by a different sort of license than commercial or proprietary code.

What are the types of open source licenses?

Allowed Required Forbidden
Commercial use Distribute Modify Patent use Private use Disclose source License & copyright notice Same license State changes Liability Warranty Trademark use
Mozilla Public License 2.0
Apache License 2.0
MIT License
Boost Software License 1.0
The Unlicense

Public domain license

Usually, software is protected by copyright, meaning that use of the software requires permission from the individual who created the software, or the person who holds the copyright. This does not apply to work in the public domain, however; software under this license category can be used or modified by anyone, without restriction.

It’s important to note though that even if a component is free and has no associated legal requirements, you should still ensure that it is secure before incorporating it into your own codebase.

Permissive license

Permissive licenses have very few requirements regarding how the software can be used and distributed. This is the most common type of license used with open source software. Examples include the MIT license.

Copyleft license

Copyleft licenses, also known as restrictive or reciprocal licenses, allow for modification and distribution of the open source code, so long as you meet the requirements for redistribution of whatever you create with the code. Examples include the GNU Affero General Public License.

There are various scopes to copyleft licenses. Some allow you to release just the code you modified, while others require that you release the entire application under the same license as the open source code you used to create it.  

Weak copyleft

A weak copyleft license is designed to allow linking to open source libraries with little obligation. If software dynamically links to a GNU Lesser General Public License (LGPL)–licensed library, the entire work can be distributed under any license, even a proprietary license, with minimal requirements. Static linking and modifying the library is more complicated. And using the LGPL-licensed component in other ways comes with copyleft obligations. Other weak copyleft licenses (including the MPL, CDDL, and Eclipse) occupy a place between permissive and copyleft.


The copyright holder of open source code can also make their software available under different licenses depending on the type of user. With dual licensing, a copyright holder could, for example, use a combination of a restrictive open source license plus a commercial license, thereby making it easy for developers to get their hands on the code and try it out, but obligate them to adhere to the commercial license in the event of actually using the code in their own products (perhaps having to pay for the commercial license to use it).

Unlicensed code

It’s important to understand that unlicensed code does not mean that the code is automatically public domain. Even when code is released without a specific license, there may still be obligations you must meet in order to use it.

By default, unlicensed code comes with copyrights. To use it, you must have explicit permission. You should treat unlicensed code like proprietary code—that is, pretend it’s not open source.

Is it risky to use open source software?

In short, no. But failing to manage it by securing it and adhering to its associated licenses can certainly be.

Less restrictive (permissive) open source licenses typically allow you to freely use an open source component so long as you maintain associated copyright notices. With limited restrictions, it’s easy to use code in a compliant way, and not very risky to the business.

With more restrictive licenses, failing to adhere to included obligations is riskier; for example, failure to recognize the impact of a reciprocal license could result in you being obligated to release the proprietary software you created under the same open source license. Meaning your organization could have to legally provide the entirety of the software you created as royalty-free open source software to anyone who wanted it.

From a legal standpoint, if a company uses code that doesn’t have a license, or without adhering to the code’s license obligations, the organization is at risk of a lawsuit. Lawsuits could result in the company being prevented from distributing products that contain the open source component, being liable for damages, or having to publish their own open source code.  

To protect code and the organization as a whole, it's critical to understand all software licenses that govern the use of any code included in an organization's software. So long as your organization manages its use of open source (you know what's in your codebase and what kind of licenses are attached to it), you can mitigate licensing risks for your organization.

How can I manage my open source license risk?

Managing open source risk requires that an organization know what is in its codebase. Software composition analysis (SCA) is an automated tool that scans your codebase for open source components and code snippets and returns a list of licenses associated with them, as well as known vulnerabilities and other crucial information. If you're acquiring software through an M&A transaction, conducting an open source software audit as part of tech due diligence can help you discover risks associated with open source that your target doesn't know about.

How can Synopsys help to manage open source license risk?

Before you can determine which licenses govern any components in a codebase, you need a Software Bill of Materials (SBOM)—a list of all the components in your code. An established security program including policy, process, training, and SCA tools will ensure that a company can maintain an accurate SBOM over time. A good SCA tool, like Black Duck® SCA from Synopsys, will find full components as well as code snippets, identify which licenses apply to each piece of code, and determine whether you might be using licenses that have conflicts. It will also identify known security vulnerabilities in the components. Creating an SBOM—and working with an SCA tool or auditor—can help make most licensing straightforward to understand.

Related content


See how Black Duck works

Watch the video