Publishing code without a license is one of the most common mistakes made by people opening their first repository. Without a license, the code remains fully protected by copyright: anyone can read it, but nobody can lawfully copy, modify or redistribute it. The result is a project that looks open but is not. Choosing a license does not require legal study: you just need to answer a few questions honestly. This is the procedure I follow when helping someone start a project.
Question 1: what do I want to happen to modified versions?
This is the decisive question, because it separates permissive licenses from copyleft ones.
- I am fine with someone including it in a closed product. Then a permissive license is the natural choice: MIT, BSD or Apache 2.0.
- I want those who distribute modified versions to share them. Then you need copyleft: the GPL for programs, the LGPL or MPL for libraries.
There is no absolutely right answer. Many foundational libraries are permissive because their value lies in spreading widely; many complete applications are GPL because their authors want them to stay free.
Question 2: will the software mainly run on servers?
If the project is a web application, an API or a service, the GPL has almost no effect: the software is not distributed to users, so the obligations never apply. If you want copyleft in this scenario too, the consistent choice is the AGPLv3. Bear in mind that some companies avoid the AGPL as internal policy, which may reduce adoption.
Question 3: are patents involved?
If companies will contribute to the project, or if the technical field is dense with patents (media coding, cryptography, networking), a license with an explicit patent grant is advisable:
- among permissive licenses, Apache 2.0;
- among copyleft licenses, GPLv3, LGPLv3, AGPLv3 or MPL 2.0.
MIT and BSD do not address patents explicitly. For a small personal tool that is not a problem; for a project with corporate contributors it may be.
Question 4: what must the code live alongside?
Dependencies constrain the choice. If the project uses a GPL library tightly, the distributed whole will be GPL anyway. If the project wants to be included in an ecosystem that uses a specific license, adopting the same license reduces friction. Some examples:
- a plugin for a GPL application naturally tends towards the GPL;
- a library for an ecosystem where the MIT and Apache 2.0 dual license prevails benefits from adopting it;
- a Linux kernel module must be compatible with GPLv2.
Question 5: what community do I expect?
A license sends a signal. A permissive license attracts corporate contributions and commercial use. A copyleft license reassures people who fear their work will be locked up by others. Thinking about who you want to involve helps you choose.
A summary table
| Situation | Recommended license |
|---|---|
| Small utility, maximum freedom | MIT |
| Library with corporate contributions | Apache 2.0 |
| Library that must stay free but usable anywhere | LGPLv3 or MPL 2.0 |
| Desktop application that must stay free | GPLv3 |
| Web application that must stay free | AGPLv3 |
| Documentation | CC BY 4.0 or CC BY-SA 4.0 |
Mistakes to avoid
- Writing your own license. An invented license, however well meant, creates uncertainty and discourages adoption. Established licenses have been read by many lawyers and are recognised by automated tools.
- Modifying the text of an existing license. Adding clauses such as "not for military use" turns the license into something that is no longer open source and makes it incompatible with many others.
- Choosing a "non-commercial" license. It is not open source and rules out many legitimate uses.
- Forgetting contributors. If several people have written code, changing the license later requires their consent or a mechanism planned in advance.
How to apply it in practice
Once you have chosen the license:
- create a
LICENSEfile at the root of the repository with the full, unmodified text; - fill in the year and copyright holder correctly where required;
- add a standard identifier at the top of every source file, for example:
# SPDX-License-Identifier: MIT
- state the license in the README and in the package metadata (for example
package.json,pyproject.toml,Cargo.toml); - if you use Apache 2.0, consider whether to create a
NOTICEfile.
Changing your mind later
Moving from a permissive license to a copyleft one, or vice versa, is possible but not trivial: you need the rights to all the code or the contributors' consent. Versions already published remain available under the original license. That is why it is worth spending half an hour on the choice from the very first commit.
In short
- Without a license, code cannot be reused, even if it is public.
- The first question is whether modified versions must stay free: permissive or copyleft.
- Network software needs the AGPL; for patents, Apache 2.0 or the version 3 GPL licenses are advisable.
- Dependencies and the ecosystem may dictate the choice.
- Use an existing license without changes and declare it with standard identifiers in every file.
