Permissive and copyleft licenses can both be open source, but they attach different conditions to reuse and redistribution.
Permissive and copyleft licenses can both be open source. The difference is what happens after someone receives, modifies, combines, or redistributes the software.
A permissive license usually gives broad reuse rights with relatively light conditions, such as preserving copyright notices and license text. A copyleft license also gives open-source rights, but it uses license conditions to preserve those freedoms in certain downstream versions, combinations, or network-service uses.
The practical choice is not "business versus anti-business." It is a question of project goals, dependency compatibility, redistribution plans, contributor expectations, and how much downstream freedom the license is meant to preserve. This guide is educational, not legal advice. For product, customer, patent, or redistribution decisions, involve qualified counsel.
Quick comparison
| Criterion | Permissive licenses | Copyleft licenses | What to check |
|---|---|---|---|
| Main goal | Maximize downstream flexibility | Preserve software freedoms downstream | Whether your priority is adoption flexibility, reciprocal sharing, or both |
| Common examples | MIT, BSD, ISC, Apache 2.0 | GPL, LGPL, AGPL, MPL 2.0 | Exact license version and SPDX identifier |
| Redistribution | Usually allowed with notice/license conditions | Allowed, often with source-sharing or same-license conditions | Whether you distribute source, binaries, containers, plugins, or modified versions |
| Proprietary combination | Often easier to combine with proprietary code | May require covered code or larger works to remain under compatible terms | How the license defines derivative works, linking, files, or network use |
| Source-code duties | Usually no broad source-publishing requirement | Often requires source availability in defined redistribution or service scenarios | Whether the trigger is distribution, file modification, linking, or network interaction |
| Compatibility work | Still requires notice and dependency tracking | Usually requires closer compatibility review | Dependency tree, dual licensing, exceptions, and license versions |
What permissive means
In open-source licensing, "permissive" is often used as shorthand for non-copyleft or non-reciprocal licenses. These licenses let people use, copy, modify, redistribute, and include the software in larger works without requiring the larger work to use the same license.
That does not mean there are no conditions. A permissive license can require copyright notices, license text, attribution notices, warranty disclaimers, patent terms, or trademark boundaries. Apache 2.0, for example, is permissive but more structured than MIT because it includes explicit patent, NOTICE-file, changed-file, and trademark language.
Permissive licenses are common when a project wants broad adoption across open-source and proprietary ecosystems. They can fit libraries, developer tools, educational examples, infrastructure components, and projects where downstream users need flexibility. The tradeoff is that someone may build a closed product from the code without sharing their changes back, as long as they comply with the license.
What copyleft means
Copyleft uses copyright licensing to keep software freedoms attached to downstream versions in specified situations. Instead of only granting permission to use and modify the code, a copyleft license can require redistributed modified versions, covered files, linked combinations, or network-service versions to preserve source-code access and compatible license terms.
The Open Source Initiative describes copyleft as a license model that allows derivative works while requiring those derivatives to use the same license in relevant cases. GNU explains the same idea as a way to make sure recipients keep the freedom to copy and change redistributed versions.
Copyleft is not one rule. It depends on the specific license. GPL, LGPL, AGPL, and MPL use different scopes and triggers. Reading the actual license text matters more than relying on the word "copyleft."
Weak, strong, and network copyleft
Copyleft licenses vary in scope.
Weak copyleft generally applies reciprocity more narrowly. MPL 2.0 is commonly described as file-level copyleft: modifications to covered files stay under MPL terms, while separate files can often remain under other licenses when the license conditions are followed. LGPL is designed for libraries and allows certain linking patterns under defined conditions.
Strong copyleft generally reaches further when covered code is modified, combined, and redistributed. GPL licenses are the common example. They are designed to preserve software freedom for recipients of redistributed covered works.
Network copyleft addresses software used to provide services over a network. AGPL is the common example. It can require source availability for modified versions used to provide network interaction, not only for copies distributed as downloads.
These labels are shortcuts. The controlling question is always the license text and the way the software is used, modified, combined, or conveyed.
Commercial use and proprietary products
Open source does not forbid commercial use. OSI's FAQ states that open-source software can be used for commercial purposes. A company can sell support, services, devices, hosted access, or distributions that include open-source software, but it must still follow the license conditions.
Permissive licenses often create fewer license-driven barriers to proprietary combination because they usually do not require the larger work to adopt the same license. That is why companies often like permissive licenses for libraries and infrastructure.
Copyleft licenses can also be used commercially, but they may make some proprietary distribution models harder or incompatible. If a company distributes a modified GPL-covered program, builds a product around a covered combined work, or offers a modified AGPL-covered service, the license may require source availability and compatible downstream terms.
Do not guess from the license family alone. Internal use, unmodified redistribution, modified redistribution, dynamic linking, plugin APIs, containers, SaaS deployment, and embedded devices can raise different questions.
Notices, source code, and redistribution
Both families require discipline. A permissive license may look short, but redistributors still need to preserve required notices and license text. A copyleft license may require the same notices plus corresponding source, installation information, changed-file notices, or license text depending on the license and distribution path.
Distribution is often the moment when obligations become visible. Sending a binary, publishing a fork, shipping an installer, bundling a dependency, distributing a container image, or delivering firmware can be different from using a tool privately.
For ordinary users who only install an app, these issues may stay mostly in the background. For developers, maintainers, package builders, and organizations, they become part of release and dependency management. FOSShub's software packaging guide and dependency management guide explain the operational side of keeping package and dependency evidence organized.
Compatibility and dependency checks
License compatibility matters when code under multiple licenses is combined, linked, bundled, copied, or redistributed together. Two licenses can both be open source and still create conditions that do not fit the planned combination.
Start with exact identifiers. SPDX identifiers such as MIT, Apache-2.0, GPL-3.0-only, GPL-3.0-or-later, LGPL-3.0-only, AGPL-3.0-only, and MPL-2.0 make license records less ambiguous. The difference between "only" and "or later" can matter, as can exceptions and dual-license expressions.
Then check the real shape of the software. Is the code copied into your project, linked as a library, loaded as a plugin, bundled as a separate program, packaged in a container, or used only as a local tool? Family labels help you ask the right questions, but they do not answer every compatibility issue.
If source and binary labels are part of the decision, the source code and binary files guide explains why release artifacts, source archives, and package metadata should match the evidence you rely on.
When a permissive license may fit
A permissive license may fit when the project wants maximum downstream flexibility and relatively simple redistribution conditions.
Common fits include:
- Small libraries, plugins, examples, starter templates, and developer tools.
- Projects that want adoption by both open-source and proprietary users.
- Code meant to be embedded, copied, studied, or adapted with minimal license friction.
- Ecosystems where compatibility with many license models is a major goal.
- Organizations that can manage notices but do not want reciprocal source-sharing terms.
The tradeoff is control. A permissive license may allow downstream proprietary versions that do not publish their changes. If the project goal is to guarantee that improvements remain available to later recipients, permissive licensing may not express that goal strongly enough.
For a focused comparison inside the permissive family, see MIT and Apache 2.0 licenses compared.
When a copyleft license may fit
A copyleft license may fit when preserving downstream software freedom is a central project goal.
Common fits include:
- End-user applications where recipients should receive source-code rights with redistributed versions.
- Community projects that want improvements to remain available under compatible terms.
- Infrastructure where proprietary forks would undermine the collaboration model.
- Libraries where a narrower reciprocal boundary, such as LGPL or MPL, fits better than broad GPL-style reciprocity.
- Network services where AGPL-style source availability for modified service versions is intentional.
The tradeoff is review work. Copyleft can require closer attention to dependency trees, linking models, distribution paths, source availability, and compatibility with other licenses. That is not a flaw; it is part of the license design. But it means maintainers and adopters should understand the obligations before choosing or depending on the license.
Checklist before choosing either family
Use this checklist before selecting a permissive or copyleft license for a project, or before relying on either family in software you use:
- Confirm the exact license file in the official repository, release archive, or package metadata.
- Record the SPDX identifier and version, including
only,or-later, exceptions, and dual-license choices. - Check whether the license is OSI-approved if the project calls itself open source.
- Separate private use, internal use, distribution, hosted-service use, and product embedding.
- Identify whether you modify the covered code, combine it with other code, or redistribute it unchanged.
- Preserve copyright, license, attribution, and NOTICE-file requirements.
- Check whether source-code availability, corresponding source, or installation information is required.
- Review patent and trademark language separately from copyright permission.
- Check dependency licenses before assuming the top-level project license answers everything.
- Get qualified review for customer contracts, patents, regulated environments, acquisitions, or commercial redistribution.
Bottom line for license families
Permissive and copyleft licenses are both part of open source. Permissive licenses emphasize flexible reuse with conditions such as notices. Copyleft licenses emphasize preserving software freedoms for downstream recipients in the situations each license defines.
The right choice depends on the project goal. If broad reuse with minimal reciprocity is the priority, a permissive license may fit. If keeping modified or redistributed versions free is the priority, copyleft may fit. In either case, read the actual license file, track exact identifiers, preserve notices, and avoid turning a family label into legal advice.
For the broader foundation, start with FOSShub's open source license guide. For adjacent terminology, see FOSS meaning, free software vs open source, and source-available software.