You push your project to GitHub without a LICENSE file and, technically, no one has legal permission to use your code, not even to copy it, even if the repository is public. Not having a license doesn't mean "free for anyone": by default, copyright protects the code and no one can reuse it without explicit permission. Choosing a license is, literally, deciding what you allow others to do with your work.
What a software license decides
A license answers very specific questions: can someone use my code in a commercial project? Can they modify and redistribute it? If they modify it, are they required to share those changes? Do I need to be credited as the original author?
The most common licenses, explained without legal jargon
-
MIT: the most permissive and popular. Anyone can use, modify and redistribute your code, even in closed commercial projects, with the only condition being to keep the original copyright notice. It's the default choice if you want maximum adoption with no restrictions.
-
Apache 2.0: similar to MIT in permissiveness, but adds explicit patent protection: if someone contributes code and later tries to sue over patents related to that contribution, they lose the right to use the license. Common in large corporate projects.
-
GPL 3.0: a copyleft-type license: if someone modifies your code and distributes the result, they're required to publish those changes under the same GPL license. It's the right choice if you want to guarantee that improvements to the project stay open, though companies tend to avoid GPL dependencies precisely because of this obligation.
-
BSD (2- and 3-clause): very similar to MIT in permissiveness; the 3-clause version adds a restriction on using the original author's name to promote derivative products without permission.
-
ISC: functionally equivalent to MIT, with shorter, simplified legal text.
How to choose the right license
- You want maximum adoption, even in closed commercial software: MIT or ISC.
- You want maximum adoption but with explicit patent protection: Apache 2.0.
- You want any improvement to the project to stay open source: GPL 3.0.
- You prefer the MIT style but with an extra clause about the use of your name: 3-clause BSD.
How to generate your LICENSE file
- Choose the license that fits what you want to allow.
- Fill in your name and the year where the license requires it.
- Download or copy the generated text as a
LICENSEfile at the root of the repository.
You can do it free with the LICENSE generator on this site.
Why this isn't just a formality
Without a clear LICENSE file, any company wanting to reuse your code in a commercial product can't do so with legal certainty, no matter how open the repository looks on the surface. Many companies have internal policies that directly prohibit using dependencies without an explicit license, precisely because of this risk. A correct LICENSE isn't just good practice: it's what makes your project actually usable by others.
Frequently asked questions
What happens if I don't add any license? Standard copyright applies by default: no one has permission to use, copy or modify your code without your explicit authorization, even if the repository is public.
Can I change licenses later? It's complicated once others are already using or contributing to the project under the previous license; it's best to decide the right license from the start.
Are MIT and Apache 2.0 basically the same? They're similar in permissiveness, but Apache 2.0 adds a specific patent protection clause that MIT doesn't have.
Does GPL stop me from making money with my project? No, GPL doesn't prohibit commercial use; what it requires is that distributed modifications stay open source under the same license.
Generate the correct LICENSE file for your project for free with the LICENSE generator, with MIT, Apache 2.0, GPL 3.0, BSD and ISC.