I’ve been railing against automated copyright dates for years but just learned Serine Molecule scooped me in Copyright Notices Are Not Clocks:
You should update the copyright year whenever you make nontrivial, copyrightable changes to your work. Not every year, and definitely not automatically. If you do it automatically, you are lying to your users, and lying is unprofessional, and I would not recommend it.
Or maybe technically we scooped them, but you had to view our html source or read an anfractuous forum thread to find it. Also I didn’t actually intend for it to be a very serious argument at the time and only gradually took my own argument seriously and started thinking of automated copyright years as literally dishonest.
The way it first came up is users would start telling us in January or February that our copyright date still said the previous year, like they were telling us about a glob of spinach on our teeth. Sometimes they would helpfully offer to show us how to display the current year dynamically. We debated it and my argument was this:
i can’t tell what fraction serious i am about doing it manually. i guess if, counterfactually, we ever weren’t at the wheel it would be lies and that feels icky. like there’s something inherently dishonest about literally being like “copyright… uh, whatever year it is when you’re reading this!”
Which is exactly Serine Molecule’s point and it now seems almost obvious so I’m a little embarrassed that I only took myself half seriously at the time (though seriously enough to never assent to automating it at least!).
We also joked about what the cynical, slytherinly optimal way to handle copyright dates was and how setting it to the current year was actually a dead giveaway that you’d automated it.
Instead you could do
year(now-random(5,10)*86400) — simulating a fairly attentive human at the wheel updating the copyright 5-10 days after new year’s.
Stripe.com and the primordial dialogical sea
Interesting side note that was the other reason we thought to blog about this now: our most-worthy-of-emulation-ever website, Stripe.com, is, as of this writing, 12 days after new year’s, still saying copyright 2022. So we’re hopeful that automating the copyright year has finally become uncool. Also, if you’re curious to see our whole dialog debating this, here you go:
The dialog, circa 2017
dreev: boo to automatically filling in copyright! that’s how we prove we’re still at the wheel :)
andy: it only proves that if it’s publicly visible how the copyright is being created
andy: like if beeminder were open source. otherwise no one can tell the difference
dreev: actually i think when the copyright changes at a random time in january, that’s a good signal that you’re at the wheel…
dreev: if it changes at the stroke of midnight then obviously you cheated and could all be dead or on a beach somewhere
bee: but everyone cheats
bee: so it can only be an indicator in our absence
dreev: boo to cheaters
adam?: it’s the best way to score GitHub points too: open2017->2018pull requests
andy: but who is going around checking exactly when copyrights change??
andy: bots, that’s who
andy: okay nevermind I’m on board with this as a precaution to confuse future overlords
bee: anyhow, it also makes us look stupid. like we don’t know how to use string format, and causes people to write us emails like “Umm. so your copyright is out of date. I don’t know what language you guys use, but in php it’s really easy you..”
andy: maybe that’s a positive, identify users who can write code
andy: “oh, thanks! here’s another nerd sniping problem. can you rewrite beebrain?”
dreev: clearly the optimal solution is to set it toyear(now-random(5,10)*86400):)
dreev: (simulates a fairly attentive human at the wheel updating the copyright 5-10 days after new years)
dreev: i can’t tell what fraction serious i am about doing it manually. i guess if, counterfactually, we ever weren’t at the wheel it would be lies and that feels icky
dreev: like there’s something inherently dishonest about literally being like “copyright… uh, whatever year it is when you’re reading this!”
bee: ok, so part of the checklist for shuttering beeminder is “update footer copyright date”
bee: you clearly didn’t understand my argument for why we’re doing this, because you seem to remain unconvinced. go read my email again and then i’m putting you in timeout so you can think about what you’ve done.
dreev: [pastes this in the html source [1] so we can show it to people in<%=(Time.now+86400*365.25).strftime('%Y')%>who see “<%=Time.now.strftime('%Y')%>” and think we don’t know how to insert a dynamic date]
PS: Bee’s argument in the email with the user who called us out:
I think Danny had some convoluted reasoning for why we shouldn’t just make that programmatic, like “it’s a signal that the site is still active”, but I think that’s kind of incorrect — anyone writing a website can make the copyright date be programmatically generated, so it doesn’t actually serve as any indicator of currency, it can only serve as a anti-activity signal by going out of date.
Anyway, in terms of signals that we’re alive, we have UVIs which are a bright signal that we’re actively making changes and improvements. And in practice we deploy new code several to many, many times in a typical week. So what we decided, as of today, is to automate getting the date-of-last-deploy in our site footer. Now the use-by date on your carton of Beeminder is exquisitely up to date. No sour milk surprises for you. It looks like this:
(That last bit is the git SHA prefix, basically a unique identifier of the latest commit to our source code repository.)
Footnote
[1] The version in the actual Ruby source, which I’ve reproduced here, makes slightly more sense than what you see in the html source since the html source macro-expands the macros being talked about! Fun philosophical case study for the use-mention distinction perhaps.