Open-source software licensing is the distribution of software under licenses that grant every recipient the rights to use, study, modify and redistribute it, including in source code form. Two definitions anchor the field: the Open Source Definition maintained by the Open Source Initiative (OSI), which lists ten criteria a license’s distribution terms must meet,[1] and the free software definition of the Free Software Foundation (FSF), which describes free software as software that gives the user “the freedom to share, study and modify it”.[4] For software asset management (SAM), open source components carry no license fee but do carry conditions, and those conditions are mostly triggered by distributing the software rather than by installing or running it.
History
The free software movement began in 1983, when Richard M. Stallman launched the GNU project to build a replacement for the UNIX operating system; Stallman founded the Free Software Foundation in 1985.[4] The FSF’s GNU General Public License (GPL) was published as version 2 in June 1991[6] and as version 3 on 2007-06-29.[5]
OSI was founded in late February 1998 by Eric Raymond and Bruce Perens. The Open Source Definition was created at OSI’s launch by revising the Debian Free Software Guidelines, which Perens had drafted and the Debian developer community had approved in 1997, and removing Debian-specific references.[2]
The Software Package Data Exchange (SPDX) specification became the international standard ISO/IEC 5962 in August 2021.[16][17] The OpenChain specification for open source license compliance programs was first released as OpenChain 1.0 in October 2016 and became ISO/IEC 5230:2020 in December 2020.[18][19]
Scope and definitions
Open Source Definition
The Open Source Definition states that open source “doesn’t just mean access to the source code” and sets ten criteria for a license’s distribution terms: free redistribution without a royalty; inclusion of source code in “the preferred form in which a programmer would modify the program”; permission for modifications and derived works; integrity of the author’s source code (a license may require patch files or a changed name for modified versions); no discrimination against persons or groups; no discrimination against fields of endeavor; rights that pass to all recipients without an additional license; rights that are not specific to a product; no restrictions on other software distributed alongside; and technology neutrality.[1] A license must pass OSI’s license review process to be listed as OSI Approved.[3]
Free software
The FSF calls such software free “because the user is free”, and contrasts it with proprietary software whose license terms deny users the freedoms to share, study and modify.[4] The two definitions are maintained separately. The SPDX License List records both judgments: it marks Apache-2.0, MIT, BSD-3-Clause, MPL-2.0 and LGPL-3.0-only as both FSF Free/Libre and OSI Approved, while CC0-1.0 is marked FSF Free/Libre without an OSI Approved flag.[14]
Copyleft
Copyleft licenses use copyright to require that modified and derived versions remain under the same license. The GPLv3 preamble describes the GPL as “a free, copyleft license” intended to guarantee the freedom “to share and change all versions of a program”.[5] Licenses without this requirement are usually called permissive.
License families
| Family | Examples (SPDX identifier) | Scope of the reciprocal obligation |
|---|---|---|
| Permissive | MIT, BSD-3-Clause, Apache-2.0 | None; notices and license text must be kept |
| Weak copyleft | LGPL-2.1-only, LGPL-3.0-only, MPL-2.0 | The library (LGPL) or the covered files (MPL) |
| Strong copyleft | GPL-2.0-only, GPL-3.0-only | The whole work based on the program |
| Network copyleft | AGPL-3.0-only | As GPLv3, plus source for remote users of a modified version |
| Public-domain dedication | CC0-1.0 | None; rights waived to the extent the law allows |
Permissive licenses
The MIT License grants permission “to deal in the Software without restriction”, including to use, copy, modify, merge, publish, distribute, sublicense and sell copies, on the condition that the copyright notice and permission notice are included in all copies or substantial portions of the software.[10] The 3-Clause BSD License adds a clause prohibiting use of the copyright holder’s or contributors’ names to endorse or promote derived products without written permission.[11] The Apache License 2.0 (January 2004) requires redistributors to give recipients a copy of the license, mark modified files, retain copyright, patent, trademark and attribution notices, and carry forward the contents of any NOTICE file; it also contains an express patent license from each contributor.[12]
Weak copyleft
The GNU Lesser General Public License version 3 incorporates GPLv3 and adds permissions. It allows a “Combined Work” that uses the library to be conveyed under terms of the distributor’s choice, provided those terms do not restrict modification of the library portions or reverse engineering to debug them, and the distributor gives notice of the library’s use and supplies the GPL and LGPL texts, among further conditions.[7] The Mozilla Public License 2.0 applies copyleft at the level of files: source distributions of “Covered Software”, including modifications, must be under the MPL, but a “Larger Work” that combines covered software with other material in separate files may be distributed under terms of the distributor’s choice.[8]
Strong copyleft
Under GPLv3 a person who conveys a work based on the program “must license the entire work, as a whole, under this License to anyone who comes into possession of a copy”, regardless of how its parts are packaged.[5] Object code may be conveyed only together with the machine-readable Corresponding Source, provided in one of the ways the license lists.[5] GPLv2 has an equivalent requirement, which can be met with a written offer of source valid for at least three years.[6]
Network copyleft
The GNU Affero General Public License version 3 adds a condition in section 13: if a person modifies the program, the modified version must “prominently offer all users interacting with it remotely through a computer network” an opportunity to receive its Corresponding Source from a network server at no charge.[9]
Public-domain dedications
Some authors seek to place software as close to the public domain as the law allows. Creative Commons CC0 1.0 is a waiver of copyright and related rights, with a fallback public license for any jurisdiction where the waiver is ineffective. It states that no trademark or patent rights held by the affirmer are waived, abandoned, surrendered or licensed by the document.[13]
How it works
What triggers obligations
Most conditions in open source licenses attach to distribution. GPLv3 distinguishes “propagating” a work, which covers acts that would otherwise infringe copyright except executing it on a computer or modifying a private copy, from “conveying”, which is propagation that enables other parties to make or receive copies; the license adds that “mere interaction with a user through a computer network, with no transfer of a copy, is not conveying”.[5] Section 2 of GPLv3 allows a licensee to “make, run and propagate covered works that you do not convey, without conditions” while the license remains in force, and to have contractors modify or run the works exclusively on the licensee’s behalf.[5] Internal use of GPL software therefore creates no source obligation under the license text; distributing it to customers does.
Network use is the main exception. Because GPLv3 does not treat network interaction as conveying, software offered as a hosted service does not trigger its source obligations, whereas AGPLv3 section 13 does when the service runs a modified version that users interact with remotely.[5][9] For SaaS publishers the GPL and AGPL therefore differ materially.
Common obligations
- Notices. MIT and BSD require the copyright and permission notices to be reproduced;[10][11] Apache-2.0 requires retention of existing notices, change markings on modified files, and the NOTICE file’s attribution notices.[12]
- License text. Apache-2.0 requires a copy of the license to be given to recipients;[12] the MPL requires recipients to be told that the source is governed by the MPL and how to obtain a copy;[8] the LGPL requires the GPL and LGPL texts to accompany a Combined Work.[7]
- Source code or source offer. GPL-family licenses require Corresponding Source with object code distributions, or, under GPLv2, a written offer of source.[5][6]
- Patent grants and retaliation. Apache-2.0 grants a royalty-free patent license from each contributor, and terminates the patent licenses of anyone who starts patent litigation alleging that the work infringes.[12] GPLv3 grants each contributor’s essential patent claims and bars licensees from initiating patent litigation over making, using or selling the program;[5] MPL-2.0 terminates the rights of a licensee who asserts a patent infringement claim against a contributor version.[8]
License compatibility
Compatibility is whether code under two licenses can be combined and distributed as one work while complying with both. Copyleft licenses with different terms may conflict because each requires the whole work to be under itself; some licenses provide explicit bridges. GPLv3 section 13 permits a covered work to be combined with a work under AGPLv3, with each part remaining under its own license and the AGPL’s network condition applying to the combination.[5] MPL-2.0 names GPL-2.0, LGPL-2.1 and AGPL-3.0 and their later versions as “Secondary Licenses” and allows MPL-covered software in a Larger Work to be additionally distributed under them, unless the software is marked incompatible.[8]
Version selection affects compatibility. SPDX release 3.0 replaced the older GNU identifiers with explicit “-only” and “-or-later” forms because the choice between “this version only” and “any later version” changes which combinations are permitted.[14]
Trademarks are separate
Open source licenses grant copyright (and in some cases patent) permissions, not trademark rights. Apache-2.0 states that it does not grant permission to use the licensor’s trade names, trademarks, service marks or product names except for reasonable and customary use in describing the origin of the work;[12] MPL-2.0 grants no rights in contributors’ trademarks, service marks or logos;[8] and CC0 expressly leaves trademarks unaffected.[13] A project’s name and logo are governed by the owner’s separate trademark policy, which can restrict how modified builds are named.
Source-available and relicensed software
Some publishers distribute source code under licenses that do not meet the Open Source Definition. These are commonly called source-available licenses, and they typically restrict one of the rights the OSD protects, such as use in any field of endeavor. The SPDX License List assigns identifiers to several, including SSPL-1.0 (Server Side Public License), Elastic-2.0 (Elastic License 2.0) and BUSL-1.1 (Business Source License 1.1), none of which it flags as FSF Free/Libre or OSI Approved.[14]
Relicensing from an open source license to a source-available license has been a recurring pattern among publishers that sell proprietary features or managed services alongside a community edition, often described as open core. In January 2021 OSI stated that the SSPL is not an open source license, that it had been submitted for OSI approval and withdrawn when it became clear it would not be approved, and that Elastic’s move of projects previously offered under the Apache license to it restricted cloud service providers from offering the software as a service, contrary to the sixth OSD criterion.[23] Vendor terms are covered in MongoDB licensing and Elastic licensing.
The same questions arise for machine-learning models distributed with published weights. In July 2023 OSI stated that Meta’s LLaMa 2 license is not open source because it restricts commercial use for some users and restricts use for certain purposes through an Acceptable Use Policy, contrary to OSD criteria 5 and 6.[24] The license versions and thresholds are covered in Meta Llama licensing. For SAM, the practical consequence is that “open” in a product’s marketing does not establish which license family applies; the license text and its SPDX identifier do.
Practice in software asset management
Inventory and SBOMs
A software bill of materials (SBOM) is, in the words of the U.S. Cybersecurity and Infrastructure Security Agency, “a nested inventory, a list of ingredients that make up software components”.[21] The NTIA’s 2021 minimum elements report, issued under Executive Order 14028, set the minimum data fields as supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp.[20] License data was not among those minimum fields, although the report describes license management as an early SBOM use case, especially for open source software, and notes that SPDX and CycloneDX can both express licenses using SPDX identifiers and expressions.[20] CISA’s August 2025 public comment draft of updated minimum elements adds a License element, to be conveyed in machine-processable form where possible, to include proprietary license conditions, and to be marked unknown when the author does not know it.[22]
License identification
SPDX short identifiers give each listed license a stable code such as MIT or GPL-3.0-or-later; deprecated identifiers remain valid but should not be used.[14] SPDX license expressions combine identifiers: OR records a choice between licenses, AND records that both must be complied with, and WITH attaches a listed exception; licenses not on the list are recorded as user-defined LicenseRef- references.[15] SPDX states that its mission is to develop open standards for communicating software bill of materials information, including provenance, license and security information.[16] Identification records what a component declares; it does not decide whether a given use complies.
Policy and approval workflows
ISO/IEC 5230 defines the key requirements of a quality open source license compliance program. According to the OpenChain Project, it identifies the key places to have license compliance processes, how to assign roles and responsibilities, and how to ensure those processes are sustained, for past, current and future products or services.[18][19] In SAM practice such a program commonly comprises a written policy that classifies license families by permitted use (internal use, distribution, SaaS); an intake or approval step before a component is used; a record of each component’s identifier and version; and a release review that confirms notices, license texts and source offers before software is distributed. Because obligations turn on distribution and, for AGPL, network use, one component can be approved for internal tools and refused for a distributed or hosted product.
Standards and frameworks
| Standard or publication | Subject |
|---|---|
| ISO/IEC 5230:2020 (OpenChain) | Requirements of an open source license compliance program[19] |
| ISO/IEC 5962:2021 (SPDX 2.2.1) | Data format for software package, license and related metadata[17] |
| SPDX License List v3.29.0 | Short identifiers and FSF/OSI status flags[14] |
| NTIA minimum elements (2021) | Baseline SBOM data fields[20] |
| CISA minimum elements (2025 draft) | Updated SBOM elements, including License[22] |
Relationship to other disciplines
Open source licensing is a branch of software licensing in which conditions take the place of a priced metric. It shares the inventory discipline of software asset management, but reconciliation compares components against license conditions and policy rather than purchased quantities under a licensing model.
Criticism and challenges
The terms “open source” and “free software” reflect different emphases. The FSF frames free software as a political and ethical choice,[4] and its license judgments do not always coincide with OSI’s.[14] Use of “open” for source-available software and for AI models with usage restrictions has been disputed by OSI.[23][24]
Out of scope
This article does not interpret particular combinations, court decisions or contributor license agreements. Commercial subscriptions for open source products are covered in vendor articles such as Red Hat Enterprise Linux and OpenShift.