UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

License Generator

Generate common OSS license templates with year and copyright holder.

About License Generator

Shipping code without a license is more consequential than most developers realise. Under default copyright law, unlicensed code is fully proprietary — no one can legally use, copy, modify, or distribute it without explicit permission, even if it is publicly visible on GitHub. The License Generator produces complete, correctly formatted text for the most widely used open source licenses — MIT, Apache 2.0, GNU GPL v2 and v3, GNU LGPL, Mozilla Public License 2.0, BSD 2-Clause, BSD 3-Clause, ISC, and the Unlicense — with your name and year automatically substituted. It also provides a plain-language summary of what each license permits, requires, and prohibits so you can make an informed choice.

Why use License Generator

Correct Copyright Substitution Every Time

License templates contain placeholder fields for the copyright holder's name and year. The generator fills these automatically so you never ship a license file containing [YOUR NAME] or [YEAR] placeholder text.

Plain-Language Summaries for Informed Decisions

Legal license text is dense and hard to parse quickly. Each license comes with a concise summary of what it permits (use, modify, distribute), what it requires (attribution, source disclosure), and what it prohibits (sublicensing, trademark use).

Covers the Full Spectrum From Permissive to Copyleft

From the extremely permissive Unlicense and ISC to the strong copyleft GNU GPL v3, the generator covers licenses across the entire open source spectrum so you can match the license to your project's philosophy and audience.

OSI and FSF Approved License Texts

All generated license texts are taken verbatim from official OSI-approved and FSF-approved sources. You get legally accurate text, not a paraphrase or approximation that could create ambiguity in a downstream legal review.

Instant Compatibility Check Reference

The license detail view includes compatibility notes showing which licenses can be combined in the same project, helping you avoid the common mistake of mixing GPL code with MIT-only dependencies in a redistributed binary.

Supports Commercial and Dual-Licensing Use Cases

Apache 2.0 and MIT are both compatible with commercial use. The generator's explanations make this clear upfront, saving you the research step when a client or employer asks whether your chosen license allows commercial deployment.

How to use License Generator

  1. Read the short summary cards to understand the key differences between permissive, copyleft, and public domain options
  2. Select your desired license type from the list: MIT, Apache 2.0, GPL v3, BSD, ISC, MPL 2.0, or others
  3. Enter your full name or organisation name as it should appear in the copyright notice
  4. Confirm or adjust the year — it defaults to the current year
  5. Click Generate to produce the full license text with your details substituted
  6. Copy the output and save it as a file named LICENSE or LICENSE.txt in your repository root

When to use License Generator

  • 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

Input: License: MIT, Name: Jane Smith, Year: 2026

Output: 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...

Apache 2.0

Input: License: Apache 2.0, Name: Acme Corp, Year: 2026

Output: 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...

BSD 3-Clause

Input: License: BSD 3-Clause, Name: Open University, Year: 2026

Output: 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

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.