What is the difference between permissive and copyleft licenses?

Permissive licenses like MIT and Apache let others use, modify, and distribute your code with almost no obligations beyond keeping the notice. Copyleft licenses like GPL require derivative works to be released under the same license, keeping them open.

When should I choose Apache 2.0 over MIT?

Apache 2.0 is like MIT but adds an explicit patent grant and a requirement to state significant changes, which gives users patent protection. Choose it for larger projects or where patent clarity matters; MIT is simpler for small libraries.

What does GPL v3 require?

GPL v3 is a strong copyleft license. Anyone who distributes your code or a modified version must make the full source available under GPL v3, and cannot add restrictions. It protects software freedom but limits use in closed-source products.

LGPL is a weaker copyleft aimed at libraries. You can link the library into proprietary software without that software becoming GPL, but modifications to the library itself must stay open under LGPL.

Is the generated text legally valid?

The texts are the official, unmodified license texts with only the name and year placeholders filled in, which is exactly how they are meant to be applied. For high-stakes projects you should still confirm the choice with a lawyer.

What is the Open Source License Picker & Generator?

Compare MIT, Apache 2.0, GPL v3, LGPL v3, MPL 2.0, BSD 3-Clause, and ISC with a decision guide on permissions, conditions, and copyleft, then generate the full LICENSE text with your name and year filled in, ready to drop into your repository. It runs free in your browser on Gera Tools, with nothing uploaded.

Open Source License Picker & Generator

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

Choosing a software license decides how others may use your code. This tool compares the most common open-source licenses across permissions, conditions, and copyleft strength, then generates the full LICENSE text with your name and year filled in.

Why the license decision matters more than most developers realise

An unlicensed repository is not “open source by default” — legally, all rights are reserved, and no one has permission to use, copy, or distribute your code. Even for a personal project you post publicly, the absence of a license means other developers cannot safely incorporate your code into their projects. Picking any recognised open-source license is almost always better than picking none.

At the other end, choosing GPL when you meant MIT can prevent commercial adoption of your library. Companies routinely exclude GPL code from proprietary products not because of hostility but because the copyleft obligation to open-source derivatives is incompatible with their product model.

How it works

Each license falls on a spectrum from permissive to strong copyleft:

Permissive (MIT, BSD 3-Clause, ISC, Apache 2.0): use freely, just keep the notice. Apache 2.0 adds a patent grant.
Weak copyleft (MPL 2.0, LGPL v3): modifications to the licensed files stay open, but you can combine them with proprietary code.
Strong copyleft (GPL v3): any distributed derivative must be released under the same license.

The generator inserts your copyright holder name and the current year into the official, unmodified text — the standard, legally-meaningful way to apply a license.

Side-by-side comparison

License	Copyleft	Patent grant	Conditions
MIT	None	No	Keep copyright notice
ISC	None	No	Keep copyright notice (shorter text than MIT)
BSD 3-Clause	None	No	Keep notice; no endorsement using project name
Apache 2.0	None	Yes	Keep notice; document changes
MPL 2.0	File-level	Yes	Changed files stay MPL; can combine with proprietary
LGPL v3	Library-level	Yes	Library mods stay open; linking allowed in proprietary
GPL v3	Full	Yes	Distributed derivatives must be GPL v3 and open source

Decision guide by scenario

You want maximum adoption of your library. Use MIT or Apache 2.0. These are the most widely accepted licenses in the npm, PyPI, and Maven ecosystems. Apache 2.0 is preferable when your project could be used in environments where patents are a concern (for example, codec libraries, compression algorithms).

You are building a command-line tool and want to stay open. GPL v3 is the canonical choice. Anyone who distributes a modified version must release the source. This is how Linux, GCC, and many GNU tools are licensed.

You are writing a library you want used in both open and commercial projects. LGPL v3 (or MPL 2.0 for file-level copyleft) lets you keep the library open-source while allowing downstream proprietary applications to link against it without triggering the full copyleft.

You want to be truly maximally permissive with zero obligations. ISC is equivalent to MIT but shorter. Both are acceptable for tiny utilities and snippets. Some developers use the Unlicense or CC0 to explicitly disclaim copyright, but these have less legal clarity in some jurisdictions.

Corporate context. Apache 2.0 is almost universally accepted by corporate legal teams because of the explicit patent grant and the “document significant changes” requirement, which creates an audit trail. When contributing to an Apache Software Foundation project or a CNCF project, Apache 2.0 is typically required.

Practical tips

Name the file exactly LICENSE (no extension) at the repository root — GitHub, GitLab, and npm all detect this exact filename and display the license badge and type automatically.
The year in the copyright notice is the year of first publication, not the current year. If you update a multi-year project, some teams write 2019–2026 to cover the span.
Permissive licenses maximize adoption; copyleft licenses maximize software-freedom guarantees.
If your project depends on GPL libraries, you may be required to use GPL regardless of your preference — check your dependency licenses before deciding.