License Generator

Next

Shipping a project without a LICENSE file technically means “all rights reserved”, nobody can reuse the code. This generator produces the full, unmodified text of the most popular open source licenses, with your name and the current year substituted into the copyright header. Paste it into a LICENSE file at the root of your repository and push.

How to pick and generate a license

  1. 1

    Choose a license

    MIT for permissive, Apache-2.0 for permissive + patent grant, GPLv3 for copyleft.

  2. 2

    Enter your name and year

    The copyright holder: your legal name or your company. Year is the first year of release.

  3. 3

    Review the full text

    The license text stays exactly as OSI / FSF publish it; only the copyright line changes.

  4. 4

    Drop it in LICENSE

    Save to the root of your repository. GitHub detects and displays it in the sidebar.

Choosing between the popular options

There is no universally “best” open source license. The choice depends on what you want downstream users to be able, and unable, to do.

License Type Patent grant Copyleft? Notable users
MIT Permissive Implicit No Rails, Node packages, jQuery
Apache-2.0 Permissive Explicit No Kubernetes, Android AOSP
BSD-3-Clause Permissive No No Go standard library, Nginx
GPL-3.0 Strong copyleft Yes Yes GCC, Bash, GIMP
LGPL-3.0 Weak copyleft Yes Partial glibc, Qt (historically)
MPL-2.0 Weak copyleft Yes Partial Firefox, Thunderbird
AGPL-3.0 Network copyleft Yes Yes MongoDB (pre-2018), Grafana
Unlicense / CC0 Public domain dedication - No Small utility libraries

The three practical questions

  1. Do you want closed-source forks? Permissive (MIT, Apache, BSD) → yes. Copyleft (GPL, AGPL) → no.

  2. Do you care about patent retaliation? Apache-2.0, GPLv3 and MPL-2.0 have explicit patent grants that terminate on litigation. MIT and BSD-2/3 do not.

  3. Does your code run as a network service? AGPL-3.0 closes the “SaaS loophole”, users of the service count as distribution. If that matters, choose it; otherwise GPLv3 is simpler.

Common mistakes to avoid

  • Don’t edit the license text. A “MIT-with-my-amendments” license is a new, incompatible license. Courts reject ad-hoc modifications.
  • Don’t use two licenses without understanding compatibility. Apache-2.0 and GPLv2 are not compatible; Apache-2.0 and GPLv3 are.
  • Don’t forget the SPDX identifier in source headers: SPDX-License-Identifier: MIT on line 1 helps tooling detect your choice.
  • Don’t use “Creative Commons” for software. CC licenses are for creative works; use them on documentation and images, not code.

Dual licensing

Some projects ship under two licenses, typically one copyleft, one commercial, so businesses can buy out of the copyleft terms. Qt and MySQL famously do this. It is legally complex; if you’re not monetising the project, stick with a single OSI-approved license.

Frequently Asked Questions

MIT is the most popular default for small open-source projects: short, permissive, widely understood, and compatible with virtually every other license. Apache-2.0 is a slightly safer choice if your project has any patentable novelty.

Yes. Without one, your code is fully copyrighted and nobody can legally reuse it, GitHub public access is not a license. Add a LICENSE file the same day you make the repo public.

The first year of release (single year) or a range ending in the current year (e.g. “2019-2026”). Updating the year each January is a courtesy, not a legal requirement in most jurisdictions.

No, the substitution happens in your browser and your name, year and choice of license are never sent to us.

Related Tools

Tool available in other languages