How to add SPDX license identifiers to your source files

Add a single comment line to the top of each source file that reads SPDX-License-Identifier, a colon, a space, and a license ID such as MIT. It is short, machine readable, and tells scanners and humans exactly which license applies to that file without parsing a long legal header.

What the tag looks like

The format has four parts. First comes the comment start characters for the language, if the language needs them. Then the text SPDX-License-Identifier: followed by a space. Then one SPDX license ID or one license expression. Last come the comment end characters, if needed.

// SPDX-License-Identifier: MIT
/* SPDX-License-Identifier: MIT OR Apache-2.0 */
# SPDX-License-Identifier: GPL-2.0-or-later

Use one ID when a single license applies. Use an expression when two or more apply. The next post in this series covers the operators in detail: see OR versus AND in license expressions.

Why bother with a tag

Long license headers are written for lawyers and are copied with small variations. A scanner has to guess whether a slightly edited paragraph is still the same license. A tag removes the guess. Every file declares its own license in a form a script can read with a one line search.

That matters for mixed repositories. A project might ship mostly under one license with a vendored folder under another. File level tags show the boundary without anyone having to read the folder README.

What the tag does not replace

A tag is a pointer, not the license text. You should still ship the full license file at the repository root so recipients get the complete terms.

It also does not cover copyright notices. The SPDX guidance says you should not remove or modify existing copyright notices when you add an identifier. If a file already carries a copyright line, keep it and add the tag beside it.

A rollout plan that works

1. Pick the license and confirm you have the right to apply it to every file. Code you copied from elsewhere keeps its original terms.
2. Add the tag to new files first, using a template in your editor or a pre-commit check that fails when the line is missing.
3. Backfill existing files with a script, but review the diff. A script that blindly stamps one license on a vendored file creates a false statement.
4. Leave third party files with their own tags and notices untouched.
5. Add a CI check that lists files without a tag so gaps stay visible.

Common mistakes

Writing a custom string such as "Open Source" instead of a real ID gives a scanner nothing to match. Putting two IDs on one line with a comma or slash is not valid expression syntax. Tagging a file with a license your project does not actually hold the rights to is worse than no tag.

If your repository contains generated files, decide whether the generator output should carry the tag or whether the generator template should. Either is fine as long as the answer is consistent.

For a wider view of how licensing affects your dependency list, see how to audit open source licenses.

Safeguard's SBOM and dependency scanning can inventory what you ship, and you can try a free scan on a repository to see the component list.

Quick check

Sources

• SPDX: handling license info

Last reviewed: 19 October 2026.