Open Source Licenses Explained: The Good, The Bad, and The 'Wait, Can I Actually Use This?'

Source: Dev.to

Introduction

You’ve built something cool and want to open‑source it. When you click “Choose a license” on GitHub you’re faced with a wall of options: MIT, Apache 2.0, GPL v3, AGPL, BSD, MPL, ISC, Unlicense, and more. It can feel overwhelming, especially if all you want is for people to use your code.

Below is a plain‑English guide to the most common open‑source licenses, what they actually allow, and when each one makes sense.

---

The spectrum: permissive ↔ copyleft

Permissive  ←--------------------------→  Copyleft
(do whatever)                         (share improvements)

MIT / BSD → Apache 2.0 → MPL → LGPL → GPL → AGPL

• Permissive licenses let you do almost anything with the code, even incorporate it into proprietary products.
• Copyleft licenses require that modifications be released under the same license, ensuring improvements stay open.

---

License breakdown

MIT (and BSD‑style)

What it says (simplified)

“Use this code however you want. Just keep my copyright notice. I’m not responsible if it breaks.”

Key points

• Commercial use, modification, distribution, sublicensing are all allowed.
• No requirement to share changes.
• Very short and widely understood.

Typical projects
React (originally BSD‑style), Node.js, jQuery, Tailwind CSS.

When to choose it

• You want maximum adoption.
• You don’t mind companies profiting from your work.
• You need a simple, permissive license.

---

Apache 2.0

What it adds over MIT

• Patent protection – contributors grant a perpetual, worldwide, royalty‑free patent license.
• Trademark protection – the project name can’t be used for endorsement without permission.

Example clause (patent grant)

3. Grant of Patent License.  Each Contributor hereby grants to You a
   perpetual, worldwide, non‑exclusive, no‑charge, royalty‑free patent
   license to make, use, sell, offer for sale, import, and otherwise
   transfer the Work, where such license applies only to those patent
   claims licensable by such Contributor that are necessarily infringed
   by their Contribution(s) alone or by combination of their
   Contribution(s) with the Work to which such Contribution(s) was
   submitted.

Typical projects
Kubernetes, TensorFlow, Android, Swift.

When to choose it

• You hold patents or may file patents.
• You want contributors protected from patent trolls.
• You’re building infrastructure where patent risk is a concern.

---

BSD (2‑clause / 3‑clause)

What it says – almost identical to MIT, but adds a clause preventing the use of the author’s name to endorse derived works.

Example clause (endorsement)

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived
   from this software without specific prior written permission.

Typical projects
FreeBSD, OpenBSD, nginx.

When to choose it

• Same goals as MIT, but you want to avoid “endorsement confusion”.

---

GPL v3 (General Public License)

What it says (simplified)

• You can use, modify, and distribute the software.
• If you distribute a modified version, you must release the source under GPL v3 as well.
• You must provide installation instructions for compiled binaries.

Typical projects
Linux kernel, Git, WordPress, GIMP.

When to choose it

• You believe in the free‑software philosophy.
• You want improvements contributed back.
• You’re okay with the “viral” nature that can deter proprietary use.

Gotcha: SaaS providers can avoid sharing changes because they don’t distribute the software—only run it on their servers.

---

AGPL v3 (Affero GPL)

What it adds – if users interact with the software over a network, you must also share the source of your modifications.

Typical projects
MongoDB (originally AGPL), Grafana, GitLab CE, Mastodon, Nextcloud.

When to choose it

• You’re building a database, backend service, or other infrastructure.
• You want to prevent cloud providers from “strip‑mining” your work.
• You’re willing to limit commercial adoption.

---

LGPL v2.1 / v3 (Lesser GPL)

What it says – you may link to the library from proprietary software, but any modifications to the library itself must be released under LGPL.

Typical projects
Qt, FFmpeg, GStreamer.

When to choose it

• You’re publishing a library that you want others (including proprietary apps) to use.
• You still want improvements to the library itself to stay open.

---

MPL 2.0 (Mozilla Public License)

What it says – copyleft applies per file. Modified files must stay under MPL, but you can add new files under any license.

Typical projects
Firefox, Thunderbird, LibreOffice.

When to choose it

• You want a middle ground between permissive and strong copyleft.
• You’re comfortable with a mixed‑license codebase.

---

Unlicense (public domain)

What it says – “This is public domain. Do absolutely anything with it. I waive all rights.”

Typical use cases – tiny utilities, educational examples.

Caveat – some jurisdictions don’t allow a full waiver of copyright, so the Unlicense may not be legally enforceable everywhere. MIT is a safer alternative with essentially the same effect.

---

Choosing a license – decision tree

├─ "I want maximum adoption"
│   └─ MIT or Apache 2.0
│
├─ "I want improvements shared back"
│   ├─ Library → LGPL or MPL
│   ├─ Application / Service → GPL
│   └─ SaaS → AGPL
│
├─ "I want to prevent cloud giants from profiting"
│   └─ AGPL
│
└─ "I don’t care at all"
    └─ MIT or Unlicense

---

Compatibility matrix

Rule of thumb

• Permissive licenses (MIT, Apache) can be combined with any other license.
• GPL “infects” the entire project—once you include GPL code, your whole distribution must be GPL.
• AGPL is the most restrictive; it adds the network‑use clause.

---

Real‑world pitfalls & lessons

1. No license = legal limbo

A developer released an npm package without a license. A startup used it, and when the developer sued, the court ruled that no license means “all rights reserved.” Neither side could enforce their claims.

Lesson: Always include a license; “no license” does not equal “free to use”.

2. Patent clauses can backfire

Facebook released React under a BSD‑style license with a patent retaliation clause (“if you sue us for patents, you lose the React license”). Community backlash forced Facebook to re‑license React under MIT.

Lesson: Patent clauses are powerful but can alienate users.

3. Adding restrictive clauses mid‑project hurts adoption

Redis Labs added the “Commons Clause” (“you can’t sell this software”) to some modules. This violated the Open Source Definition, causing the community to fork the project (Valkey).

Lesson: Changing a license to a more restrictive one after release can fracture a community.

4. Cloud providers and AGPL

MongoDB’s AGPL allowed AWS to offer a compatible “DocumentDB” service without contributing back, prompting MongoDB to switch to the Server Side Public License (SSPL).

Lesson: Even AGPL may not stop large cloud providers from offering hosted versions; consider additional business models.

5. GPL and SaaS

Linksys shipped routers with a modified Linux kernel (GPL) but didn’t release the source. The GPL community sued, and Linksys was forced to comply, leading to community firmware projects like DD‑WRT and OpenWRT.

Lesson: GPL enforcement can compel source disclosure for distributed binaries, but not for pure SaaS.

---

Quick recommendations

---

Final checklist

1. Define your goals – adoption, contribution back, patent protection, preventing cloud exploitation.
2. Pick the simplest license that meets those goals – don’t over‑complicate.
3. Add a LICENSE file to the root of the repository.
4. Include a short header in each source file (e.g., “© 2025 Your Name – SPDX‑License‑Identifier: MIT”).
5. Document any additional policies (e.g., contribution guidelines, code of conduct).

With the right license, your project can thrive while you retain the level of control you’re comfortable with. Happy open‑sourcing!