Open Source License Generator

The right license, in its exact official words.

  • Exact official texts
  • SPDX headers
  • Files in a ZIP
A sheet of white paper with two ribbon seals lying on a wooden desk between an open laptop and a small brass balance scale.

The guide

A software license is a short text that only works when every word of it is the published one

Code without a license is closed by default. Opening it takes a few hundred words that someone else wrote, copied exactly, plus one honest line about who holds the copyright.

  • 14 licenses compared here, from MIT to the GNU Affero GPL
  • 2 placeholders in the MIT text: the year and the copyright holders
  • 1,078 bytes the whole MIT License as SPDX stores it
  • 35,149 bytes the GNU GPL version 3 as gnu.org publishes it
  • GPL-3.0-or-later one of the two identifiers the same GPL text can carry
Read the full guide Fold the guide 6 min · 20 sources

Publishing code is not the same as letting people use it. That surprises almost everyone the first time.

GitHub’s own documentation says it plainly: nobody is obliged to choose a license, but without one the default copyright laws apply, the author retains all rights, and no one may reproduce, distribute or create derivative works from the code. The page that Choose a License keeps for this case adds a twist. Once a project has other contributors, each of them is a copyright holder too, and the “nobody” who may reuse the work starts to include the person who began it.

So a license is a grant, not a restriction. It is a few paragraphs, written long ago by somebody else, in which the copyright holder tells the world what it may now do and on what conditions. The interesting questions are how much it grants, what it asks back, and whether the words in the file are really the words of the license.

Permission with strings, or permission that travels

The shortest licenses ask for almost nothing. The MIT License grants permission to use, copy, modify, merge, publish, distribute, sublicense and sell, and its one condition is that the copyright notice and the permission notice be included in all copies or substantial portions of the software. The BSD and ISC licenses work the same way in slightly different words. These are usually called permissive.

Copyleft licenses add a condition that follows the code. Mozilla’s FAQ places its own license on a spectrum with unusual candor: the Mozilla Public License sits between the Apache license, which does not require modifications to be shared, and the GNU family, which requires modifications to be shared under a much broader set of circumstances. Mozilla calls its version file-level copyleft. Change a covered file and that file stays under the license, while files you add beside it may carry other terms, open or proprietary.

The GNU General Public License reaches further, to works based on the program as a whole. The Affero variant reaches further still. Its how-to page asks that a program which interacts with users over a network offer its source to those users, for instance through a link in the interface of a web application.

None of this makes one end of the spectrum the correct one. A permissive license optimizes for adoption anywhere, including inside closed products. A copyleft license optimizes for keeping later versions open. Both are deliberate designs, and the same author can reasonably pick differently for different projects.

Patents, libraries and giving it all away

Copyright is only one of the rights a piece of software can touch. Apache License 2.0 spends a full section on another: each contributor grants a perpetual, worldwide, royalty-free patent license covering the claims their contribution necessarily infringes, and that license terminates for anyone who files a patent suit alleging the work infringes. The MIT text never mentions patents at all. Whether that silence matters is exactly the sort of question a license chooser should surface instead of deciding for you.

Libraries raise a narrower question. The Free Software Foundation describes the choice in a single sentence: using the Lesser GPL permits use of the library in proprietary programs, while using the ordinary GPL for a library makes it available only for free programs. The foundation argues for the ordinary GPL in an article whose title tells you not to use the Lesser GPL for your next library. It also concedes the opposite case, where a library’s features are readily available elsewhere and the weaker license loses nothing.

At the far end are texts that try to give up copyright entirely. The Unlicense describes itself as a template for disclaiming copyright interest in software you have written, a dedication to the public domain joined to a warranty disclaimer. CC0 from Creative Commons is a public domain dedication as well. Creative Commons even publishes the legal code of its own licenses and of CC0 under CC0, so that anyone may reuse those texts for any purpose.

Three stacks make these differences visible at a glance: what a license lets people do, what it requires of them, and what it withholds. On the rule lists that Choose a License publishes, MIT shows four permissions, one condition and two limitations. The GPL version 3 shows five, four and two.

Why the text has to be exact

A license is not a description of terms. It is the terms. Paraphrase it, tidy its punctuation or reconstruct it from memory and you have written a new document that no court, company lawyer or package registry has seen before.

The stewards know this. Every GNU license opens by saying that everyone is permitted to copy and distribute verbatim copies of the license document, but changing it is not allowed. The Apache Software Foundation answers the same question in its FAQ: you may reuse the license unchanged, and if you modify it the result is not the Apache License and may not use the name.

