Software licenses: a guide to understanding permissions and obligations

Technical account. October 2026. A map for reading licenses, understanding integrations, and recognizing questions that require legal analysis in the specific case.

You find a library that solves a difficult problem, add the dependency, and keep developing. Months later, the product is ready to reach the customer. At that point a question appears that should have accompanied the choice: what does this license allow — and what does it require from whoever delivers the software?

The answer depends on the text, the version, and what you do with the component. Running a tool, modifying a library, delivering an installer, and offering a service over the internet are different situations.

This guide goes through the main families of licenses, with examples of where those differences appear. The central question is practical: what permissions and obligations come with the software you are building?

What a license grants

A license grants permissions over rights that would otherwise remain reserved to the holder. It may authorize copying, modification, and redistribution, setting conditions for those acts. A code license also does not by itself resolve every right over trademarks, patents, or third-party materials present in the project.

The legal framing cannot be reduced to the sentence “every license is a contract.” Conditions of a copyright authorization and contractual obligations can have different consequences. In Jacobsen v. Katzer, in 2008, a United States federal court of appeals recognized that certain requirements of the Artistic License could operate as conditions of the copyright license. The decision reversed the earlier analysis and sent the case back to the trial court; it did not establish that every breach of every license automatically produces the same judgment. Official decision [1].

That is why the starting point is the text applicable to the component and the version received. A badge in the README helps locate the information; it does not replace reading the conditions.

Permissive, copyleft, and the meaning of open

Permissive licenses grant broad freedom to reuse, including in proprietary products, with conditions such as preserving notices. Copyleft licenses add reciprocity obligations for covered code. The reach of that reciprocity varies: files, libraries, or a combined work, depending on the license and the integration.

Both families allow commercial activity. The open-source definition includes free redistribution and does not allow prohibiting use in particular fields of endeavor. Visible code with restrictions on certain uses can be source-available without being open source in this sense. Open Source Definition [2].

For developers, the difference appears in three questions: what was incorporated, what was modified, and who receives a copy or interacts with the running version?

Permissive licenses

MIT: broad permissions, notices preserved

The MIT license allows using, copying, modifying, distributing, sublicensing, and selling the software. It requires including the copyright notice and permission text in copies or substantial portions of the material. It also contains a warranty disclaimer and limitation of liability. MIT text [3].

Example: incorporating an MIT library into a paid application may be allowed without opening the application's code. The library notices still accompany the distribution; changing the product name does not remove that condition.

MIT does not contain an express patent license grant. That is different from saying that no implied right could exist in any jurisdiction. It also does not allow concluding that patent issues are irrelevant merely because the project is small.

BSD: check the number of clauses

Two-clause BSD requires preserving notices, conditions, and disclaimers. In a binary redistribution, that information must appear in the documentation or materials accompanying the distribution. Three-clause BSD adds a restriction on using the names of holders or contributors to endorse or promote derivatives without prior written permission. BSD-2-Clause [4], BSD-3-Clause [5].

Neither variant contains an express patent grant. Writing only “BSD” in the inventory loses necessary information: which text is being used?

ISC: short, with concrete conditions

ISC grants broad permissions to use, copy, modify, and distribute, with or without charge. It requires preserving copyright and permission notices and contains warranty and liability disclaimers. It is a concise license, but its text still has to accompany use according to its conditions. ISC text [6].

Apache 2.0: more detailed patents and redistribution

Apache 2.0 permits reuse in proprietary software. On redistribution, it requires providing the license, identifying modified files, and preserving relevant notices. If there is a NOTICE file, applicable attribution notices need to be reproduced in one of the forms allowed by section 4. This is not an obligation to copy indiscriminately every file with that name.

Section 3 includes an express patent grant from contributors, limited to licensable claims necessarily infringed by the contribution, alone or combined with the work to which it was submitted. It does not cover every patent of every contributor or guarantee the absence of third-party patents.

The patent license also terminates when the user starts the patent litigation described in section 3. Section 6 does not grant a general trademark authorization. Apache 2.0 text [7].

Copyleft with a bounded scope

MPL 2.0: the boundary follows covered files

MPL 2.0 is often described as file-level copyleft. When distributing executables containing covered software, you must make the corresponding source code available under MPL and explain how to obtain it. This includes covered files you did not modify.

Separate files that are not covered software can form a Larger Work under other terms, including proprietary ones. Changes kept only for private use do not automatically create a duty to publish them. MPL 2.0 text [8], Mozilla FAQ [9].

Example: if you modify an MPL file and distribute the result, that file remains subject to MPL. The license does not automatically cover every independent file in the application.

LGPL: the library and the possibility of replacing it

LGPL allows certain combinations of free libraries with applications under other licenses. Under LGPLv3, distribution of the combined work must meet conditions that preserve modification of the library and recombination with the application. This includes notices and permissions, including for reverse engineering intended to debug those modifications.

One possibility is a suitable shared-library mechanism. Another involves providing object code or enough application material to permit recombination, in addition to the library's corresponding source. Static linking does not automatically require disclosing the application's proprietary source; dynamic linking does not automatically remove the conditions. LGPLv3, section 4 [10].

