Open Source Licenses

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.

Dual

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.

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.

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.