Exact also means current, and here even careful sources drift. The GPL version 2 on gnu.org today ends its sample notice by pointing readers to a web address. The copy of the same license in the SPDX data files still tells them to write to a street address in Boston. Neither is a forgery. One is simply an older printing, and a project that wants the steward’s present wording has to fetch it from the steward.

Length is no guide to care. The MIT License as SPDX stores it is 1,078 bytes. The GPL version 3 as gnu.org publishes it is 35,149 bytes. Both must arrive in your repository unaltered.

Filling in only what is meant to be filled

Most of a license is not yours to edit, but a few words are waiting for you. The MIT text has exactly 2 placeholders, a year and the copyright holders. Take the SPDX text, type 2026 and Ada Lovelace, and the third line becomes “Copyright (c) 2026 Ada Lovelace”. Nothing else moves. The file shrinks from 1,078 bytes to 1,069, because the two bracketed labels were longer than what replaced them.

The longer licenses work differently, and the difference trips people up. The GNU texts contain no blanks to fill. Their closing section, on how to apply the terms to new programs, tells you to attach a notice to the start of each source file, with a copyright line and a statement of copying permission, and the license file itself stays untouched. Apache 2.0 follows the same pattern with a boilerplate notice in its appendix, where the fields in square brackets are replaced and the brackets dropped. The FSF’s guide adds one more step for the Lesser GPL: ship the GPL beside it, since the lesser license is a set of additional permissions on top of the GPL.

Long notices at the top of every file are hard for software to parse, which is why SPDX defined short identifiers. One comment line, written as SPDX-License-Identifier followed by a name from the SPDX License List, states the license of a file in a form that a search tool can find.

The identifiers also force a decision that prose tends to blur. The GNU licenses let an author offer the code under one version only, or under that version or any later one, and the Free Software Foundation asks people to stop writing the ambiguous short form. The same license text therefore travels under two names, such as GPL-3.0-only and GPL-3.0-or-later, and the choice between them is stated in the notice, not in the license file.

Package manifests have converged on the same vocabulary. The npm documentation asks for a current SPDX identifier in the license field of package.json. The Python packaging specification now defines the license key as a string holding an SPDX expression, and it marks the older table form as legacy, deprecated in favor of the string. Cargo’s reference says crates.io reads its license field as an SPDX expression too.

What a license leaves out

A license settles less than its length suggests. Apache 2.0 states that it grants no permission to use the licensor’s trade names or trademarks, and it says that contributions submitted to a project come under the same license unless the contributor states otherwise. Most short licenses say nothing on either point. A project’s name, its logo and the terms on which it accepts patches may each need their own answer.

A comparison grid cannot supply those answers, and neither can this page. It can show what 14 licenses say they allow, require and withhold, and it can hand over the published words without a character changed. It cannot tell you how a clause applies to your product, your employer or your country. That takes a person who is allowed to give legal advice.

Sources

Every source consulted for this guide. Links checked October 5, 2026.

  1. No License Choose a License, GitHub, Inc.
  2. Licensing a repository GitHub Docs
  3. The MIT License Open Source Initiative
  4. MIT License Choose a License, GitHub, Inc.
  5. GNU General Public License v3.0 Choose a License, GitHub, Inc.
  6. Apache License, Version 2.0, January 2004 The Apache Software Foundation
  7. Apache Licensing and Distribution FAQ The Apache Software Foundation
  8. MPL 2.0 FAQ Mozilla
  9. GNU General Public License, Version 3, 29 June 2007 Free Software Foundation
  10. GNU General Public License, Version 2, June 1991 Free Software Foundation
  11. How to Use GNU Licenses for Your Own Software GNU Project, Free Software Foundation
  12. Don't Say "Licensed under GNU GPL 2"! Richard Stallman, GNU Project, Free Software Foundation
  13. Why you shouldn't use the Lesser GPL for your next library GNU Project, Free Software Foundation
  14. Unlicense Yourself: Set Your Code Free Unlicense.org
  15. Policies Creative Commons
  16. Handling License Info SPDX, The Linux Foundation
  17. License List Data SPDX license-list-data repository, GitHub
  18. package.json npm Docs
  19. pyproject.toml specification Python Packaging User Guide, Python Packaging Authority
  20. The Manifest Format The Cargo Book, The Rust Project