Why Licenses Matter
Copyright law grants the author of code exclusive rights by default. Without a license, no one can legally copy, modify, or distribute your code — even if it's publicly visible on GitHub. A license grants users specific permissions and defines what obligations come with those permissions.
When you use a library without checking its license, you may be unknowingly violating copyright. When you publish code without adding a license, you're not making it "free to use" — you're making it legally ambiguous.
The Three Categories of Open Source Licenses
| Category | Key Requirement | Examples |
|---|---|---|
| Permissive | Keep copyright notice. Do almost anything else. | MIT, Apache 2.0, BSD |
| Weak Copyleft | Modifications to the library must be open-sourced, but you can use it in proprietary software. | LGPL, MPL 2.0 |
| Strong Copyleft | Any software using this code must also be open-sourced under the same license. | GPL v2, GPL v3, AGPL |
MIT License
The most popular open source license. Short, simple, and permissive.
You can: Use commercially, modify, distribute, sublicense, use privately
You must: Include the copyright notice and license text in any distribution
You cannot: Hold the author liable
Used by: React, Vue, Rails, jQuery, Bootstrap, Next.js, most npm packages
In practice: You can use MIT-licensed libraries in proprietary commercial software. You don't need to open-source your code. You just need to include the MIT license file (usually in a LICENSES directory or NOTICE file).
Apache License 2.0
Similar to MIT but adds explicit patent grants and has stronger trademark protections.
You can: Use commercially, modify, distribute, sublicense, use privately
You must: Include license and copyright notice; state changes made to files; include NOTICE file if present
You cannot: Use contributor trademarks; hold authors liable
Key difference from MIT: Contributors explicitly grant you a patent license. If a contributor has a patent covering the code, they can't sue you for using it. MIT has no such protection.
Used by: Kubernetes, Hadoop, Kafka, TensorFlow, Android (AOSP), many Apache Software Foundation projects
MIT vs Apache 2.0: For most projects, they're functionally equivalent. Choose Apache 2.0 if patent protection matters (e.g., in enterprise or biotech contexts). MIT is simpler and more widely understood.
BSD Licenses
Several variants exist. All are permissive like MIT.
- BSD 2-Clause ("Simplified BSD") — nearly identical to MIT
- BSD 3-Clause ("New BSD") — adds a clause prohibiting use of project name in endorsements without permission
- BSD 4-Clause — deprecated; had an "advertising clause" that caused GPL incompatibility
Used by: FreeBSD, many older Unix utilities, some Python packages
GNU GPL (General Public License)
The original strong copyleft license by the Free Software Foundation. The defining concept is "copyleft": any software that incorporates GPL code must itself be GPL-licensed.
You can: Use, modify, distribute
You must: Release source code of your modified version; use GPL for the entire combined work; include license text
You cannot: Use in proprietary software (the entire project becomes GPL)
Used by: Linux kernel (GPLv2), Git, GCC, WordPress (plugins), VLC
GPL v2 vs v3
| Aspect | GPL v2 | GPL v3 |
|---|---|---|
| Tivoization | Allowed | Prohibited — hardware must allow modified software to run |
| Patent retaliation | No explicit clause | Explicit patent grant and retaliation clause |
| Compatibility with Apache 2.0 | Incompatible | Compatible |
| Adoption | Linux kernel uses v2-only | Most new GPL projects use v3 |
Commercial implications: If you use GPL v2/v3 code in your commercial product, your entire product must be open-sourced under GPL. This is why many companies pay for commercial licenses from projects like MySQL, Qt, and MongoDB.
LGPL (Lesser GPL)
A "weaker" copyleft license that allows proprietary software to use the library without requiring the entire project to be open-sourced. However, modifications to the library itself must remain LGPL.
Used by: Qt (LGPL edition), GNU libc, FFmpeg (portions)
Typical use: Libraries designed to be usable in proprietary software. If you modify the LGPL library, you must release your modifications. If you just use it via standard interfaces, your application can remain proprietary.
AGPL (Affero GPL)
Like GPL v3 but closes the "SaaS loophole": if you run AGPL software as a service over a network, you must make the source code available to users of that service. GPL only triggers when distributing software, not when running it as a service.
Used by: MongoDB (SSPL, similar), Nextcloud, Mastodon, many "open core" SaaS companies
Implication: If you build a SaaS product using AGPL code, your service's source must be open. This is how companies like MongoDB protect against cloud providers building competing services.
Mozilla Public License 2.0 (MPL)
File-level weak copyleft. MPL-licensed files must remain MPL, but you can combine them with proprietary code in the same project as long as the files stay separate.
Used by: Firefox, Thunderbird, LibreOffice
License Compatibility
When combining code with different licenses, they must be compatible. Key incompatibilities:
- GPL v2 + Apache 2.0 — incompatible (patent clause conflicts)
- GPL v3 + Apache 2.0 — compatible
- GPL + MIT — compatible (MIT becomes GPL when combined)
- GPL v2 + GPL v3 — incompatible (v2-only code can't be relicensed to v3)
Choosing a License for Your Project
| Goal | Recommended License |
|---|---|
| Maximum adoption, businesses and individuals can use freely | MIT or Apache 2.0 |
| Want patent protection for contributors | Apache 2.0 |
| Want contributions to stay open source, but allow commercial use | GPL v3 |
| Library that can be used in proprietary software, modifications stay open | LGPL v2.1 or MPL 2.0 |
| Protect against SaaS providers forking without contributing back | AGPL v3 |
| No one can use this code for anything | No license (default copyright) |
Use choosealicense.com (by GitHub) to help choose. Once you decide, add a LICENSE file to the root of your repository — GitHub detects it automatically.
Dual Licensing
Many successful open source companies use dual licensing: release under AGPL or GPL for free/open use, and offer a commercial license to businesses that need proprietary integration. Examples: MySQL, Qt, MongoDB, Redis (SSPL), Elasticsearch.
What "Open Source" Does NOT Mean
- Visible source code ≠ open source (you need an OSI-approved license)
- Open source ≠ free to use commercially (check the license)
- Open source ≠ no copyright (author retains copyright)
- No license ≠ public domain (all rights reserved by default)
Summary
MIT and Apache 2.0 are permissive — use in commercial projects freely, just include the copyright notice. GPL is strong copyleft — using GPL code requires open-sourcing your project. LGPL allows library use in proprietary software. AGPL extends GPL to SaaS. When choosing a license for your project, MIT is the simplest for maximum adoption; Apache 2.0 if patent protection matters; GPL if you want derivative works to stay open.