Copyleft vs Permissive Licenses

What Is a Permissive License?

A permissive license grants users broad rights to use, modify, and redistribute software with minimal conditions. The conditions are typically limited to preserving the copyright notice and including the license text with any redistribution. Beyond that, a permissive license places no restrictions on what users can do with the code. They can incorporate it into proprietary products, sell it, modify it without sharing their changes, or relicense derivative works under completely different terms.

The most common permissive licenses are the MIT License, the Apache License 2.0, the BSD licenses (2-Clause and 3-Clause), and the ISC License. Together, these licenses account for more than 70 percent of all licensed open source software as of 2025, a share that has been growing steadily for over a decade.

The philosophy behind permissive licensing is that maximum freedom means imposing the fewest conditions possible. If someone wants to take your code, improve it, and sell the result without sharing their improvements, a permissive license says that is their right. The code's creator gave it to the world, and the world can do what it pleases. Proponents argue that this approach maximizes the practical impact of open source software by removing barriers to adoption, particularly for businesses that need to integrate open source code into proprietary products.

What Is a Copyleft License?

A copyleft license grants users the same rights as a permissive license (use, modify, redistribute) but adds one critical condition: if you distribute a modified version of the software, you must release your modifications under the same license and make the source code available. This is the "share-alike" or "reciprocal" requirement, and it is what makes copyleft fundamentally different from permissive licensing.

The most prominent copyleft licenses are the GNU General Public License (GPL v2 and v3), the GNU Affero General Public License (AGPL v3), the GNU Lesser General Public License (LGPL), and the Mozilla Public License (MPL 2.0). While their combined market share has declined relative to permissive licenses, copyleft licenses still cover many of the most important projects in computing, including the Linux kernel (GPL v2), WordPress (GPL v2), and MariaDB (GPL v2).

The philosophy behind copyleft is that software freedom should be preserved through all generations of a work. Richard Stallman, who created the GPL and coined the term "copyleft," argued that it is not enough to make software free once. If someone can take free software, modify it, and distribute the result as proprietary software, then the users of that derivative work lose the freedoms that the original author intended to guarantee. Copyleft uses copyright law to enforce the opposite of its usual purpose: instead of restricting copying, it restricts restriction. You can copy, but you cannot restrict others from copying in turn.

Strong Copyleft vs Weak Copyleft

Not all copyleft licenses have the same scope. The distinction between strong and weak copyleft determines how much of a combined work must be open-sourced when copyleft code is included.

Strong copyleft licenses like GPL v3 and AGPL v3 require that the entire program, including all code that is linked with or combined with the GPL code, must be released under the GPL. If you build an application that links against a GPL library, your entire application is considered a derivative work and must be GPL-licensed. The AGPL goes further by defining "distribution" to include providing access to the software over a network, which closes the SaaS loophole that allows companies to modify GPL software, run it on their servers, and never share the changes because they never technically distribute the binary.

Weak copyleft licenses like LGPL and MPL 2.0 limit the scope of the copyleft requirement. The LGPL requires that modifications to the library itself remain open source, but proprietary software can link against the LGPL library without being affected by the copyleft requirement, as long as users can replace the library with a modified version (which generally means using dynamic linking). The MPL 2.0 applies copyleft at the file level: modified MPL files must stay open source, but new files added to the same project can use any license, including a proprietary one.

This distinction matters enormously in practice. A company can use an LGPL-licensed library (like glibc or GTK) in a proprietary product without open-sourcing the product. The same company could not use a GPL-licensed library in the same way without triggering the copyleft requirement for the entire product. Weak copyleft is a deliberate compromise that provides some protection for the open source code while still allowing proprietary adoption.

How Each Approach Affects Adoption

The license you choose directly affects who will use and contribute to your project. The patterns are well-documented and consistent across the open source ecosystem.

Permissive licenses tend to produce higher adoption numbers, especially among commercial users. Companies are more willing to build on MIT or Apache-licensed code because they can incorporate it into proprietary products without any obligation to share their own code. This is why the most widely adopted developer tools, frameworks, and libraries tend to use permissive licenses. React (MIT), Kubernetes (Apache 2.0), TensorFlow (Apache 2.0), and Node.js (MIT) all chose permissive licensing explicitly to maximize adoption.

Copyleft licenses tend to produce stronger community-driven development models. Because copyleft ensures that improvements to the software stay in the open source ecosystem, copyleft projects often develop deep, self-sustaining communities of contributors who know that their work will not be taken proprietary. Linux, WordPress, and the GNU toolchain all demonstrate that copyleft can produce enormously successful projects with vast contributor bases, even if some commercial users are deterred by the license terms.

The dual-licensing model bridges the two approaches. A company releases software under a copyleft license (often AGPL or GPL) for free, open source use. Companies that want to use the software in proprietary products can purchase a commercial license with different terms. This model has been used successfully by MySQL (GPL/commercial), Qt (LGPL/commercial), and MongoDB (SSPL/commercial, though SSPL is controversial and not OSI-approved).

The Business Perspective

From a business standpoint, the choice between copyleft and permissive licensing involves trade-offs that depend on the company's strategy.

Companies that produce open source software for strategic benefit (to establish a platform, attract developers, or commoditize a complementary technology) almost always choose permissive licenses. Google open-sources Android under Apache 2.0 because widespread Android adoption drives demand for Google services. Facebook releases React under MIT because widespread React adoption creates a larger pool of developers skilled in Facebook's technology stack. In these cases, the company benefits from adoption itself, not from restricting how the code is used.

Companies that produce open source software as their primary product tend to prefer copyleft or source-available licenses. The copyleft requirement prevents competitors from taking the code, adding proprietary features, and selling a competing product without contributing back. This is why companies like Red Hat (which built a multibillion-dollar business around GPL-licensed Linux) and Automattic (which develops the GPL-licensed WordPress ecosystem) have been vocal advocates of copyleft.

Companies that consume open source software generally prefer permissive licenses. Legal and compliance teams at large enterprises often maintain lists of approved and restricted licenses. Permissive licenses like MIT, BSD, and Apache 2.0 are almost universally approved for use. GPL-licensed software typically requires additional review and may be restricted to certain use cases (like internal tools that are not distributed). AGPL-licensed software is frequently prohibited entirely in corporate environments because the network distribution trigger could theoretically apply to any server-side application.

The Philosophical Debate

The copyleft-versus-permissive debate is ultimately a philosophical one about what "freedom" means in the context of software.

Advocates of permissive licensing argue that true freedom means the absence of restrictions. A permissive license gives you the code and lets you do whatever you want with it. Imposing conditions, even conditions designed to preserve freedom for others, is still a restriction on the recipient's freedom. This view aligns with the open source movement's emphasis on practical benefits: making source code available improves software quality, accelerates innovation, and reduces costs, and the fewer barriers to adoption, the greater these benefits.

Advocates of copyleft argue that freedom without protection is fragile. If someone can take free software and make it proprietary, then the freedom is lost for all downstream users. Copyleft protects the freedom of the community by ensuring that once code is free, it stays free. This view aligns with the free software movement's emphasis on user rights: users should always have the right to study, modify, and share the software they use, and copyleft is the legal mechanism that guarantees these rights persist.

Neither position is objectively correct. They represent different values and different priorities. The permissive approach has produced enormously successful and widely adopted software. The copyleft approach has produced some of the most foundational and enduring software projects in computing. The best choice for your project depends on which values you prioritize and what outcomes you want to achieve.