What is the difference between MIT and Apache 2.0?

Both are permissive, so people can use, modify and resell your code as long as they keep the notice. MIT is three short paragraphs and stops there. Apache 2.0 adds an explicit patent grant and a NOTICE requirement, which means a contributor cannot later sue users over a patent on code they contributed. If a company is involved or patents could matter, pick Apache. For a small library, MIT is shorter and just as friendly.

What is copyleft, and which licenses here use it?

Copyleft means anyone who distributes your code or a derivative must release their source under the same terms, so the freedom travels downstream. In this tool GPL-3.0 is strong copyleft, the whole program must stay GPL, and MPL-2.0 is weak copyleft at the file level, only changed files stay open. MIT, Apache, BSD, ISC and the Unlicense are permissive instead, so a closed product can include them freely. The badge on each license tells you which camp it is in.

How do I choose a license for my project?

Start from what you want others to be able to do. Want maximum adoption with no strings, pick MIT or ISC. Care about patents or shipping inside a company, pick Apache-2.0. Want every fork to stay open source, pick GPL-3.0. Want to give the code away with no rights at all, pick the Unlicense. The summary line and the Permissive or Copyleft badge in this tool exist exactly so you can compare these in a few seconds before generating the file.

What goes in the year and copyright holder fields?

The year is the year you first published the code, and it defaults to the current year. You can write a single year like 2026 or a range like 2021-2026 if the project spans several years. The holder is whoever owns the copyright, usually your full name like Jane Doe or your company like Globex Inc. For an example, MIT then reads Copyright (c) 2026 Jane Doe. Leave the holder blank and the file uses a clear placeholder you can fill in later.

Where do I put the LICENSE file in my repository?

Save it as a file named LICENSE, with no extension, in the root of your repository next to README. GitHub, GitLab and npm all detect that filename automatically and show the license badge on your project page. The Download button here writes exactly that filename. If you also want the license recognised in package metadata, add the SPDX id such as MIT or Apache-2.0 to the license field in package.json, Cargo.toml or your equivalent manifest.

Add a license to a brand-new repository

You just ran git init on a side project and GitHub keeps nagging that the repo has no license, which legally means nobody is allowed to use it. Pick MIT, type your name and the current year, hit Download, and drop the LICENSE file in the root. Two minutes later the project page shows a proper MIT badge and contributors know exactly what they can do with your code.

Compare permissive and copyleft before you commit

A teammate wants GPL so every fork stays open, you lean toward MIT for adoption. Instead of arguing from memory, click between the two in the tool and read the one-line summary and the Permissive or Copyleft badge side by side. The decision becomes concrete: GPL forces source release downstream, MIT does not, and you can settle it in the time it takes to skim two sentences.

Switch a company project to Apache 2.0 for patent safety

Legal asks you to move an internal tool from MIT to Apache-2.0 so the explicit patent grant protects the company. Select Apache-2.0, fill in the company name as the holder, set the year, and the generated file includes the full Apache text with the boilerplate appendix already filled. Replace the old LICENSE and the patent clause is in place.

Generate matching licenses across a multi-repo monorepo split

You are splitting one repo into five packages and each needs its own LICENSE with the same holder and year. Set the holder and year once, copy the URL, and reuse it for each package, changing only the license id if a package needs different terms. Every LICENSE comes out consistent and the share link documents exactly what you chose.

Open Source License Generator

Pick MIT, Apache, BSD, GPL and 4 more, fill in your name and year, get a ready-to-save LICENSE file. Browser-only.

Runs locally
Category Developer & DevOps
Best for Checking file type, size, metadata, and obvious mismatch signals before sharing.

License

MIT LicensePermissive

Permissive — short, do-anything license; keep the copyright notice. The default for most npm packages and small libraries.

LICENSE preview

MIT License

Copyright (c) 2026 <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

What this tool does

