License File Generator

What is a free license file generator online?

A free license file generator online is a tool that produces the complete, correctly formatted text of an open source license with your name and year already filled in, ready to save as a LICENSE file in the root of your repository. Without a license file, published source code is legally "all rights reserved" — anyone can read it, but nobody has the right to use, copy, modify or distribute it, even though GitHub shows the code publicly[reference:0]. Adding a LICENSE file transforms your code from visible-but-restricted into genuinely open and reusable.

This license file generator goes beyond a simple text filler. It combines four tools in one page: a guided chooser that walks you through four plain-English questions to recommend a license, a generator that outputs the full license text with SPDX identifiers and optional per-file comment headers, a permissions and limitations matrix comparing ten licenses side by side, and a comprehensive guide to open source licensing. Everything runs in your browser — no sign-up, no account, no upload, no tracking.

How to use this free license generator online

1. License Picker tab. Answer up to four questions about copyleft, patents and commercial use. The tool recommends the most suitable license with a plain-English explanation.
2. Generate LICENSE tab. Enter your name or organisation, the year, and optionally a project name. Select a license from the grid. Click Generate to see the full license text, the SPDX identifier, and — if you chose a comment style — a ready-to-paste header block for your source files.
3. Compare Licenses tab. View the permissions, requirements and limitations of every license in a single matrix. Useful when you are deciding between two similar options.
4. Guide tab. Read the fuller explanation of permissive vs copyleft, SPDX identifiers, header styles and the common mistakes to avoid.

The ten licenses covered

These are the ten OSI-approved licenses that account for the overwhelming majority of open source projects. Each entry shows the SPDX identifier, a one-line summary and quick permission badges.

Permissive vs copyleft: the one distinction that matters

Every open source license grants the right to use, modify and distribute the software. What separates them is the conditions attached — and the single most important condition is whether the license is permissive or copyleft[reference:1].

Permissive licenses — MIT, Apache 2.0, BSD, ISC — ask very little. You can use the code however you like, including inside closed-source commercial products, as long as you preserve the copyright notice and license text. They do not require you to share your own changes. Among permissive licenses, the practical ranking for commercial use is Apache 2.0 (permissive plus patent protection), then MIT and BSD (permissive, no patent language)[reference:2].

Copyleft licenses — GPL, AGPL, LGPL, MPL — require that derivative works be distributed under the same license. In practice this means sharing your source code under those terms. Copyleft comes in strengths: strong (GPL, affects the whole combined work), weak (LGPL and MPL, affects only the licensed component or file) and network (AGPL, triggers even when the software is provided as a service without distributing it)[reference:3].

Which family a component belongs to matters far more than the specific license name. If you are building a proprietary product, permissive dependencies are usually safe; copyleft dependencies need review.

SPDX identifiers and why they matter

SPDX (Software Package Data Exchange) is an open standard maintained by the Linux Foundation for communicating software bill of materials information[reference:4]. Every SPDX-recognised license has a short, unambiguous identifier — MIT, Apache-2.0, GPL-3.0-only, BSD-3-Clause. Using the correct SPDX identifier in your package manifest and in source file headers lets automated license scanners, SBOM tools and compliance pipelines identify your license without guessing.

SPDX also distinguishes between "only" and "or-later" versions. GPL-3.0-only means exactly version 3; GPL-3.0-or-later means version 3 or any later version published by the FSF. The choice matters for compatibility and is recorded in the header. This generator uses the "only" form by default because it is the more conservative option.

Do you need a license header in every file?

Modern practice has moved away from long per-file headers. The three common approaches are:

• Full traditional header. Three to twenty lines of comment at the top of every source file. Common in older, larger projects, and still standard in C, C++ and Java codebases.
• SPDX one-liner. A single machine-readable line: // SPDX-License-Identifier: MIT. Used by the Linux kernel, curl, FFmpeg and many modern projects. Minimal noise, fully machine-readable.
• LICENSE file only. No per-file headers. The single LICENSE at the repository root is the source of truth. Common in the JavaScript and TypeScript ecosystem and in small libraries.

All three are valid. Pick by context. This generator supports the first two: choose a comment style and it will produce a header block you can paste at the top of your files, with the correct comment syntax for C-style languages, hash-comment languages, HTML, SQL and others.

How to add a LICENSE file to GitHub

Adding a license to a GitHub repository takes under a minute:

1. Navigate to the main page of the repository.
2. Above the file list, click the Add file dropdown, then Create new file[reference:5].
3. In the file name field, type LICENSE or LICENSE.md — all capitals, no other punctuation[reference:6].
4. Paste the full text of the license into the editor.
5. Commit the file. GitHub will detect the license and display it at the top of the repository page.

GitHub also offers a "Choose a license template" button that appears when you name the file LICENSE. You can use that instead of pasting, but the template picker does not let you pre-fill your name and year, which is why a generator is faster for the common case.

Common licensing mistakes

• No license at all. Publishing code without a license does not make it open source. Default copyright applies, and others have no legal right to reuse it[reference:7].
• Copying the wrong license text. Using a license text that has been modified — even slightly — can invalidate it. Always use the verbatim standard text.
• Forgetting the year or holder. A license file that still contains <year> or [fullname] placeholders is not a valid license.
• Assuming MIT and Apache 2.0 are interchangeable. They are similar, but Apache 2.0 adds an explicit patent grant that MIT lacks. For patent-heavy technologies or corporate contributors, this difference matters[reference:8].
• Using GPL in a proprietary product without review. GPL copyleft can obligate you to release your own source code. Companies routinely flag GPL dependencies for legal review by default[reference:9].
• Mixing incompatible licenses. GPLv2 and GPLv3 are not automatically compatible with each other. Combining code under incompatible licenses can create a distribution problem.
• Changing the license without contributor permission. If others have contributed, you cannot relicense their work without their agreement.
• Treating a generator's output as legal advice. A generator produces standard text. It does not analyse your project, your dependencies or your business model.

Frequently asked questions