Open Source Maintenance: Do I Need to Update My License Year?

Source: Dev.to

If you’ve been maintaining a project since 2019 and have reached a milestone like v5.x, you might wonder whether the “2019” in your LICENSE file makes your project look abandoned. Here’s a quick guide on handling license dates effectively without overthinking it.

License year best practices

In an MIT or Apache license, the year (e.g., Copyright (c) 2019) marks the year of first publication.
Instead of choosing between the start year and the current year, the professional standard is to use a range.

• Bad: Copyright (c) 2019 – looks abandoned.
• Better: Copyright (c) 2026 – wipes out the history of the original work.
• Best: Copyright (c) 2019‑2026 – preserves the original v1.0 and the current v5.x.

If you follow Semantic Versioning, you don’t need to touch the license for every patch.

When to update the license year

Automating license updates

If manual updates feel tedious, you can use a GitHub Action to check your license at the start of every year.

FantasticFiasco/action-update-license-year will handle it for you.

name: Update copyright year(s) in license file
on:
  schedule:
    - cron: '0 3 1 1 *' # 03:00 AM on January 1
jobs:
  update-license-year:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - uses: FantasticFiasco/action-update-license-year@v3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

This action will detect your 2019 start date and automatically transform it into 2019‑2026, keeping your project looking active and professional.

Updating the license header manually

For a project spanning several years, simply update your license header to:

Copyright (c) 2019-2026 [Your Name]

This tells the world your project is established, battle‑tested since 2019, and actively maintained in 2026.

Note: my personal blog.