Software Licenses

Not legal advice

This is a technical reference. For business-critical or high-risk licensing questions, ask a qualified lawyer.

Quick Picks

Lowest friction

Use MIT when you want a short, familiar license that is easy for most developers and companies to adopt.

Patent-aware permissive

Use Apache-2.0 when you want a permissive license with an explicit patent grant.

Keep derivatives open

Use GPL-3.0 or AGPL-3.0 when preserving open source obligations is a core project goal.

Quick Comparison

License	Type	Allows commercial use	Requires source disclosure	Patent grant	Best for
MIT	Permissive	Yes	No	No explicit grant	Simple libraries, examples, small tools
BSD 2-Clause	Permissive	Yes	No	No explicit grant	Academic and infrastructure projects
BSD 3-Clause	Permissive	Yes	No	No explicit grant	Projects that also restrict endorsement
Apache-2.0	Permissive	Yes	No	Yes	Libraries, SDKs, company-backed projects
GPL-3.0	Strong copyleft	Yes	Yes, for distributed derivatives	Yes	Projects that should remain open source
LGPL-3.0	Weak copyleft	Yes	Usually only changes to the LGPL component	Yes	Libraries used by proprietary apps
AGPL-3.0	Network copyleft	Yes	Yes, including network service use	Yes	Server software and hosted applications
MPL-2.0	File-level copyleft	Yes	Yes, for modified MPL files	Yes	Mixed open/proprietary codebases
Unlicense	Public domain style	Yes	No	No explicit grant	Tiny public-domain-like snippets
CC0-1.0	Public domain dedication	Yes	No	No patent license	Data, docs, examples, creative assets

License Families

Permissive Licenses

Permissive licenses allow broad reuse with minimal obligations. Users can usually copy, modify, redistribute, sublicense, and include the code in proprietary products.

• Keep the copyright notice.
• Keep the license text.
• Do not imply endorsement when the license says so.

Copyleft Licenses

Copyleft licenses allow reuse, but require derivative works to remain under compatible open source terms when distributed.

• Provide the license text.
• Preserve notices.
• Provide source code when distributing covered binaries.

Common permissive choices:

• MIT: short, widely understood, and easy to comply with.
• BSD-2-Clause: similar to MIT, with slightly different wording.
• BSD-3-Clause: adds a non-endorsement clause.
• Apache-2.0: includes an explicit patent license and patent retaliation terms.

Common copyleft choices:

• GPL-3.0: strong copyleft for distributed software.
• LGPL-3.0: weaker copyleft designed for libraries.
• AGPL-3.0: extends GPL-style obligations to software offered over a network.
• MPL-2.0: applies copyleft at the file level, allowing easier mixing with proprietary files.

Choosing a License

Goal	Good default
Maximum adoption with minimal friction	MIT
Permissive license with explicit patent protection	Apache-2.0
Keep all distributed derivatives open source	GPL-3.0
Keep a web service open source even when hosted	AGPL-3.0
Open source a library while allowing proprietary apps to link it	LGPL-3.0
Protect only modified files, not the whole project	MPL-2.0
Release documentation, datasets, or examples as freely as possible	CC0-1.0

Compatibility Notes

• MIT, BSD-2-Clause, and BSD-3-Clause code can usually be included in GPL projects.
• Apache-2.0 is compatible with GPL-3.0, but not with GPL-2.0-only.
• GPL code generally cannot be combined into proprietary distributed software.
• LGPL libraries can often be used by proprietary software, but modifications to the LGPL library itself must remain open under LGPL terms.
• AGPL is stricter for hosted software because network users must be able to receive the source code.
• CC0 is common for data and examples, but it is usually not the best choice for software when patent rights matter.

License File Checklist

When adding a license to a project:

1. Create a root LICENSE or LICENSE.md file.
2. Use the exact official license text.
3. Add the copyright line if the license requires one.
4. Mention the license in README.md.
5. Add package metadata where relevant, such as license in package.json.
6. Check dependencies for incompatible licenses before publishing.

Package Metadata Examples

npm package.json

{
  "license": "MIT"
}

For dual licensing:

{
  "license": "(MIT OR Apache-2.0)"
}

Python pyproject.toml

[project]
license = "MIT"

SPDX Identifiers

SPDX identifiers are standard short names used by package managers, scanners, and repositories.

License	SPDX identifier
MIT License	MIT
Apache License 2.0	Apache-2.0
GNU General Public License v3.0 only	GPL-3.0-only
GNU General Public License v3.0 or later	GPL-3.0-or-later
GNU Lesser General Public License v3.0 only	LGPL-3.0-only
GNU Affero General Public License v3.0 only	AGPL-3.0-only
Mozilla Public License 2.0	MPL-2.0
BSD 2-Clause License	BSD-2-Clause
BSD 3-Clause License	BSD-3-Clause
Creative Commons Zero v1.0 Universal	CC0-1.0
The Unlicense	Unlicense

Further Reading

• Choose an open source license
• SPDX License List
• Open Source Initiative licenses