Career
Open Source Licenses Explained: MIT, Apache 2.0, and GPL for Developers
May 20269 min read
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.
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 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.
Open Source License Decision Tree (2025)
Start: What is your goal?
│
┌──────────────┼──────────────┐
│ │ │
Max adoption Enterprise/ Keep it open
minimal fuss patent safe (derivatives too)
│ │ │
MIT Apache 2.0 GPL v3
│ │ │
"Do whatever, "Do whatever + "Any derivative
keep copyright" patent grant" must be GPL"
│ │ │
Next.js, React Kubernetes, Linux kernel,
Most npm pkgs TensorFlow GNU tools
─────────────────────────────────────────────────────
Library that companies will use → LGPL
(can link to LGPL lib without making their code GPL)
SaaS with open source + commercial tier → AGPL
(forces cloud providers to contribute back)
─────────────────────────────────────────────────────
License Popularity (OSI 2025 pageviews):
MIT: ████████████████████████ #1 by far
Apache 2.0: ████████████ 344K views
BSD 3-Clause: ████████ 214K views
GPL-2.0/3.0: █████ 130K views combinedFrom 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 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.
# Check all dependency licenses in your Node.js project
npm install -g license-checker
license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC'
# Exits non-zero if any dep uses a disallowed license
# package.json — SPDX identifier (machine-readable)
{
"name": "my-erp-module",
"version": "1.0.0",
"license": "MIT", # ← SPDX identifier, not plain text
...
}
# MIT License text (add as LICENSE file in repo root)
MIT License
Copyright (c) 2025 Matthews Wong
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...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 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.
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.
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.
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.