What is the difference between permissive and copyleft licenses?

Permissive licenses (MIT, BSD, Apache 2.0) let you reuse the code in almost any project, including proprietary ones, as long as you keep the copyright and license notice. Copyleft licenses (GPL, AGPL, and weakly LGPL/MPL) require that derivative works are released under the same license, keeping the code open.

What does the Apache 2.0 patent grant add over MIT?

Apache 2.0 includes an explicit patent licence from contributors and a patent-retaliation clause: if you sue a contributor over patents in the work, your patent rights terminate. MIT has no express patent grant, relying only on an implied licence, so Apache 2.0 gives downstream users stronger patent certainty.

What makes the AGPL different from the GPL?

The AGPL closes the 'SaaS loophole'. Under the GPL, you only trigger source-disclosure obligations when you distribute the software. The AGPL also triggers them when users interact with the software over a network, so running modified AGPL code as a web service requires you to offer that modified source.

Are LGPL and MPL strong copyleft?

No, they are weak copyleft. The LGPL lets you link the library into proprietary software as long as the LGPL parts stay replaceable and their source is available. MPL 2.0 applies copyleft per file, so you must share changes to MPL-covered files but can combine them with proprietary code in other files.

Does this reference send anything to a server?

No. The comparison table and filter run entirely in your browser using JavaScript. Nothing you type is uploaded, logged or stored.

What is the Open Source License Reference?

Reference comparing major open-source licenses — MIT, BSD, Apache 2.0, MPL 2.0, LGPL, GPL 2/3 and AGPL — by permissive vs copyleft type, patent grant, and what you must disclose when you distribute. It runs free in your browser on Gera Tools, with nothing uploaded.

Open Source License Reference

Name: Open Source License Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Comparing the major open-source licenses

Open-source licenses fall on a spectrum from permissive (do almost anything, just keep the notice) to strong copyleft (derivatives must stay open under the same terms). Choosing or complying with one comes down to three questions: can you use it in proprietary code, does it grant patents, and what must you disclose when you distribute. This reference compares the licenses you will meet most often.

License spectrum at a glance

License	Type	Proprietary use?	Patent grant?	Key obligation
MIT	Permissive	Yes	Implied only	Keep notice
BSD 2/3-clause	Permissive	Yes	Implied only	Keep notice; BSD-3 adds no-endorsement clause
Apache 2.0	Permissive	Yes	Explicit + retaliation	Keep notice; state changes
MPL 2.0	Weak copyleft	Yes (mixed files)	Explicit	Share modified MPL files
LGPL 2.1/3	Weak copyleft	Yes (dynamic link)	Yes (LGPL-3)	Keep library replaceable; share library source
GPLv2	Strong copyleft	No	None	Distribute source of whole derivative
GPLv3	Strong copyleft	No	Explicit + tivoization	Distribute source + installation info
AGPLv3	Network copyleft	No	Explicit	Distribute source for networked use too

How it works

Each license sets conditions that attach when you distribute (and, for AGPL, when you serve over a network). Permissive licenses — MIT, BSD, Apache 2.0 — only ask you to preserve the copyright and licence text; Apache 2.0 adds an express patent grant. Weak copyleft — LGPL (library linking) and MPL 2.0 (per-file) — keeps the licensed parts open while allowing proprietary combination. Strong copyleft — GPLv2, GPLv3, AGPLv3 — requires the whole derivative work to be released under the same licence, with AGPL extending that to networked use. GPLv3 and Apache 2.0 are compatible one way; GPLv2-only and Apache 2.0 are not — a common trap when combining packages.

Compatibility traps

GPLv2-only + Apache 2.0 is the most common problem in practice. The Apache 2.0 patent retaliation clause imposes extra restrictions beyond what GPLv2 allows, so combining them in a single binary is not permitted under GPLv2-only. If you need to combine Apache 2.0 code with a GPL project, the project must use GPLv3 or include the “or later” clause that allows it.

AGPL and SaaS is the second common surprise. Developers who run modified GPL code in a cloud service without distributing binaries believed they were safe from source disclosure — the “SaaS loophole.” AGPL was specifically designed to close that loophole.

Choosing a license for your project

Maximizing adoption: MIT or Apache 2.0 — both let companies use the code in proprietary products without worry.
Wanting a patent grant: Apache 2.0 adds an explicit patent licence and a retaliation clause that MIT lacks.
Keeping the library open while allowing proprietary apps: LGPL or MPL 2.0.
Ensuring all derivative work stays open: GPL (for desktop/server binaries) or AGPL (for SaaS).
Keep the LICENSE file and every copyright notice intact in every distribution — that is the minimum obligation for all permissive licenses and a legal requirement for copyleft ones.