Five types of software licenses you need to understand

Different types of software licenses require you to meet certain obligations if you want to reuse the code. Here are five common types of software licenses.

If a company creates software, it also reuses code, including code snippets, libraries, functions, frameworks, and entire applications. In fact, in most applications the majority of the code comprises reused third-party components. And all software code comes with certain rights and obligations if used by others or incorporated in a company’s codebase. Even code snippets copied from Stack Overflow have obligations for reuse. Most of those third-party components are open source. Open source software is free of cost but not free of obligations; it’s just controlled by a different sort of license.

Software is licensed in different ways, and the downside of license noncompliance can be significant. If a company reuses a component without a license or without following a license’s obligations, the copyright holder might sue. In some circumstances, a company could face an injunction against further distribution of products containing misused components, damages, or the possibility of having to publish its own source code. Most companies simply want to be “clean” in their use of third-party software. To protect code and the organization, you need to understand the software licenses that governs the use of any code, including libraries and frameworks you didn’t write yourself. Here is a list of the top open source licenses and their potential legal risks.

The different types of software licenses

Here are five common types of licensing models for components that may be reused in a codebase, along with the rare and much-misunderstood public domain category of software, and the not-so-rare unlicensed category.

Permissive. Permissive licenses contain minimal restrictions on how the software can be modified or redistributed. They are also known as “attribution style” licenses as they typically only require that the copyright information be retained in a notices file when the software is distributed. This category of software license is the most popular open source license type. The best-known examples of this category are the Apache License, the BSD License, and the most-common MIT License.

Weak copyleft. The GNU Lesser General Public License is known as a “weak copyleft” style license. It is designed to allow linking to open source libraries with little obligation. If software dynamically links an LGPL-licensed library, the entire work can be distributed under any license, even a proprietary license, with minimal requirements. Static linking and/or modifying the library gets 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.

Copyleft. Copyleft licenses are also known as reciprocal licenses or restrictive licenses. In general, they are less commercial-friendly than other licenses. The most well-known and frequently used is the General Public License (GPL) family of licenses. These licenses allow developers to modify the licensed code, incorporate it with proprietary code, and distribute new works based on it, as long as they distribute source code to any new works or adaptations under the same software license. (The Affero General Public License [AGPL] is similar but closes the “SaaS loophole” in that it is triggered in hosted deployments, not just upon distribution.) The catch here is that these licenses require distribution of source code along with the new, derivative work. Therefore, the license for a proprietary work that includes GPL-licensed code requires distribution of proprietary source code. But of course, exposing source code to users or competitors is generally not in a company’s best (commercial) interests. So companies creating commercial applications tend to shy away from using software with these types of licenses.

Commercial or proprietary. Of all types of software licenses, these tend to be the most restrictive. Such licenses are generally used for commercial software where the copyright holder is asserting express conditions with respect to the rights being granted, and for instance, doesn’t want the code to be shared, reverse-engineered, modified, redistributed, or sold.

Dual. A copyright holder may choose to offer their software under different licenses to different users. An increasingly common business model is dual-licensing—using both a copyleft or other form of open but restrictive license, and a commercial license. The strategy is to use the open source license to make it easy for developers to get their hands on the code and try it out, but the obligations are such that if the company really wants to make money with the software, it needs to pay for a commercial license. The AGPL license is often used for this purpose, and some new variants have arisen that are even more commercially restrictive, such as the Server Side Public License.

Public domain. Some software is in the public domain. In general, software works are protected by copyright, meaning that using the software in any way requires the permission of the creator or copyright holder, i.e., a license. However, copyright does not apply to works in the public domain—anyone can modify and use such software without any restrictions. But you should know that public domain code is rare and that the definition varies between jurisdictions.

Unlicensed. Code that doesn’t have an explicit license is not de facto in the public domain; the default is that you need a license to use software. So if a company cannot associate software it is using with a license, it is likely violating copyright law.

How to tell what licenses apply to a particular software codebase

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 the code. An established program including policy, process, training, and software composition analysis (SCA) tools will ensure that a company can maintain an accurate SBOM over time. A good SCA tool will be able to find full components as well as code snippets, and it’ll tell you which licenses apply to each piece of code and whether you might be using licenses that have conflicts (in addition to identifying known security vulnerabilities in the components). Absent all that, or, say, in an M&A transaction, a trusted, competent third-party audit can provide an accurate snapshot in time.

Once the SBOM is established, and especially with the aid of and SCA tool or auditor, most licensing will be straightforward to understand. But as this article highlights, that is not always the case. Best practice is to have an open source–savvy IP attorney on tap to advise on the more complex questions that inevitably arise.

This post was originally published Oct. 7, 2016, and refreshed July 27, 2022.