Understand open source license types and their organizational obligations

Overview

Open source licenses are not uniform. They range from licenses that impose minimal obligations — essentially permitting any use with only an attribution requirement — to licenses that impose substantial obligations that can affect the organization’s ability to protect proprietary code, to distribute software commercially, or to integrate open source components into products sold under proprietary terms. Understanding the license types the organization is using and the obligations each imposes is the foundational governance requirement from which all other open source license compliance disciplines follow.

Best Practice

Classify every open source component in the Open Source Components Inventory by its license type, using the SPDX License List as the authoritative reference for license identification and classification. (Source: The Linux Foundation, SPDX License List, spdx.org/licenses.) The SPDX License List provides standardized identifiers for hundreds of open source licenses and is the most widely adopted reference for license identification in enterprise open source governance programs. The primary license categories the organization’s classification should distinguish are as follows.

Permissive licenses, including MIT, Apache 2.0, BSD-2-Clause, and BSD-3-Clause, impose minimal obligations. They typically require attribution — preservation of copyright notices and license text — and may require acknowledgment in documentation or marketing materials for certain uses. They do not require the organization to release its own code. Permissive-licensed components can generally be integrated into proprietary products with minimal governance complexity.

Weak copyleft licenses, including the GNU Lesser General Public License (LGPL), Mozilla Public License (MPL), and Eclipse Public License (EPL), impose more significant obligations than permissive licenses but stop short of requiring the full release of any software that uses them. They typically require that modifications to the licensed component itself be released under the same license, while allowing the component to be used as a library by proprietary software. The specific scope of the copyleft obligation varies by license and requires careful assessment for each specific use case.

Strong copyleft licenses, including the GNU General Public License (GPL) and the GNU Affero General Public License (AGPL), impose the most significant obligations. They require that any software that is distributed or — in the AGPL’s case, used to provide services over a network — and that includes or links to a GPL or AGPL-licensed component be released under the same license. AGPL is particularly significant for cloud-hosted services because its copyleft obligation extends to network use rather than only to binary distribution. Strong copyleft components require careful legal assessment before integration into products or services that the organization distributes or provides commercially.

Commercial open source licenses are hybrid licenses offered by vendors who develop both an open source version and a commercial version of the same software. The open source version is typically available under a strong copyleft license, while the commercial version is available under a proprietary license for organizations that cannot comply with or prefer not to comply with the copyleft obligations. Understanding which version the organization is using and what obligations apply requires careful license review.

Figure: Open Source License Obligation Matrix — Different open source license types carry different organizational obligations and risks.

Benefit(s)

A consistent, taxonomy-based license classification of all open source components in the Open Source Components Inventory gives the organization a clear picture of its license obligation profile across the full portfolio. Permissive-licensed components can be used with minimal governance overhead. Copyleft-licensed components are identified and their specific obligations assessed before integration decisions are made rather than after. The organization can respond confidently to license compliance inquiries from customers, partners, and regulators because the license classification data is maintained and current.