You found a beautiful software project on GitHub. Maybe the README file even mentions that it’s open source. You download it, then you put it on your company’s server.
But you might just have committed a copyright violation!
But… how is it possible? It was on GitHub, and the authors seem to genuinely think it’s Open Source!
The problem is that code needs a license.
What Happens if No License is There
Code, articles, and in general any human creation need a license. A missing license is equivalent to the infamous All rights reserved note. You can download that code and use it, but you do not have the right to:
- Modify the code;
- Distribute it to others;
- Copy it to any computer that is not yours.
GitHub Terms of Service impose some exceptions, but they are very limited. Essentially, they are designed to make the website’s features legal, no matter what the license is. So, for example, you can fork the repository or edit a file online. But the moment you pull or download any code outside of GitHub, the Terms of Service stop shielding you.
If you want more details, I suggest you read this page, curated by GitHub and the community. But the page is not complete so, for example, it might not be obvious to you that you don’t have permissions to use non-licensed code on your organisation’s server; or even share it with a teammate outside of GitHub.
How Licenses Should be Displayed
For a license to be valid, it’s necessary that the user sees it (or is asked to read it) before performing any action that might constitute a license violation.
For code on GitHub, this typically means that, as an author:
- You need to write a note in the
READMEfile; - You need to distribute the license as part of the source code;
- The program needs to inform the final users about the license, in case they received the software in a binary form.
Repository-Specific Metadata
Some technologies make use of some native repositories. For example Python has PyPi, Ansible has Ansible Galaxy, Node.js has npm… and there are many more. Generally speaking, those repositories require a metadata file that contains some information that the user might want to know before downloading or installing some software. A relevant piece of information is, of course, the license.
Is it really necessary to add license and copyright information in those metadata files? Sometimes probably not, but it’s a good idea to always do it for a number of reasons:
- Users who care about licenses should be able to see accurate information in every relevant place.
- For packages without a license, the repository might show “Unlicensed” or something like that. This might make your license harder or impossible to enforce, and genuinely confuses users.
- Providing accurate license information in all reasonable ways makes your license easier to enforce.
- If you made a small mistake somewhere else, it’s possible that correct redundant information is considered sufficient to compensate that mistake.
Do Licenses Really Need to be Written in Each File?
Some licenses might have requirements about how the license itself should be distributed. It’s always a good idea to follow the license’s common practices and any other advice from the license’s authors.
The BSD, for example, can only be enforced when a file that contains the license is copied.
The Free Software Foundation encourages developers to add a standard license note at the beginning of each file, as a comment. In their case this doesn’t seem to be a legal requirement, but again, following the authors’ guidance is a good idea. See How to Use GNU Licenses for Your Own Software.
If you can’t find any indication from the authors, just follow the common practice for the license you’ve chosen.
Lots of more details can be found in this great article: The open source notice requirement in web-based applications.
Using SPDX
Occasionally, license notes are worded in ambiguous or confusing ways. For example, when a license is indicated generically, without a version number (e.g.: GPL). Or when multiple licenses are provided, and it’s not clear which license applies to what.
SPDX (Software Package Data Exchange) is a standard format designed by the Linux Foundation. It allows us to communicate software license and copyright information without ambiguities. It provides short identifiers for common licenses (like MIT, Apache-2.0 or GPL-3.0-or-later). It also defines a license expression syntax for combining multiple licenses, like MIT AND Apache-2.0, or GPL-2.0-or-later OR BSD-3-Clause.
This standard makes it easier for both humans and automated tools to quickly identify licenses without confusion.
In the code, a SPDX identifier should be indicated first. Copyright should follow. Immediately after that, you can put any text required by the license. For example:
// SPDX-License-Identifier: GPL-2.0-or-later
// Copyright (C) 2025 Darth Vader <darth.vader@empire.com>
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License
// as published by the Free Software Foundation; either version 2
// of the License, or (at your option) any later version.
//
// ...
What to do When No License is Provided
You want to use some useful software, but the source code has no license. Damn it! What can you do?
In most cases, if code has no license, it’s because its authors are not aware of the legal consequences of this. They usually think that software without license is public domain, or that generically mentioning that the code is Open Source is sufficient.
In these cases, assuming that the software is still maintained, all you have to do is to inform the authors. Open a bug or a feature request. The maintainers might not know the correct way to add licenses, so it’s a good idea to add a link to an article that provides some guidance.
Don’t propose a specific license; the authors will choose the license they prefer. But if you have compatibility problems, explain them. For example, you can add that you personally need a license that is compatible with Apache License 2.0, and explain the reason.
If a license is specified in a configuration file related to some specific repository, most probably the maintainers think that this is sufficient. You should explain to the maintainers that this practice is indeed a good idea, but doesn’t eliminate the need to include a license properly.
Remember: contributions are essential to Open Source. And reporting a missing license as a bug is a great contribution. And be kind. Make sure that your bug report doesn’t come across as lecturing.
IMAGE CREDIT: DALL·E 3

