Software Licensing 101: GPL vs MIT (and More) in 2026

Understand open-source software licenses in 2026 — GPL, MIT, Apache, BSD and more. Learn what each license allows, requires, and how to choose the right one for your project.

Software licensing comparison document concept
Last updated: April 1, 2026

Licensing Isn't Optional

Every piece of software you download, fork, or bundle into your project comes with a license. If there's no license file, that doesn't mean "free to use" — it means "all rights reserved" by default. Most developers learn this the hard way when legal sends an email asking why there's GPL code in a proprietary product.

Open-source licenses exist to give you explicit permissions. But the permissions vary enormously. Some licenses let you do almost anything. Others require you to share your own code if you use theirs. Getting this wrong can mean rewriting large chunks of a project, pulling a product from distribution, or having an uncomfortable conversation with your company's lawyers.

This guide covers the licenses you'll actually encounter in 2026. No legalese, no abstract philosophy — just what each license lets you do, what it requires, and how to pick one.

The Major Open-Source Licenses

There are dozens of OSI-approved licenses, but in practice about five or six cover the vast majority of projects you'll interact with. Let's go through them.

MIT License

The MIT License is the most popular open-source license by volume. It's short — about 170 words — and extremely permissive. You can use, copy, modify, merge, publish, distribute, sublicense, and sell the software. The only requirement is that you include the original copyright notice and the license text in any copies or substantial portions of the software.

That's it. No requirement to share your modifications. No requirement to keep your project open-source. You can take MIT-licensed code, put it in a proprietary product, and sell it. The author just wants credit.

Used by: React, jQuery, Rails, Node.js, .NET (runtime), Vue.js, Angular.

Apache License 2.0

Apache 2.0 is similar to MIT in its permissiveness, but it adds two important things: an explicit patent grant, and a requirement to document changes. When someone contributes code under Apache 2.0, they're also granting you a license to any patents that cover that code. This matters for enterprise software where patent disputes are a real risk.

You must include the license, a NOTICE file if one exists, and state any changes you've made to the original files. You can still use Apache-licensed code in proprietary projects.

Used by: Android (AOSP), Kubernetes, TensorFlow, Apache HTTP Server, Swift.

BSD Licenses (2-Clause and 3-Clause)

The BSD licenses are close cousins of MIT. The 2-Clause BSD ("Simplified") is essentially identical to MIT in practice — include the copyright notice and license text, do what you want. The 3-Clause BSD ("New" or "Modified") adds one restriction: you can't use the name of the original project or its contributors to endorse or promote your derivative product without permission.

There's also a historical 4-Clause BSD that required an advertising clause, but it's considered obsolete and you shouldn't use it for new projects.

Used by: FreeBSD, Django, Flask, Nginx (historically), many academic projects.

GPL (GNU General Public License) v2 and v3

The GPL is the license that scares corporate lawyers — and for good reason, if you don't understand it. The GPL is a copyleft license. It says: you can use, modify, and distribute this software, but if you distribute a modified version (or a program that links to GPL code), you must also release your source code under the GPL.

This is the key difference. MIT says "do what you want, just give credit." GPL says "you can use this, but if you share the result, you have to share the source too."

GPLv3 (released in 2007) added protections against "tivoization" — the practice of putting GPL software on hardware that prevents users from running modified versions. It also has stronger patent provisions than GPLv2.

Used by: Linux kernel (GPLv2), WordPress, GIMP, GCC, Bash, MariaDB.

LGPL (Lesser GPL)

The LGPL is a compromise. It allows proprietary software to link to LGPL libraries without triggering the copyleft requirement. If you modify the LGPL library itself, you must share those modifications. But your own application code stays private.

This makes LGPL popular for shared libraries. You can use glibc or Qt (LGPL version) in a commercial product without open-sourcing your entire application — you just can't modify those libraries and keep the modifications private.

Used by: glibc, Qt (partially), FFmpeg (some components), GNU Classpath.

AGPL (Affero GPL)

The AGPL closes the "SaaS loophole" in the GPL. Regular GPL only triggers its copyleft requirement when you distribute software. If you run modified GPL code as a web service, you're not distributing binaries, so technically you don't have to share your changes. The AGPL says: if users interact with the software over a network, that counts as distribution, and you must provide source code.

Used by: MongoDB (pre-SSPL switch), Nextcloud, Grafana (partially), some SaaS tools.

License Comparison Table

