Picking the right open source licence for your code
What each major licence allows and forbids, how the chooser narrows the field from nine options to one, the patent and service questions that trip people up, and how to save the finished text as a LICENSE file.

Why a repository needs a licence at all
Code without a licence is not free to use. Copyright law gives the author exclusive rights by default. Nobody may copy, modify, or distribute the work unless the author says so in writing. A public repository with no licence file is visible to the world but legally untouchable.
An open source licence is that written permission. It tells everyone what they are allowed to do, what they must do in return, and what they must not do. The range goes from almost no conditions at all to a full requirement that every change be shared under the same terms.
Choosing the wrong one is expensive to fix. Once other people contribute code, changing the licence requires the agreement of every contributor. That gets difficult fast. It is worth spending ten minutes on the decision now rather than discovering the problem two years into a project.
The question the whole field turns on
The side panel starts with If someone builds on this and offers three answers. This single question is the divide that separates every licence into its camp.
They may keep their work closed is the permissive path. Someone can take your code, build a product around it, and sell that product without ever showing their changes. MIT, Apache, and BSD live here. Most libraries and frameworks choose this because it means the widest possible adoption.
Changes to my files must stay open is the weak copyleft path. If someone modifies your source files, those changes must be published under the same licence. But new files they write on top of yours can stay closed. Mozilla Public Licence and LGPL work this way. This is common for shared libraries that a closed application links against.
Everything built on it must stay open is the strong copyleft path. Any software that includes your code must be released under the same terms, including entirely new code that builds on it. GPL and AGPL live here. This is the choice when you want to guarantee that every user of the software can see and change it.
Patents and the service gap
Below the main question sit two checkboxes that refine the choice.
I want an explicit patent grant matters when the code might be covered by a patent. Under MIT, there is no promise about patents. A contributor could submit code, then later claim a patent covers it and sue the people using it. Apache 2.0 closes that gap. Every contributor automatically grants a patent licence for anything their contribution covers. This is why large companies often default to Apache.
Running it as a service should count as distributing it addresses the software-as-a-service loophole. GPL requires you to share your changes, but only when you distribute the software. Running it on a server and letting people use it through a browser is not distributing it. The AGPL adds a clause that treats network use as distribution. If someone modifies your code and runs it as a hosted service, they must publish their changes.
The nine licences on the list
The Licence dropdown can recommend one based on your answers, or you can pick directly. Here is what each option does in a sentence.
MIT is the shortest and most popular. It says do whatever you want, just keep the copyright notice. Apache 2.0 is MIT plus a patent grant and a requirement to note changes. BSD 3-Clause is close to MIT with an extra rule against using the author's name for promotion.
Mozilla Public 2.0 is file-level copyleft. Changes to the licensed files must stay open, but new files can be closed. LGPL 3.0 is similar but aimed at libraries that a closed application links to.
GPL 3.0 is full copyleft. Any work that includes the code must be released under the same terms. AGPL 3.0 is GPL plus the network clause.
The Unlicense and CC0 both try to put the code in the public domain, giving up as many rights as the law allows. The difference is in how they handle countries where public domain dedication is not a legal concept. CC0 includes a fallback licence for those cases. Both are used for code that the author wants to give away completely, such as reference implementations, sample code, and small utilities.
Filling in your details
The Copyright holder field takes your name or your company name. The Year field defaults to the current year. Both are inserted into the licence text wherever it calls for them.
For licences that are short enough to include in full, the finished text appears in the LICENSE file textarea at the bottom of the main panel. For longer licences like GPL, LGPL, MPL, and CC0, the text must be included exactly as published. A shortened or paraphrased copy is not valid. Those licences are linked to the official SPDX source rather than reproduced here.
Saving the file
Press Download to save the text as a plain file called LICENSE with no extension. That is the conventional name, and most hosting platforms recognize it automatically. GitHub, for example, reads this file and displays the licence type on the repository page.
Copy puts the text on your clipboard if you want to paste it into an existing file or a project template. The file belongs in the root of the repository, alongside the readme and the main configuration files. Do not put it in a subfolder where it might be missed by someone scanning the project.
The prefer shortest option
Prefer the shortest possible licence is ticked by default. When two licences satisfy the same answers, it picks the one with fewer words. In practice, this usually means MIT wins over Apache when patents are not a concern.
Untick it and the recommendation may shift to a licence with more precise terms. A longer licence is not a worse licence. It simply spells out more edge cases. The trade-off is that fewer people will read it, and more will ask their legal team whether it is safe, which slows adoption.
Mistakes that cause real problems later
- Shipping without any licence file. A public repository with no licence is legally all rights reserved, even if you intended it to be free.
- Choosing a licence because it is popular. MIT is the most used, but if you want changes to stay open, it does not do that. Choose based on what you want to happen, not on what most people do.
- Expecting to change the licence later. Every contributor holds copyright over their own contribution. Relicensing requires permission from all of them. A Contributor Licence Agreement can help, but it must be set up from the start.
- Confusing MIT with public domain. MIT requires the copyright notice to be kept in every copy. Public domain dedication gives up that right entirely. They are different legal positions.
- Assuming GPL applies to hosted services. GPL triggers on distribution. Running code on your own server is not distribution. AGPL is the version that covers that case.
This is not legal advice
The tool summarises well-known licences to help you choose. It does not interpret law, and it does not know anything about your situation beyond the questions you answered. If real money is attached, or if a company's products depend on the decision, talk to a lawyer.
What it does do is get the boring part right. The licence text is correct, the copyright line is filled in, and the file is ready to drop into a repository. The legal thinking is yours. The typing is not.
Everything stays in your browser
The recommendation, the comparison, and the licence text are all produced on your own machine. Nothing about your project or your choices is sent to any server. There is no account and no record of what you looked at.
For a company evaluating licences for an internal project, that means the decision process is private. No one outside the room knows which licence you considered, which questions you answered, or what you decided. You can disconnect from the network and the page still works, since every licence text is already loaded.
