Add Copyright License Is Now Available in the GitHub Marketplace

Add Copyright License is now available in the GitHub Marketplace.

I built this GitHub Action to solve a small problem that becomes a large, boring problem surprisingly fast: keeping copyright and license notices consistent across an entire codebase.

Adding one header by hand is easy. Adding it to hundreds of files, using the right comment syntax, skipping ignored files, and avoiding duplicate notices is exactly the kind of repetitive work automation should absorb for us.

The action is available in the GitHub Marketplace here:

Add Copyright and License

What It Does

The action scans a directory and adds the appropriate copyright and license information to supported source files.

It includes:

• Support for 700+ current SPDX license identifiers
• Automatic comment-style selection for 15+ programming languages
• Detection that skips files with a current copyright notice
• Support for .gitignore and common configuration-file exclusions
• An optional working directory for monorepos or targeted updates
• Monthly license-data updates from the official SPDX License List Data repository

In other words, you define the ownership and license once, then let the workflow apply those rules consistently across supported languages and directories. That keeps the licensing decision visible in the workflow and reduces the chance of files being missed during manual updates.

Add It to a Workflow

Create a workflow in .github/workflows/add-copyright.yml and add the following job:

name: Add copyright and license headers

on:
  workflow_dispatch:

jobs:
  add-copyright:
    runs-on: ubuntu-latest

    steps:
      - name: Check out the repository
        uses: actions/checkout@v4

      - name: Add copyright and license headers
        uses: CoderRob/add-copyright@v1
        with:
          name: "Your Name or Organization"
          license: "MIT"
          working-directory: "src"

The inputs are intentionally small:

• name is the person or organization that holds the copyright.
• license is a valid SPDX license identifier, such as MIT, Apache-2.0, or GPL-3.0-only.
• working-directory is the directory to scan. It is optional and defaults to the repository root.

The action updates files in the checked-out workspace. From there, your workflow can inspect the diff, commit the changes, or fail a compliance check—whatever fits your repository’s trust model. I prefer keeping that policy outside the action because silently committing code is a very different permission boundary from editing a workspace.

Why SPDX Identifiers?

License names have aliases, abbreviations, and enough punctuation variants to turn a simple string into an argument.

SPDX identifiers give tools and people a shared, machine-readable vocabulary. Apache-2.0 means one specific license. GPL-3.0-only also makes an important constraint explicit: version 3 only, rather than version 3 or a later version.

That precision matters. Licensing is not a great place for “the tool probably knew what I meant.”

Use It Where the Code Lives

For a repository with separate frontend and backend directories, you can run the action once for each boundary:

- name: License frontend source
  uses: CoderRob/add-copyright@v1
  with:
    name: "Your Organization"
    license: "MIT"
    working-directory: "frontend"

- name: License backend source
  uses: CoderRob/add-copyright@v1
  with:
    name: "Your Organization"
    license: "Apache-2.0"
    working-directory: "backend"

This is useful when a monorepo contains projects with different ownership or licensing requirements. The boundary stays visible in the workflow instead of being buried in an elaborate script that only one brave maintainer understands.

A Small Guardrail With Practical Value

Copyright headers do not replace choosing the correct license, keeping a root license file, or getting legal guidance when the stakes require it. This action is an automation tool, not a tiny YAML attorney.

What it does provide is consistency. Once you have made the licensing decision, the action helps apply that decision across the codebase without asking someone to remember every file, language, and comment style.

You can install it from the GitHub Marketplace, or review the documentation and source code at CoderRob/add-copyright.

If it saves you from one afternoon of manually repairing headers, it has done its job.

Hope it helps you.

-Rob