LicenseCommercial UseModificationDistributionMust Share SourcePatent Grant
MIT✅ Yes✅ Yes✅ Yes❌ No❌ No (implicit)
Apache 2.0✅ Yes✅ Yes✅ Yes❌ No✅ Yes
BSD 2-Clause✅ Yes✅ Yes✅ Yes❌ No❌ No
BSD 3-Clause✅ Yes✅ Yes✅ Yes❌ No❌ No
GPLv2✅ Yes✅ Yes✅ Yes✅ Yes (copyleft)❌ Implicit
GPLv3✅ Yes✅ Yes✅ Yes✅ Yes (copyleft)✅ Yes
LGPL✅ Yes✅ Yes✅ Yes⚠️ Library mods onlyVaries by version
AGPL✅ Yes✅ Yes✅ Yes✅ Yes (network use too)✅ Yes (v3)

Note: "Commercial Use" means you can use the software commercially — but some licenses (GPL, AGPL) may require you to release your code in turn.

Copyleft vs. Permissive: The Core Split

Every open-source license falls into one of two camps:

  • Permissive (MIT, Apache, BSD): Do what you want. Include the license. No obligation to share your source code.
  • Copyleft (GPL, LGPL, AGPL): You can use and modify the software, but if you distribute or deploy the result, you must make your source available under the same license.

Neither is inherently better. Permissive licenses maximize adoption — anyone can use the code, including companies building proprietary products. Copyleft licenses maximize openness — any improvements must flow back to the community. Your choice depends on what you value more.

How to Choose a License for Your Project

If you're publishing your own code, here's a practical decision framework:

  1. Do you want maximum adoption with minimal friction? → MIT. It's the default choice for libraries and tools where you want the widest possible use.
  2. Do you want permissive terms but need patent protection? → Apache 2.0. Important for enterprise projects or anything involving patentable technology.
  3. Do you want to ensure all derivatives stay open-source? → GPLv3. Prevents companies from taking your work, improving it, and keeping the improvements private.
  4. Building a library that proprietary apps should be able to use? → LGPL. Allows linking without copyleft, but modifications to your library itself stay open.
  5. Building a web service or SaaS tool? → Consider AGPL if you want to prevent someone from running your code as a service without contributing back.
  6. Is it a small script, snippet, or example code? → MIT or even public domain (CC0, Unlicense) if you truly don't care about attribution.

License Compatibility: The Hidden Trap

You can't always combine code under different licenses. The most common headache: GPL and MIT code can be combined (the result is GPL), but GPLv2-only and Apache 2.0 are incompatible. GPLv3 fixed this specific conflict, but compatibility still trips people up.

A few rules of thumb:

  • Permissive + Permissive = Almost always fine. Use the most restrictive of the bunch.
  • Permissive + Copyleft = Usually fine. The combined work becomes copyleft.
  • Copyleft + Different Copyleft = Often incompatible. GPLv2-only and GPLv3-only can't be combined.
  • When in doubt, check the FSF's license compatibility chart or consult someone who deals with this professionally.

Practical Advice for 2026

A few things that matter right now:

  • AI-generated code and licensing. If an AI model was trained on GPL code and outputs something substantially similar, is that output GPL-encumbered? This is an active legal question in 2026 with no clear court precedent. Be cautious — if you're using AI coding tools, check what your company's legal team says about the output's license status.
  • SBOMs are becoming mandatory. Software Bills of Materials (SBOMs) are required in US federal procurement and increasingly expected in EU markets. You need to know every dependency's license, not just your own. Tools like SPDX and CycloneDX can automate this.
  • License scanning in CI/CD. Tools like FOSSA, Snyk, and FOSSology can flag license conflicts automatically in your build pipeline. If you're shipping software, this should be part of your process, not a manual review done once a year.
  • The "source-available" trend. Some companies (Elastic, HashiCorp, MongoDB) have moved from traditional open-source licenses to custom "source-available" licenses like SSPL or BSL. These let you read and self-host the code but restrict commercial SaaS use. They're not OSI-approved, and the community debate is ongoing.

What to Check When You Download Software

Whether you're grabbing a library from npm, downloading a desktop app from our downloads page, or pulling from the French-language downloads section, here's what to look for:

  • Check the LICENSE or COPYING file in the repository root.
  • Look for an SPDX identifier in package.json, pyproject.toml, or the equivalent metadata file.
  • If the license is GPL or AGPL, understand whether that affects your ability to use it in your project.
  • If there's no license file at all, do not assume it's free to use. Contact the author or find an alternative.

Related Resources

Frequently Asked Questions