The version matters: LGPLv2.1 and LGPLv3 are not interchangeable texts. Packaging must be examined together with the license actually received.

EPL and CDDL: read each license's definitions

EPL 2.0 defines the scope of the program and modified works, including distinctions for works that merely link to or link by name to interfaces. It has its own patent and secondary-licensing provisions when that option was expressly made available. Reducing it to “module copyleft” hides these conditions. EPL 2.0 [11].

CDDL also allows a larger work with code under other terms while retaining obligations for covered software. Versions 1.0 and 1.1 have patent-related termination clauses, with differences that require checking the received text. CDDL 1.0 [12], CDDL 1.1 [13].

GPL: distributing a covered work brings obligations

GPLv2

Under GPLv2, distributing a covered work in binary form requires meeting the conditions for providing the corresponding source code. When there is a derivative work covered by the license, distribution of the whole must follow GPL. The license itself distinguishes this from merely aggregating independent programs on the same medium. GPLv2, sections 2 and 3 [14].

The scope is not “everything on the same computer.” You need to understand the relationship among components, modifications, and the form of delivery. Running a program and developing a derivative program are different acts.

GPLv3

GPLv3 defines conveying as propagation that enables others to make or receive copies. Mere interaction over a network, without transferring a copy, does not fall within that definition. But a web service can also deliver JavaScript, WebAssembly, applications, or container images: each artifact needs to be examined.

Version 3 includes express patent provisions and, in the situations specified for User Products, information needed to install modified versions. It also provides mechanisms for restoring rights after correction. One involves curing the first violation notified by a particular holder within 30 days; it is not a universal grace period for every breach. GPLv3, sections 0, 6, 8, and 11 [15].

Source for whom? And can you charge?

Making source available under GPL does not necessarily mean putting everything in one particular public repository. The license defines recipients and methods of provision or offer. Recipients, in turn, retain the redistribution rights provided by it. GNU license FAQ [16].

GPL software can be sold. Revenue can come from distribution, support, and services. The point to assess is compatibility between the obligations and the intended model, especially when you want to restrict redistribution or keep a covered work proprietary. FSF: selling free software [17].

AGPL: an additional condition for network interaction

Section 13 of AGPLv3 establishes a specific obligation: if you modify the program and the modified version allows remote network interaction, you must offer all those users, prominently and free of charge over the network, the corresponding source code for that version. AGPLv3, section 13 [18].

“Users” does not mean only external customers. Employees who interact remotely with a modified version are not categorically excluded by the text. Calling the installation internal does not settle the question.

Running an unmodified version does not, by that isolated fact, trigger this specific modification requirement. That does not authorize removing existing mechanisms or eliminate other applicable conditions, such as those for distributing copies. And AGPL is not a ban on offering commercial hosting.

Example: you modify an AGPL application that people use through a browser. You need to examine the offer of corresponding source to anyone interacting with that version. The sentence “nobody downloaded the server” does not end the analysis.

License changes: the history must point the right way

In Grafana's case, the 2021 change was from Apache 2.0 to AGPLv3 in the central Grafana, Loki, and Tempo projects. This does not automatically describe every product and component of the organization. Grafana licensing [19].

In 2024 Elastic announced AGPLv3 as an additional option for the free source-code portions of Elasticsearch and Kibana that were already available under SSPL and Elastic License 2.0. Distributions remained under Elastic License. It was not a complete migration of every artifact to AGPL. Elastic FAQ [20].

In Redis 8 and later, there is a choice among AGPLv3, SSPLv1, and RSALv2. Redis 7.2 and earlier remain BSD-3-Clause; the 7.4–7.8 range is under RSALv2 or SSPLv1. The product name alone does not identify the license. Official Redis history [21].

Public domain, CC0, Unlicense, and 0BSD

The Unlicense combines a dedication to the public domain with broad permissions and a warranty disclaimer. The legal effect of that dedication depends on applicable law; the text contains no express patent grant. Unlicense text [22].

CC0 seeks to waive copyright and related rights as far as permitted and contains a fallback license when the waiver does not have the intended effect. It expressly excludes trademark and patent rights from its scope. CC0 1.0, legal text [23].

0BSD is a permissive license without an attribution condition. It does not depend on presenting the software as public domain and likewise contains no express patent grant. 0BSD text [24].

These are different instruments. The absence of a credit requirement does not demonstrate the absence of every other possible right over the material.

Creative Commons: content and code require distinctions

Creative Commons recommends its software-specific licenses for code because its content licenses were not designed to address matters such as source distribution. But that does not authorize saying that every CC license is incompatible with free software.

The organization itself considers CC0 acceptable for software, with its limitations, and explains a specific one-way compatibility between CC BY-SA 4.0 and GPLv3 for certain adaptations. This exception does not make every combination of CC licenses automatically compatible. Official Creative Commons FAQ [25].

In one repository, code, documentation, and images can have different licenses. A README under Creative Commons does not necessarily mean that the library is under it too.

Source-available: being able to read is not having every freedom