A LICENSE file generator for picking and writing the right open source license without leaving the browser. Choose from eight bundled licenses, each with the full canonical text on hand: MIT, Apache-2.0, BSD-3-Clause, BSD-2-Clause, ISC, Unlicense, MPL-2.0 and GPL-3.0. Every license carries a one-line plain-language summary plus a Permissive or Copyleft badge, so you decide which terms you actually want before you generate the file, not after. Type your copyright year, which defaults to the current year, and the name or organisation that holds copyright, and the preview fills both placeholders live. The long licenses keep their full legal text in a collapsible panel so the page stays readable. Copy gives you a paste-ready file and Download writes a plain LICENSE you can drop in your repo root. The license id, year and holder are encoded in the URL, so a share link reopens the exact same file. Everything runs client-side; the license texts are static data shipped with the page and nothing you type is uploaded.

Tool details

Input: Numbers; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy + Download; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 14 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Developer & DevOps · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How Open Source License Generator fits into your work

Use it before upload, handoff, archive, support review, or any moment where a file needs one local check before it leaves your machine.

File jobs

Checking file type, size, metadata, and obvious mismatch signals before sharing.
Preparing mixed folders for upload, archive, intake, or review.
Keeping sensitive files in the browser instead of sending them to an account-based service.

File checks

Do not treat the extension alone as proof of the real file type.
Review metadata before a file goes to customers, vendors, or a public page.
Keep the original file until the copied, converted, or exported result is verified.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Add a license to a brand-new repository
You just ran git init on a side project and GitHub keeps nagging that the repo has no license, which legally means nobody is allowed to use it. Pick MIT, type your name and the current year, hit Download, and drop the LICENSE file in the root. Two minutes later the project page shows a proper MIT badge and contributors know exactly what they can do with your code.
Compare permissive and copyleft before you commit
A teammate wants GPL so every fork stays open, you lean toward MIT for adoption. Instead of arguing from memory, click between the two in the tool and read the one-line summary and the Permissive or Copyleft badge side by side. The decision becomes concrete: GPL forces source release downstream, MIT does not, and you can settle it in the time it takes to skim two sentences.
Switch a company project to Apache 2.0 for patent safety
Legal asks you to move an internal tool from MIT to Apache-2.0 so the explicit patent grant protects the company. Select Apache-2.0, fill in the company name as the holder, set the year, and the generated file includes the full Apache text with the boilerplate appendix already filled. Replace the old LICENSE and the patent clause is in place.
Generate matching licenses across a multi-repo monorepo split
You are splitting one repo into five packages and each needs its own LICENSE with the same holder and year. Set the holder and year once, copy the URL, and reuse it for each package, changing only the license id if a package needs different terms. Every LICENSE comes out consistent and the share link documents exactly what you chose.

Common pitfalls

Shipping a repo with no LICENSE at all. With no license, default copyright law applies and nobody may legally copy, modify or distribute your code, even on a public GitHub repo. Generate any license and commit it before you invite contributors.
Naming the file wrong. GitHub and npm only auto-detect a file literally named LICENSE or LICENSE.md in the repo root. A file called license.txt in a docs folder will not show the license badge or be picked up by tooling.
Mixing a copyleft dependency into a permissive project without checking. If you pull in GPL code, your project may be forced to become GPL too. Read the badge in this tool, and confirm your dependencies' licenses are compatible before you publish.

Privacy

The license texts are static data bundled with this page, and the substitution of your year and holder is plain JavaScript running in your browser tab. Nothing you type is uploaded and there is no logging of the name you enter. The one caveat: the share link encodes the license id, year and holder in the query string, so a link pasted into chat records that name in the recipient server's access log. If the holder name is sensitive, use the copy or download button and share the file directly rather than the URL.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

Open Source License Generator

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How Open Source License Generator fits into your work

File jobs

File checks

Good next steps

Real-world use cases

Add a license to a brand-new repository

Compare permissive and copyleft before you commit

Switch a company project to Apache 2.0 for patent safety

Generate matching licenses across a multi-repo monorepo split

Common pitfalls

Privacy

FAQ

.gitignore Generator

.editorconfig Generator

Conventional Commit Generator

JSON Formatter & Validator

AI Eval Planner

API Key Generator

ASCII Table Generator

ASCII Table Reference

awk + sed Cheatsheet

AWS CLI Cheatsheet

Backup Codes Generator

Barcode Generator