This article explains ideas at a general level. It is not legal advice, licences differ between countries and versions, and anyone with a serious need, such as a business use or a dispute, should read the actual licence text and ask a qualified professional.
Why a public project needs a licence
It is easy to assume that code posted publicly is free for anyone to use. In many places, the opposite is the default: the author holds copyright automatically, and others have no clear permission to copy, modify or redistribute the work unless the author grants it. A licence is the document that grants those permissions, and sets any conditions.
So a public repository with no licence is, in practice, a repository that people may be nervous about using. If you want others to build on your project, include a licence file in the repository root so the terms are obvious.
What “open source” means
Open source software is released under terms that allow people to use, study, modify and share it. There are many such licences, and they differ mainly in what they require of people who reuse your work. It is worth separating this from “free to look at”. Some projects publish their source but restrict reuse, and that is a different thing from an open source licence.
Permissive licences
Permissive licences place few requirements on reuse. Generally, someone can use your code in their own project, including a closed or commercial one, as long as they keep a copyright notice and the licence text. Well-known examples include the MIT and BSD families and the Apache licence. The Apache licence is a little longer and also deals explicitly with patents, which some people value.
The appeal is simplicity and wide adoption. The trade-off is that someone can take your code, improve it and keep their improvements private. If you are happy with that, a permissive licence maximises how many people will feel comfortable using your work.
Share-alike (copyleft) licences
Share-alike licences, often called copyleft, add a condition: if someone distributes a modified version or a larger work built on yours, they must offer it under the same or compatible terms. The GNU General Public License is the best-known example. The goal is to keep improvements open.
The trade-off is that some companies and projects avoid copyleft code because of the obligations it brings. There are also variations, such as licences that apply the share-alike rule only to the library itself rather than to everything that uses it. The exact scope differs by licence and version, which is where reading the text matters.
Questions to ask before choosing
Rather than hunting for a “best” licence, consider what you want:
- Do I mind if my code ends up in a closed product? If not, permissive is usually fine. If you would prefer improvements come back to the community, look at share-alike.
- Who do I expect to use it? Hobbyists, companies, other libraries? Some audiences have strong preferences.
- What am I building on? If your project includes or links other people’s code, their licences may limit what you can choose. Check compatibility before you decide.
- Is it software, hardware or documentation? Software licences do not always suit circuit designs, 3D models or written guides. Separate licences exist for creative and hardware work, so check what fits each part of your project.
- Do I own all of it? If others send open source contributions, think about how those are licensed, so that the project’s terms stay clear.
Practical steps
A sensible routine is short:
- Decide roughly where you stand: permissive or share-alike.
- Choose a standard, widely used licence rather than writing your own. Standard texts are well understood and tools can recognise them.
- Put the full licence text in a file such as
LICENSEat the top of the repository, and mention it in the README. - Add a copyright line with your name and the year, as the licence instructs.
- Keep a record of any third-party code you included and its licence.
Online comparison tools and the licence texts’ own summaries can help you understand the options. They are aids to understanding, not a substitute for advice.
What a licence does not do
A licence does not protect you from every problem. Most open source licences state that the software comes without warranty, which is reassuring for the author but also means users must judge quality for themselves. A licence also does not cover trademarks, which are a separate matter, and it does not make a project secure or well maintained. Mistakes in what you commit, such as accidentally including keys, are a matter of API key secrecy and good habits, not of licensing.
If you later change your mind, you can release new versions under new terms, but copies already distributed under the old licence generally stay under it. That is a reason to think carefully at the start, even though most small projects will do well with a common, standard choice.