MongoDB's SSPL contains a service condition broader than AGPL's network clause. Section 13 reaches making the program's functionality available as a service to third parties and requires Service Source Code, defined to include management and operating software needed to run an instance of the service. It is not enough to equate it to “AGPL under another name.” SSPL text [26].

SSPL is not approved by OSI. The approval proposal was withdrawn; describing the episode as an approval denied in a formal decision would be inaccurate. OSI position on SSPL [27].

The Business Source License, often abbreviated BSL or BUSL, was created by MariaDB. In version 1.1, additional permissions and the future change to another license depend on the work's parameters: Additional Use Grant, Change Date, and Change License. During the restricted phase, it is not an open-source license. Elastic License 2.0 is another instrument. Business Source License 1.1 [28].

The SPDX identifier for this version is BUSL-1.1. Do not confuse it with BSL-1.0, which identifies the Boost Software License, a different open-source license. BUSL-1.1 at SPDX [29], Boost Software License 1.0 [30].

Examining production, hosting, and competition restrictions is part of the choice. Being able to download the source does not replace those conditions.

Compatibility: versions and direction matter

Compatibility means being able to comply simultaneously with the conditions applicable to the intended combination. It is not merely a ranking among lighter and stronger licenses.

The Apache Software Foundation explains that Apache 2.0 is compatible with GPLv3, allowing combination under GPLv3, but not with GPLv2. If the component permits a later GPL version, that option may change the analysis. Apache compatibility FAQ [31].

Permissive code can participate in copyleft works while preserving its notices and relevant conditions. The reverse is not automatic: receiving GPL code does not grant the right to redistribute it only under MIT. Express exceptions, alternative licenses, and permission from holders can change the result. GNU FAQ on combinations and compatibility [16].

It is also important to distinguish GPL-2.0-only from GPL-2.0-or-later. “GPL” without a version is insufficient information for deciding an integration.

Dual licensing and open core

In dual licensing, the same code can be offered under alternative licenses. One may be copyleft; another may permit certain proprietary integrations under negotiated conditions. Warranties and support depend on the agreement, not on the name of the strategy.

Whoever offers the alternative must have sufficient rights to do so. This may come from ownership, assignment, or adequate contribution permissions. A CLA is one possible path; it is not a universal requirement and cannot relicense third-party rights that were never granted. FSF: copyright assignment and selling exceptions [32].

In open core, the open core coexists with extensions or features under other terms. Architecture helps organize the boundaries, but dependency licenses and the relationship among components remain relevant. Separating folders or processes does not, by itself, establish a legal conclusion about independence.

Compliance in practice: track what leaves the build

A useful policy begins with an inventory of what the product actually contains. This includes transitive dependencies, copied code, binaries, typefaces, images, and materials generated or incorporated during the build.

An operational flow can follow this sequence:

1. Identify the component, origin, and version. Also record local modifications and the artifacts in which it appears. 2. Keep the applicable text. Check the root license, file notices, exceptions, and third-party licenses included in the package. 3. Map the acts. Distinguish running, modifying, delivering copies, and remote interaction; examine what reaches the browser and customer. 4. Prepare obligations before delivery. Include notices and, when required, corresponding source, offers, and recombination or installation materials. 5. Automate change detection. Use scanners and a software bill of materials — an SBOM — to flag new dependencies and divergences requiring review. 6. Check the final package. The repository inventory and the content actually distributed can diverge.

Scanners help find evidence; their results need interpretation. A file with no identified license requires investigation. Publication in a visible repository does not, by itself, equal a general authorization to reuse. GitHub: repository licensing [33].

SPDX: express the license without losing conditions

SPDX identifiers allow licenses to be recorded in a standardized way. An expression such as MIT OR Apache-2.0 indicates alternatives; MIT AND Apache-2.0 indicates cumulative obligations in the represented scope; WITH associates an identified exception with a license.

A line such as SPDX-License-Identifier: MIT helps tools and people recognize the declaration. It does not prove that the declarant held all rights. And appearing on the SPDX list does not mean OSI approval: the list also identifies licenses that are not open source. SPDX list [34], expression specification [35].

A quick map for returning to the right text

MIT, BSD, and ISC — Main point to check: Broad permissions, with the notices and other conditions of the received variant.

Apache 2.0 — Main point to check: Redistribution, relevant notices, modified files, and the scope of the patent grant.

MPL 2.0 — Main point to check: Source for covered files in the distribution, including unmodified ones.

LGPL — Main point to check: Conditions of the library and combined work, including replacement or recombination.

GPL — Main point to check: Scope of the covered work, delivery of copies, and provision of corresponding source.

AGPLv3 — Main point to check: GPL conditions and source offer during remote interaction with the modified version.

Unlicense, CC0, and 0BSD — Main point to check: Different instruments; pay attention to rights they do not expressly grant.

SSPL and Business Source License — Main point to check: Their own service or use conditions; do not automatically classify them as open source.

The table is an index, not a replacement for the texts. A generic “low risk” or “high risk” label says less than a concrete description of the integration and the obligations that will be fulfilled.

A license accompanies architecture, distribution, and business decisions from the first dependency. Understanding that relationship makes it possible to choose more clearly what to reuse, what to share, and how to sustain the product without erasing the rights of those who built its parts.