Open Source License Generator

Pick MIT, Apache 2.0, GPL, BSD, MPL, or public-domain. Fill author and year. Get the LICENSE file.

License

The most-used permissive license. Almost no restrictions — keep the copyright notice and you're done. Default for most small open-source projects.

Author / copyright holder
Year
LICENSE · 22 lines
MIT License

Copyright (c) 2026 Your Name

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.

01 — Overview

How the Open Source License Generator works

Generate a complete LICENSE file for your open-source project. Choose from the most-used OSI-approved licenses (and a couple of public-domain options), fill in the author and copyright year, and copy or download. Each license includes a short rationale so you can pick with confidence.

02 — Use cases

When to use the Open Source License Generator

  1. 01

    Bootstrap a new repo with a license in 30 seconds

  2. 02

    Re-license a project — generate the canonical text without copy-paste errors

  3. 03

    Get the right author + year format for your jurisdiction

  4. 04

    Decide between MIT and Apache 2.0 with quick guidance

03 — Examples

Open Source License Generator examples

MIT, Jane Doe, 2025

ex 01

MIT License\n\nCopyright (c) 2025 Jane Doe\n\nPermission is hereby granted...

The most-used permissive license for small projects.

Apache-2.0, Acme Corp, 2025

ex 02

Apache License\nVersion 2.0, January 2004...

Permissive with explicit patent grant — good for companies.

GPL-3.0, Jane Doe, 2026

ex 03

GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007…

Strong copyleft — derivative works must also be GPL-licensed.

CC0-1.0, Acme Corp, 2026

ex 04

CC0 1.0 Universal Statement of Purpose…

As close to public domain as a license can get, for data and assets rather than code.

04 — FAQ

License — frequently asked questions

MIT or Apache 2.0?

Both are permissive. MIT is shorter and more famous. Apache 2.0 adds an explicit patent grant and requires changes to attributed files to be marked — preferred for corporate-backed projects and anything that ships in a product with patent risk.

What's the difference between BSD-2 and BSD-3?

BSD-3 adds a 'no endorsement' clause — you can't use the author's name to promote derivative works without permission. BSD-2 is otherwise identical. For most projects, MIT covers the same ground more concisely.

When should I pick GPL?

GPL-3.0 is copyleft — derivative works must also be GPL. Pick it when you want to ensure forks stay open. Avoid it if you want your code embedded in commercial closed-source products.

Is Unlicense the same as CC0?

Both put work in the public domain. CC0 has stronger international legal standing — it's drafted to handle jurisdictions where pure public-domain dedication is hard. Unlicense is shorter and equally common in the dev world.

Where does the file go and what should it be called?

LICENSE in the repository root, with no file extension. GitHub, npm, pkg.go.dev, and most package registries look for exactly that and will surface the license in the UI when they find it. LICENSE.md works too, though a plain LICENSE is the safer default for tooling that does an exact match.

Do I need a license header in every source file?

Apache-2.0 recommends one and includes the boilerplate to use; MIT doesn't require it. Headers help when files get copied out of the project and separated from the LICENSE file, which happens more than you'd like. Set the SPDX identifier in your package metadata either way — that's what automated tooling actually reads.

05 — Reference

Specs and further reading

The primary sources this tool follows. Where behaviour is defined by a specification, we link the specification rather than a summary of it.

  • SPDX License List

    Linux Foundation — The canonical identifiers used in package metadata and the license field.

  • OSI Approved Licenses

    Open Source Initiative — Which licenses meet the Open Source Definition, and the approval process behind them.

  • Choose an open source license

    GitHub — A plain-language comparison of the permissions and conditions of each license.

07 — More

Tools that pair with License

Last updated .