Developer

License Generator

Generate common OSS license templates with year and copyright holder.

Loading interactive tool…

Embed this tool on your site

About this tool

License Generator fills one of four templates — MIT, Apache-2.0, GPL-3.0 or BSD-3-Clause — with a copyright year and holder. MIT and BSD-3-Clause come out as the complete license text, ready to save as LICENSE. Apache-2.0 and GPL-3.0 come out as the short copyright notice that points to the full license, so you still need to add the full license text from apache.org or gnu.org to your repository. The year defaults to the current year. It produces a starting text only: the tool does not provide legal advice or choose a license for you, so read the terms and check your project's dependencies before publishing.

Why use it

  • No Leftover Placeholders: The year and copyright holder are written into the template for you, so the file never ships with a placeholder still in it.

  • Complete MIT and BSD Texts: MIT and BSD-3-Clause output is the full license text with your notice at the top, ready to commit as a LICENSE file.

  • Standard Apache and GPL Notices: Apache-2.0 and GPL-3.0 output is the copyright-plus-license notice those licenses ask you to place in your project or source files.

  • Permissive and Copyleft Options: MIT, Apache-2.0 and BSD-3-Clause are permissive, while GPL-3.0 is copyleft, so the four templates cover the most common open-source choices.

  • Runs in the Browser: The template is filled locally with no account and no upload.

How to use

  1. Pick MIT, Apache-2.0, GPL-3.0 or BSD-3-Clause from the License dropdown.
  2. Check the Year field, which defaults to the current year, and change it if needed.
  3. Enter your name or organisation in Author / Copyright holder.
  4. Click Generate to fill the template; if the year or holder is empty, the tool asks for both.
  5. Click Copy output. For MIT or BSD-3-Clause save it as LICENSE; for Apache-2.0 or GPL-3.0 use it as the notice and add the full license text separately.

When it helps

  • When initialising any new open source project before the first public commit
  • When a collaborator or company asks what license your project uses before contributing or integrating it
  • When moving a private project to public on GitHub and realising it has no LICENSE file
  • When creating a library intended for use in commercial products and needing to verify the license permits that
  • When your organisation requires Apache 2.0 specifically for patent protection clauses in corporate open source projects
  • When a pull request checklist on an open source project requires you to verify you understand the project's license before contributing

Examples

MIT License (first lines)

Input
License: MIT, Year: 2026, Author: Jane Smith
Expected result
MIT License

Copyright (c) 2026 Jane Smith

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

Apache-2.0 notice (complete output)

Input
License: Apache-2.0, Year: 2026, Author: Acme Corp
Expected result · Scroll for more
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

Copyright 2026 Acme Corp

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

BSD 3-Clause (first lines)

Input
License: BSD-3-Clause, Year: 2026, Author: Open University
Expected result
BSD 3-Clause License

Copyright (c) 2026, Open University
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

Tips

  • Add an SPDX identifier comment at the top of your main source files (e.g., // SPDX-License-Identifier: MIT) to make machine-readable license scanning tools work correctly across your codebase
  • If your project is a library meant for wide adoption including commercial use, MIT or Apache 2.0 are the safest choices — GPL will deter many potential users and integrators
  • Store the year as the year you first published the code, not the current year — copyright duration is measured from the original publication date
  • For corporate projects, confirm with your legal team before choosing Apache 2.0 since its explicit patent grant has specific implications for organisations with large patent portfolios
  • If you accept external contributions, consider whether you need a Contributor License Agreement (CLA) to preserve the right to relicense the project in the future without having to contact every contributor

Frequently Asked Questions

What is the difference between MIT and Apache 2.0?
Both are permissive licenses that allow commercial use, modification, and redistribution. Apache 2.0 additionally includes an explicit patent license grant and requires preservation of a NOTICE file if one exists, making it more suitable for projects where patent protection is a concern.
What does copyleft mean in the context of the GPL?
Copyleft requires that derivative works and software distributed with GPL-licensed code must also be released under the GPL. It ensures that software freedom propagates downstream. This is incompatible with proprietary software distribution.
Can I use MIT-licensed code in a GPL project?
Yes. MIT is compatible with GPL because MIT permits everything the GPL allows. The combined work must be distributed under the GPL. However, you cannot combine GPL v2 code with Apache 2.0 code due to patent clause incompatibilities.
Do I need a separate copyright notice in every source file?
It is best practice but not legally required for most licenses. The LICENSE file in the repository root establishes the license for the whole project. Some organisations add a brief SPDX identifier comment to each file as a machine-readable reference.
What is the Unlicense and when should I use it?
The Unlicense is a public domain dedication template that waives all copyright claims to the extent permitted by law. Use it when you genuinely want no restrictions on use, attribution, or distribution whatsoever, though note that public domain is not uniformly recognised in all jurisdictions.
Should I use GPL v2 or GPL v3?
GPL v3 closes legal loopholes present in v2, includes anti-tivoization protections, and is incompatible with Apache 2.0. GPL v2 remains widely used (the Linux kernel uses it). Choose v3 for new projects unless you have a specific reason to target v2 compatibility.
What is the LGPL designed for?
The GNU Lesser GPL is designed for libraries. It allows proprietary software to link against an LGPL library without the full GPL copyleft applying to the proprietary code, making it a common choice for open source libraries intended for broad adoption including commercial use.
Can I change the license of my project later?
Yes, if you hold all copyright to the project or have contributor license agreements (CLAs) from all contributors. If third-party contributions are included under the current license without a CLA, relicensing requires permission from all contributors, which can be practically difficult.

Explore the category

Gitignore Generator Generate merged and deduplicated .gitignore output from stack presets. Editorconfig Generator Generate .editorconfig with global defaults and per-extension overrides. README Generator Generate markdown README scaffolds from core project fields. Dockerfile Generator Generate Dockerfile templates for Node, Python, and static Nginx apps. GitHub Actions Workflow Generator Generate starter CI/deploy workflow YAML for common project types. Package JSON Scaffold Generator Generate package.json scaffolds from project metadata and script presets.

Glossary

Permissive license
An open source license that imposes minimal restrictions on reuse. MIT, ISC, BSD, and Apache 2.0 are all permissive — they allow commercial use, modification, and redistribution with minimal obligations like attribution.
Copyleft
A licensing mechanism that requires derivative works and distributions of the software to carry the same license. GNU GPL licenses are the most common example, ensuring that freedom is preserved in downstream versions.
SPDX identifier
A standardised short string defined by the Software Package Data Exchange specification used to identify licenses in machine-readable form, such as MIT, Apache-2.0, or GPL-3.0-only.
Patent grant
An explicit clause in a license (present in Apache 2.0) that grants recipients a royalty-free license to any patents held by the licensor that are necessary to use the software, reducing patent litigation risk.
Contributor License Agreement (CLA)
A legal agreement signed by contributors that grants the project owner rights to use, relicense, or commercialise contributions. CLAs give maintainers flexibility but add friction for contributors.
OSI-approved license
A license certified by the Open Source Initiative as meeting the Open Source Definition. OSI approval signals that a license grants the freedoms expected by the open source community and is widely recognised by downstream users and organisations.
A LITTLE HELP. A LOT DONE.
Good tools.
Great flow.

Your shortcut to the everyday. Create, convert, calculate,
and get back to what you love.

✓ Free to use✓ No sign-up✓ 500+ possibilities