Open Source Licensing Models Compared: Copyleft, Permissive, and Emerging Options

Why the License Choice Matters

An open source license defines what others can do with your code — use, modify, distribute, and whether they must share changes back. Picking the right open source licensing model shapes adoption, commercial use, and how contributions flow back into a project. The choice is not just legal; it is a product decision about who can build on your work and under what conditions.

Permissive Licenses

Permissive licenses place minimal restrictions on reuse. They allow almost anyone to use, modify, and redistribute the code, even in proprietary products, with few obligations.

• MIT License — Short, simple, and permissive. Requires only that the original copyright notice be included.
• Apache License 2.0 — Permissive like MIT but adds an explicit patent grant and a patent retaliation clause.
• BSD (2-Clause and 3-Clause) — Similar to MIT, with the 3-clause version adding a restriction on using the project's name for endorsement without permission.

These licenses maximize adoption and are common in libraries, tools, and frameworks where the goal is broad uptake.

Copyleft Licenses

Copyleft licenses require that derivative works carry the same license, ensuring modifications remain open.

• GNU General Public License v3 (GPLv3) — Strong copyleft. Any distributed derivative must also be licensed under GPLv3, including the source code.
• GNU Lesser General Public License (LGPL) — Weaker copyleft. Allows linking to LGPL-covered libraries in proprietary software without forcing the entire application to be open source, though modifications to the library itself must be shared.
• GNU Affero General Public License (AGPL) — Extends GPLv3's copyleft to network use: if users interact with the software over a network, the source must be made available.

Copyleft is favored when the goal is to keep the commons growing and prevent proprietary lock-in of shared code.

Weak Copyleft and Hybrid Models

Some licenses sit between permissive and strong copyleft, applying reciprocity only to specific parts of a work.

• Mozilla Public License 2.0 (MPL) — File-level copyleft. Only files that contain MPL-covered code must remain open; other files in a combined work can have a different license.
• Eclipse Public License 2.0 — Similar to MPL in its file-level approach, with additional compatibility provisions.

These models are useful for projects that want to encourage proprietary integrations while protecting the core codebase.

Emerging and Source-Available Licenses

In recent years, new licensing approaches have emerged to protect open source projects from cloud providers and large-scale commercial use without fully closing the source.

• Business Source License (BSL) — Not open source by the OSI definition. Grants access to source and allows modification, but restricts production use until a specified time, after which the code often converts to a standard open license.
• PolyForm licenses — Designed for non-production use, often for research or evaluation, with commercial use requiring a separate agreement.

These models trade some openness for sustainability and are common in database and infrastructure projects.

How to Choose the Right Model

Selecting an open source licensing model depends on the project's goals, the community's expectations, and the intended user base.

Before choosing, review compatibility with dependencies, confirm the OSI definition if open-source status matters, and consult legal counsel for significant projects.