How to Choose an Open Source License for Your Project

How to Choose an Open Source License

Choosing a license is one of the first decisions you make when publishing an open source project. The right choice depends on your goals, your community, and how you want others to use your code.

Decision Framework

Ask yourself these questions:

1. Do you want maximum adoption? Choose a permissive license (MIT, ISC, Apache-2.0)
2. Do you want derivative works to stay open source? Choose a copyleft license (GPL-3.0, AGPL-3.0)
3. Do you need patent protection? Choose Apache-2.0 or GPL-3.0
4. Is this a library that will be linked into other programs? Consider LGPL-3.0 or MPL-2.0
5. Is this a web service? Consider AGPL-3.0 if copyleft is important

Quick Recommendation Table

Scenario	Recommended License
JavaScript library / npm package	MIT or ISC
Enterprise tool / corporate contribution	Apache-2.0
Application that must stay open	GPL-3.0
Library used by proprietary apps	LGPL-3.0 or MIT
Web service / SaaS	AGPL-3.0 (if copyleft desired)
Public domain dedication	Unlicense or CC0-1.0
Dual-license (open + commercial)	AGPL-3.0 + commercial

Common Mistakes

• No license at all — Without a license, the default copyright applies and nobody can legally use, modify, or distribute your code
• Custom licenses — Creating your own license text is almost always a bad idea. Stick to OSI-approved licenses
• Wrong license for the ecosystem — Some ecosystems have strong conventions (e.g., MIT/ISC for npm, Apache-2.0 for Java/enterprise)
• Changing license after contributions — Changing the license of a project with external contributors requires consent from all contributors

License Compatibility

Not all licenses are compatible with each other. For example:

• GPL-2.0 code cannot be combined with Apache-2.0 code
• GPL-3.0 is compatible with Apache-2.0
• MIT, BSD, and ISC are compatible with almost everything
• AGPL-3.0 is compatible with GPL-3.0 but not GPL-2.0