Day after New Years Day 2025, I saw a PR opened on a project I maintain. For historic reasons the hubotio/hubot project has a copyright statement with a date range, ex "Copyright 2011-2024, Github Inc".
Lots of projects have this format in their licensing, and I question if it's useful. I do not believe it has meaning - the project copyright wouldn't lapse if we missed updating the year, would it? I believe that in some media the second date signals that the last date that the work was substantitively modified (say, you re-edited and re-released a book text).
With an open source project, the change history of the project is highly visible, and a license date may even be less accurate than the commit history already visible. It's also a weird (to me) duplication, a kind of manual last-modified date that by being updated ensures the document has a last-modified date anyway.
I think projects would be better off dropping the end date. Your commit history should show when the project was modified, but doesn't need to show trivia like "Updated copyright year"; this is extra work for your contributors, and can be additional cognitive load[1] for anyone working with your codebase.
Your project probably don't need additional MRs/PRs that make trivia changes, unless they serve some other purpose. Trivia changes might be useful as new contributor practice tasks, but if that's the aim, you won't want a once-a-year ritual for it.
Worse, if your project includes copyright in each file (as GNU.org's GPL guidance recommends[2]), it is increasingly hard to discern meaningful changes in a file's history from trivia updates. I think GNU.org's advice is impractical here for most projects, and jurisdictions vary anyway.
Anyway - back to the PR opened on Hubot. I saw the PR, and thought "huh, why do we still have this copyright range here". The PR description said,
Yearly copyright bump. Padding my changed LOC! 😛
Uhoh. And yep, looking at the contributor's history, the account had no commits prior to this date, and had 1.5K similar open PRs across a bunch of projects ... 🙄 ... I searched for patience ... Perhaps they think it's helpful - but they do know what they're doing; they were capable of automating thousands of PRs, from a fresh Github account. I commented on the PR noting the user's PRs to other projects, suggesting that we should drop the end date instead. Joey closed the PR. Good.
Thing is, even if it was entirely well intentioned, this action probably wasted the time of hundreds of people. Even if they did no more than scan the email to decide whether it was worth their attention, that time cost in making bulk PRs multiplies out across hundreds or thousands of volunteers. Many of the PRs would be ignored, but even then it stacks up in the PR queue for that project, and will add to friction for future maintenance.
So, my messages:
- Please don't make bulk contributions without a lot of care. I fully support new contributors making tentative PRs, even trivial ones, if they feel they are contributing something meaningful. I do not have patience for automated activity that is low-value and disregards related volunteer labour costs[3].
- If you maintain a project and have a "Copyright 2020-2024" which needs updating right now, consider removing the end date. If it's not useful to your project, removal may eliminate a busywork task for the future, and reduce cognitive load for developers.
- If your project is languishing and only getting that annual license year update, perhaps stop by the oasis of No Maintenance Intended while you're at it. Nothing stopping you setting it down and picking it up again later :)
None of this is legal advice.
I probably don't live in your jurisdiction anyway.
Some prior art - years back in the CiviCRM project, we discussed (dev/core#878) and agreed to simplify the copyright headers including removing the year ranges - there was a long-form GPL license in each file's header with dates that required periodic updates. Simplifying the license in the files removed 47K of license text across 3.2K files (⚠️civicrm/civicrm-core#15843), making it much, much easier to read through future changes to any given piece of code's history by eliminating a class of changes which were not significant. ↩︎
I see that GNU.org's GPL HOWTO advises to introduce a year marker in the copyright for each release (guidance which I question, but I'll include here as it may explain why this pattern is widely observed).
The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each past release; for example, “Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.
↩︎
For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage.What happened to that account and its PRs? I see today that the account, and almost all history of its activity (except signing this CLA! conda/infrastructure#1087), has been eliminated from Github. That's why this post mostly lacks URLs for the PRs and activity discussed. There's some mentions of their activity elsewhere. ↩︎