Guide to open source licenses

Do you know what's in your software? If you wrote every line of code yourself, including any libraries and frameworks, the answer is yes. But if you're like most people, you wrote only a portion of your entire codebase. Industry practices vary, but studies show that up to 90% of the source code may be third-party code. Do you know what's in the part you didn't write?

Here the answer becomes murky. What if your codebase contains a code library from an open source repository? While it's free, using it may not be without legal peril.

Some forms of free and open source software (FOSS) allow you to use, modify, and distribute the code in your work without direct attribute. That's what most developers think when they use FOSS.

But other open source licenses don't give you that freedom. These more restrictive open source licenses might oblige you to make your proprietary project public and subject to the same licensing terms of the original FOSS.

Why use open source?

Let's say you're starting a company and the business model requires you to develop an app. Rather than reinvent the wheel by writing your own SSL, you might consider using OpenSSL. The current licensing on OpenSSL is Apache-style. That means it's a permissive free software license. However, OpenSSL is also dual licensed, so read the download library files carefully.

It's OK to use open source code, but you need to analyze it. You should know what license the component has, whether the library files are current, and whether there are any outstanding CVEs for the latest version. A good software composition analysis tool can give you this information.

What are the different types of open source licenses?

Here are three common open source license models you should know about.

Public domain. This is the most permissive model. It means that anyone can modify and use the software without any restrictions. But even if a component is free and comes without any legal strings attached, you should always make sure it's secure before adding it to your own codebase.

Permissive. Permissive licenses contain minimal requirements about how the software can be modified or redistributed. Also known as "Apache style" or "BSD style," this type of license is perhaps the most common and popular with free open source software. Besides the Apache License and the BSD License, another common variant is the MIT License.

Copyleft. Copyleft licenses, also known as reciprocal licenses or restrictive licenses, allow you to modify the code and distribute new works based on it, as long as you meet the requirements for redistribution under the same license. Different licenses have different scopes. Some copyleft licenses allow you to release the modified code only; others require you to release the entire application under the same license. One of the most common restrictive licenses is the GNU GPL (General Public License). Its cousin, the AGPL (Affero General Public License), is also becoming more popular, as it closes the SaaS loophole found in the GPL.

A note about unlicensed code: "Unlicensed" does not mean "public domain." Even if code was released to the public and doesn't come with a specific license (such as a code example from Stack Overflow), you might still have to meet certain obligations to use that code. By default, the copyright for unlicensed code belongs to its creator, who must grant explicit permission for you to use it. The safest way to approach unlicensed code is to treat it as proprietary (i.e., not open source).

Is it risky to use open source software?

Permissive open source licenses generally allow you to use an open source component freely as long as you maintain any copyright notices. But if you use a component with a restrictive license in your proprietary software, you might be legally obligated to release your software under the same license (i.e., as royalty-free open source software). As long as you are managing your use of open source (i.e., you know what's in your codebase and what kind of licenses are attached), you can manage your legal risk. But be aware that very few organizations track their open source use well, if at all. The others are all exposing themselves to legal risk.

What kind of open source license risks are there?

There are many ways to categorize open source license risks. Our software audits group classifies risks based on priority. For example, some licenses in your codebase might be OK to use as is, but others might be in conflict with other licenses, so you'd need to research them before proceeding. We further classify risks based on type of license (e.g., permissive or restrictive), which reflects your legal exposure if you use components that have those licenses.

Our guide to the top open source licenses lists some of the most popular open source licenses according to these risk categories:

Low risk. Permissive licenses are consider low risk because it's easy to meet their reuse requirements: Usually you just have to retain the copyright notice, but you don't have to expose your source code. Examples are the Apache and MIT Licenses.

Medium risk. Semi-permissive licenses, sometimes referred to as limited licenses, weak copyleft licenses, or simple copyleft licenses, are considered medium risk because if you modify the code, you have to release the modifications, but not your whole application, under the same license. Different licenses define "modification" differently. Examples are the Mozilla and the Eclipse Public Licenses.

High risk. Restrictive licenses carry a great deal of legal risk. If you use a component with one of these licenses, you might be legally obligated to release your entire application code. Examples are the GNU GPL and GNU LGPL.