MIT vs Apache 2.0 vs GPL-3.0: Choosing an Open Source License
By Byteary Team · Sep 26, 2026 · 4 min read
Publishing code on GitHub without a license does not make it free to use. By default, copyright law reserves all rights to the author, so nobody may legally copy, modify or redistribute it. A license grants those rights - and the three most popular licenses grant them on quite different terms.
This is a practical overview, not legal advice. For commercial or unusual situations, ask a lawyer.
Permissive vs copyleft
Open source licenses fall into two families:
- Permissive (MIT, Apache 2.0, BSD): anyone may use your code for anything, including in closed-source products, as long as they keep the copyright and license notice.
- Copyleft (GPL): anyone may use and modify your code, but if they distribute software based on it, they must release that software's source code under the same license.
Permissive licenses maximise adoption. Copyleft licenses make sure improvements stay open.
The three licenses side by side
| MIT | Apache 2.0 | GPL-3.0 | |
|---|---|---|---|
| Type | Permissive | Permissive | Strong copyleft |
| Commercial use | Yes | Yes | Yes |
| Use in closed-source products | Yes | Yes | Only if not distributed, or the product is released under GPL |
| Must keep the notice | Yes | Yes, plus any NOTICE file | Yes |
| Must mark changes | No | Yes, in modified files | Yes |
| Must share source of derived work | No | No | Yes, when distributed |
| Explicit patent grant | No | Yes | Yes |
| Length | One short paragraph | Several pages | Several pages |
MIT: short and simple
The MIT License fits in one paragraph: do anything you like with the code, keep the notice, and there is no warranty. It is the most common license on GitHub and the default choice for small libraries, because nobody needs a lawyer to understand it.
Apache 2.0: permissive, with patent protection
Apache 2.0 allows the same uses as MIT but adds two things. First, an explicit patent grant: each contributor licenses any patents that cover their contribution, and anyone who sues over those patents loses the license. Second, some paperwork: modified files must say they were changed, and a NOTICE file, if the project has one, must be passed on. Companies often prefer Apache 2.0 for exactly that patent clause.
GPL-3.0: keep it open
With GPL-3.0, anyone who distributes a program containing your code must offer its complete source under GPL-3.0 too. It also includes a patent grant and rules against locking down devices so modified versions cannot run ("anti-tivoization"). An important detail: running software on a server is not distribution, so a company can modify GPL code for its own web service without sharing it. If you want to close that gap, the AGPL-3.0 extends the source requirement to users who interact with the software over a network.
Compatibility: can the code be combined?
- MIT code can be included in Apache 2.0 or GPL projects.
- Apache 2.0 code can be included in GPL-3.0 projects, but not in GPL-2.0-only projects.
- GPL code cannot be included in an MIT or Apache project without the combined work becoming GPL.
Check your dependencies' licenses before choosing yours - a GPL dependency affects what you can ship.
Verdict
- You want as many people as possible to use it: MIT.
- Same, but companies or patents are involved: Apache 2.0.
- You want every distributed improvement to stay open source: GPL-3.0 (or AGPL-3.0 for network services).
Adding the license to your project
Save the license text as LICENSE in the repository root - GitHub detects it and shows the license on the repository page. The LICENSE Generator fills in your name and year for MIT and other short licenses, and produces the official notice for Apache 2.0, GPL-3.0 and MPL-2.0 with a link to the full text. Also add the license identifier to your package manifest ("license": "MIT" in package.json), using the SPDX identifier. choosealicense.com covers less common options. Then mention the license in your README.