How to Choose and Generate an Open Source License

A public repository on GitHub is not the same as code anyone is allowed to use. The two questions look identical from the outside, and they are not. If you push code with no LICENSE file, copyright law treats it as all rights reserved by default: people can read it, but they cannot legally copy, modify, or redistribute it. The single most consequential file in many open source projects is the one nobody reads, and it is twenty lines long.

This guide walks through the choice that file encodes. We will cover the two families of licenses, what each one actually permits and demands, the difference between permissive and copyleft in plain terms, and how to write the file and put it in the right place. At the end there is a worked example with the exact text MIT produces.

Why no license means all rights reserved

Start with the case most developers get wrong. You write some code, you make the repo public, and you assume that making it visible makes it usable. It does not. Under default copyright, the author holds every right automatically, the moment the work exists. There is no opt-out by silence and no implied grant from clicking the public toggle.

So a repository with no LICENSE file is, legally, a museum exhibit: you may look, you may not take. A company lawyer reviewing dependencies will flag it as unusable. A careful contributor will not open a pull request, because they have no right to distribute their changes back. The fix is not to write a paragraph in the README saying "feel free to use this." The fix is a recognized license file, because licenses are the standard machine-readable and lawyer-readable way to grant those rights.

Permissive licenses: use it, keep the notice

A permissive license grants broad rights and asks for almost nothing in return. The canonical examples are MIT, the BSD family, ISC, and Apache 2.0. The deal is simple: others may use, modify, and redistribute your code, including inside closed-source commercial products, as long as they keep your copyright notice and the license text.

That last clause is the only real obligation, and it is why you sometimes see a wall of license notices buried in the credits of a phone app. Each bundled permissive component requires its notice to travel with the distribution.

Within the permissive family there are small but real differences:

MIT is three short paragraphs. It grants everything and disclaims warranty. Nothing else.
BSD-3-Clause adds a clause forbidding the use of the author's name to endorse derived products. BSD-2-Clause drops that and is effectively MIT-equivalent.
ISC is MIT with even terser language, common in the OpenBSD world.
Apache 2.0 is the heavyweight: it adds an explicit patent grant, so a contributor cannot later sue users over a patent covering code they contributed, plus a NOTICE-file mechanism. If a company or patents are involved, Apache is the safer permissive choice.

For a small personal library, MIT is the friction-free default. The moment patents or corporate distribution enter the picture, reach for Apache 2.0.

Copyleft licenses: the freedom travels downstream

Copyleft flips the obligation. Where a permissive license lets a closed product absorb your code, a copyleft license insists that derivatives stay open under the same terms. The freedom you granted is required to travel to everyone downstream.

GPL-3.0 is the strong form. If someone distributes a program that includes GPL code, the whole program must be released under the GPL, with source available. This is deliberate: it guarantees that improvements to the code base remain in the commons and cannot be enclosed inside a proprietary product. It is also why some companies have a blanket policy against shipping GPL code, which is a constraint to know before you pick it.

MPL-2.0 is weak copyleft, and the distinction matters. Its reach is file-level: only the files you took from the MPL project must stay open when modified. You can combine MPL code with proprietary code in the same program as long as the original MPL files, with your changes to them, remain available. It is a middle path between MIT and GPL.

The practical takeaway: copyleft is a feature when your goal is to keep every fork open, and a blocker when your goal is maximum adoption by anyone including closed products. Neither is morally superior. They encode different intentions.

A worked example: MIT for a small library

Say I am publishing a tiny date-parsing library and I want the widest possible adoption with zero friction for anyone who wants to use it. I pick MIT. In the Open Source License Generator I select MIT, type 2026 in the year field, and put my name as the holder. The preview fills in the placeholders live, and Download writes a file named exactly LICENSE. The result reads:

MIT License

Copyright (c) 2026 Jane Doe

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

Read what those verbs actually grant: use, copy, modify, merge, publish, distribute, sublicense, sell. Everything. The one condition is the line requiring the notice to be included in copies. That is the entire bargain. Anyone, including a company building a paid product, can take the library, ship it, and never owe me a thing except that retained notice.

I have shipped that exact file across a dozen small repos, and the reason I reach for MIT by reflex on personal work is precisely that there is nothing to argue about. The contributor reads three paragraphs, understands them fully, and opens the pull request without consulting anyone.

Adding the LICENSE file to your repository

Generating the text is the easy part. Placing it correctly is what makes tooling recognize it.

Name it LICENSE with no extension, or LICENSE.md. Put it in the repository root, next to the README. GitHub, GitLab, and npm all auto-detect that filename and display a license badge on the project page.
Do not bury it. A file called license.txt inside a docs folder will not be detected, will not show the badge, and will not be picked up by automated dependency scanners.
Mirror it in package metadata. Add the SPDX identifier such as MIT or Apache-2.0 to the license field in package.json, Cargo.toml, or your equivalent manifest. The file is the legal source of truth; the SPDX id is what machines read.

One avoidable mistake deserves repeating: do not mix a copyleft dependency into a permissive project without checking. If you pull in GPL code, your whole project can be forced to become GPL. Confirm the badge and the compatibility before you publish.

While you are setting up the repo root, the same two-minute discipline applies to other config files. A clean .gitignore belongs next to the LICENSE, and both should land in the first commit, before you invite anyone in.

The decision in one line

Want maximum adoption with no strings? MIT or ISC. Care about patents or corporate distribution? Apache 2.0. Want every fork to stay open source? GPL-3.0. Want a file-level middle ground? MPL-2.0. Want to give the code away with no rights retained at all? The Unlicense. Whatever you choose, the cardinal rule holds: ship something, because shipping nothing means all rights reserved, and all rights reserved means nobody can legally use the work you made public.

Made by Toolora · Updated 2026-06-13