# Open Source Licenses Explained: MIT, Apache 2.0, and GPL for Developers > A practical guide to choosing between MIT, Apache 2.0, and GPL licenses for your open-source projects — with real-world implications for commercial use, patent protection, and copyleft requirements. URL: https://www.matthewswong.com/en/blog/open-source-license-guide/ - Author: Matthews Wong (https://www.matthewswong.com/en/about/) - Published: 2025-06-10 - Updated: 2025-06-10 - Category: Career The Open Source Initiative's 2025 data shows MIT and Apache 2.0 dominate the open-source landscape, with permissive licenses accounting for the vast majority of developer interest. MIT leads significantly, with Apache 2.0 drawing 344,000 pageviews — reflecting developer preference for licenses with minimal restrictions. But the most popular license isn't always the right one for your project. The license you choose determines how others can use your code, whether commercial use is allowed, what happens when someone modifies it, and whether your project can be used in enterprise software. As someone who contributes to open-source tooling and builds on open-source libraries daily, understanding these licenses has practical implications for every project. ## The Three License Families Open-source licenses fall into two broad families: permissive (minimal restrictions — MIT, Apache 2.0, BSD) and copyleft (reciprocal sharing requirements — GPL, LGPL, AGPL). A permissive license says 'do whatever you want with this code, just credit me.' A copyleft license says 'you can use and modify this, but any software that includes my code must also be open source under the same terms.' The right choice depends on your goals: maximizing adoption (permissive), ensuring derivatives stay open source (copyleft), or something in between (weak copyleft with LGPL). ### MIT: The Default Choice MIT is the most permissive mainstream open-source license. Requirements: keep the copyright notice and license text in any distribution. That's it. Users can: use the software commercially, modify it, distribute modified versions, and sublicense it. They cannot: hold you liable for damages (the license disclaims warranty). MIT's simplicity is its strength — companies can adopt MIT-licensed code without legal review, which is why frameworks like Next.js, React, and most npm packages use MIT. If your goal is maximum adoption and you don't need patent protection, MIT is the right default. > From building projects that use open-source libraries: always check the licenses of your dependencies before choosing a license for your own project. If you're using a GPL library in your project, your project may need to be GPL as well (viral effect). Tools like license-checker (npm) or FOSSA can scan your dependency tree and flag license incompatibilities. This matters most for commercial projects — an accidentally GPL-incompatible license in your dependency tree can be a legal issue for enterprise customers. ## Apache 2.0: Enterprise-Friendly with Patent Protection Apache 2.0 is MIT-compatible but adds explicit patent grant — contributors to an Apache 2.0 project grant users a patent license for the code they contribute. This means using Apache 2.0 code doesn't expose you to patent lawsuits from contributors (as long as you don't sue the contributors for their patents). This is why large organizations favor Apache 2.0 for projects they contribute to — it provides legal protection that MIT doesn't explicitly address. Kubernetes, TensorFlow, and most Apache Foundation projects use Apache 2.0. If enterprise adoption and patent protection are priorities, choose Apache 2.0 over MIT. ### GPL: The Copyleft License GPL (GNU General Public License) requires that any software incorporating GPL code must also be released under GPL. This is the copyleft or 'viral' property — it ensures that derivatives of open-source software remain open source. GPL v2 (Linux kernel, MySQL) and GPL v3 (added anti-tivoization provisions) are the most common variants. LGPL (Lesser GPL) is a weaker variant — you can link to an LGPL library in a proprietary project without making your project GPL. AGPL (Affero GPL) closes the 'SaaS loophole' — software running over a network (not distributed) must still provide source code to users. > **AGPL is hostile to commercial use — use it intentionally** > AGPL is the license choice for companies that want to offer a commercial license alongside an open-source one (dual licensing). MongoDB, Grafana, and Elastic used AGPL-adjacent licenses specifically to prevent cloud providers from offering their software as a managed service without contributing back. If you choose AGPL for a library, most companies will avoid using it because their legal team will flag it as incompatible with their commercial products. This is a valid strategy if you want to monetize via commercial licenses, but an accident if you just wanted to 'protect' your project without understanding the implications. ## License Compatibility Matrix Not all licenses are compatible with each other. MIT and Apache 2.0 are generally compatible — you can use both in the same project and release under either. MIT and GPL are compatible one-way: you can use MIT code in a GPL project (GPL absorbs MIT), but you can't use GPL code in an MIT project (that would require the MIT project to be GPL). Apache 2.0 and GPL v2 have a subtle incompatibility related to additional requirements — the FSF recommends GPL v3 for Apache 2.0 compatibility. When building a project that combines multiple libraries, check the licenses of every dependency against your intended output license. ## Choosing a License for Your Project Decision framework: (1) Maximum adoption, simple project → MIT. (2) Enterprise adoption, IP protection matters → Apache 2.0. (3) Want derivatives to stay open source, no commercial constraint concern → GPL v3. (4) Library that commercial projects should be able to use without GPL compliance → LGPL. (5) SaaS product you're open-sourcing while preventing free cloud hosting → AGPL. (6) Unsure → MIT. The license choice is a strategic decision, not just a legal formality. It signals to potential contributors and users what kind of project you're building and what freedoms you're granting. ## Practical Considerations for OSS Maintainers Beyond license choice: add a CONTRIBUTORS file and a clear contribution guide if you want external contributions; add a CODE_OF_CONDUCT file to set community expectations; consider a CLA (Contributor License Agreement) if you might want to change the license later (without a CLA, every contributor's consent is needed for license changes); update your package.json, pyproject.toml, or equivalent with the correct SPDX license identifier so package managers and license scanners pick it up correctly. Tools like choosealicense.com (from GitHub) make the selection process readable for non-lawyers. When in doubt, choose MIT — you can always make a project more restrictive in a future version, but you can't revoke permissions you've already granted. ## Sources & Further Reading - Open Source Initiative — Top Open Source Licenses in 2025 - GitHub — Choose a License - Endor Labs — Open Source Licensing Simplified: A Comparative Overview ## Source links - https://opensource.org/blog/top-open-source-licenses-in-2025 - https://choosealicense.com/licenses/ - https://www.endorlabs.com/learn/open-source-licensing-simplified-a-comparative-overview-of-popular-licenses ## FAQ ### What is the key difference between MIT and Apache 2.0, and when should I choose one over the other? Both MIT and Apache 2.0 are permissive licenses that allow commercial use and modification, but Apache 2.0 adds an explicit patent grant — contributors license their patents to users, protecting you from patent lawsuits by contributors. If enterprise adoption and intellectual property protection matter to your project, choose Apache 2.0; if you want the simplest possible license with maximum adoption (like React or Next.js), MIT is the right default. ### What does 'copyleft' mean, and why does the GPL's viral effect matter for commercial projects? Copyleft means that any software incorporating GPL-licensed code must also be released under the GPL — this is the 'viral' effect. For commercial projects, this is critical: if you accidentally include a GPL dependency in your codebase, your entire project may need to be open-sourced under GPL. Tools like license-checker (npm) or FOSSA can scan your dependency tree and flag these incompatibilities before they become a legal problem. ### When should I use AGPL instead of GPL, and why do most companies avoid it? AGPL closes the 'SaaS loophole' — unlike GPL, it requires that software running over a network (not distributed) must still provide source code to users. This makes it a deliberate choice for companies like MongoDB and Grafana that want to prevent cloud providers from offering their software as a managed service without contributing back. Most companies avoid AGPL because legal teams flag it as incompatible with commercial products, so use it intentionally only if dual-licensing for monetization is your strategy. ### How do I check whether my project's dependencies have license conflicts? You should always check the licenses of all your dependencies before choosing a license for your own project. Tools like license-checker (npm) or FOSSA can scan your full dependency tree and flag incompatibilities — for example, GPL code cannot be used in an MIT-licensed project. This matters most for commercial projects, where an accidentally incompatible license in the dependency tree can create legal issues for enterprise customers. ### What practical steps should OSS maintainers take beyond just picking a license? Beyond choosing a license, maintainers should add a CONTRIBUTORS file and a clear contribution guide, include a CODE_OF_CONDUCT to set community expectations, and update their package.json or pyproject.toml with the correct SPDX license identifier so package managers and license scanners pick it up correctly. Consider a CLA (Contributor License Agreement) if you might want to change the license later — without one, every contributor's consent is needed for any license change. The site choosealicense.com from GitHub makes the selection process accessible for non-lawyers. --- - HTML version: https://www.matthewswong.com/en/blog/open-source-license-guide/ - Bahasa Indonesia: https://www.matthewswong.com/id/blog/open-source-license-guide/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json