A Practical Guide to Applying a License

1. A LICENSE file at the repository root

The first thing to do is put the license text in a LICENSE (or LICENSE.txt, LICENSE.md) file at the root of the repository. GitHub, GitLab and package managers look for this file to detect the license. Choose a license in the generator, enter the year and copyright holder, and you can download it right away.

• Don't edit the text: Only fill in placeholders such as [year] and [fullname] in MIT, BSD and ISC, and leave the rest of the wording as is. Changing the wording means it will not be recognized as a standard license and can cause interpretation problems.
• GNU licenses in full, verbatim: The GPL, LGPL and AGPL texts have no blanks to fill in. The copyright holder and version clause are stated in the file notices.

2. Year and copyright holder

• Year: It is common to use the year of first publication. Ranges like 2019-2026 are also used. There is no legal obligation to update it every year.
• Copyright holder: For code written by an individual, that person's name; for code written as part of a job, usually the employer (this varies by country and contract). Projects with many contributors sometimes write The Example Project Authors and maintain the list in an AUTHORS file.
• A copyright notice announces rights; it does not create them. Copyright exists even without the notice.

3. Companion files by license

The Apache-2.0 NOTICE is not mandatory, but anyone redistributing code that has a NOTICE must keep its contents. The ASF recommends putting only legally required attribution notices in NOTICE, not thank-yous or full license texts.

4. Source file headers

A short header in each file means the license information travels with the file even if it is copied on its own.

# SPDX-FileCopyrightText: 2026 Example Inc.
# SPDX-License-Identifier: Apache-2.0

GNU, Apache and MPL also recommend their official notices, but more and more projects replace them with just the two SPDX lines. See the SPDX guide for details.

5. Package metadata and README

• Put the SPDX identifier in the license field of package.json, Cargo.toml, pyproject.toml and similar files.
• Add a "License" section at the end of the README with a one- or two-line summary (e.g. "This project is licensed under the MIT License — see LICENSE").

6. Third-party code notices

If you distribute other people's code with yours, you must also meet their license obligations.

• For copied code, keep the original copyright notice and license in the relevant file.
• If you distribute binaries or apps, gather the list of open source components used and their full license texts in a THIRD_PARTY_NOTICES file or the app's "open source licenses" screen.
• If you have many dependencies, generate the list automatically with SBOM tools or your package manager's license reporting feature.

7. Accepting contributions: DCO or CLA

Accepting outside contributions splits copyright among many people. There are two ways to manage this.

• DCO: Contributors add Signed-off-by: to commits to confirm "I have the right to submit this code under the project's license". It is lightweight and used by the Linux kernel.
• CLA: An agreement in which contributors give the project broad rights, including relicensing. It is needed for commercial dual licensing or to keep the option of changing the license later.

Write the contribution rules in CONTRIBUTING.md.

8. Changing the license

• The copyright holder can apply a different license to future versions. Permissions for already released versions generally cannot be revoked.
• If other contributors' code is included, their consent is needed (unless you received relicensing rights through a CLA).
• Moving from permissive to copyleft is relatively easy (because permissive code can go into copyleft projects), but moving from copyleft to permissive is practically impossible without the consent of all copyright holders.
• Clearly record when, why and from which version the change applies in the CHANGELOG and README.

Checklist

1. LICENSE text (only placeholders filled in)
2. Companion files (NOTICE, COPYING.LESSER, etc.)
3. File headers (two SPDX lines)
4. Package metadata and README
5. Third-party notices
6. Contribution rules (DCO or CLA)

This article is general information, not legal advice. Consult a professional for important decisions.

Sources

• GitHub Docs, Adding a license to a repository — https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
• Apache, Applying the Apache License · Assembling LICENSE and NOTICE — https://www.apache.org/legal/apply-license.html
• GNU, How to Use GNU Licenses for Your Own Software — https://www.gnu.org/licenses/gpl-howto.html
• REUSE Specification — https://reuse.software/spec/
• Developer Certificate of Origin — https://developercertificate.org/