We used to do this at work. Then someone bumped the date in every file. I can point to PRs that copypasta'd old dates in from people who copied the notice from deeply ancient source files and claimed a copyright date ages in the past. Or files that were updated and nobody bothered to bump the date.

As a result I ripped out all the dates, with the blessing of our legal department, because they were next to useless. We've got a git history and while the dates there aren't perfectly tamper and error free, they're vastly better than all the nonsense we had our headers.

Pretty sure these dates are a software development legal cargo cult and would encourage anyone who disagrees with me to actually sit down with their legal council and go over the issues and publish a nice medium article if you think I'm wrong. And make sure to spell out issues like this one which opposing council would be sure to use where the date bumping on /bin/true is a clear violation of policy. At best it seems legally useless and at worst you've got a policy that opposing council can probably slam dunk prove that you are not following.

I’ve heard that, but I’ve also heard that the year is supposed to be updated whenever it’s published again.

But by updating the copyright year, haven't you thus changed the file's contents?

(Please read this comment as written in the same tone as the original article.)

> you're not supposed to append copyright years to a notice

It shouldn't matter because the date of actual first publication would control, not what is on one particular notice.

The date of revisions extends the copyright beyond the original cutoff date.

A later date on a subsequent publication including revisions doesn't extend the copyright term of the original material.