I'm not sure it's a good practice to read copyright year information from environment variables, since copyright is a static property of the authored code, and in contrast environment variables can be configured on a system-by-system basis.

Actually, the copyright is not always static. It's common to have the copyright going from some static year to current year. The use of SOURCE_DATE_EPOCH was introduced for reproducible builds which may have dynamic copyright end years depending on the build time (see https://reproducible-builds.org/specs/source-date-epoch/ and #3451).

YYYY - current feels like a static declaration to me. I'm not a lawyer/attorney, and could be mistaken. The metaphor I think of is an artist signing their work when it's complete (or after each time they make an edit, if we adjust the metaphor for software). For the copyright notice on that artwork to be somehow adjustable by the end-user doesn't seem to me to be inline with the intent of copyright law.

What I meant is that there are configuration files where the copyright value is dynamic and may change depending on when you build the configuration. With reproducible builds, you want it to be the same, independently of whether you are building it today or in 1000 years.

Maybe I am misunderstanding your point, but Sphinx is incorporated into workflows where the copyright is declared as something like '2010 - %s' % time.strftime('%Y'). However, if you want a reproducible build, you need to fix this dynamic value. The purpose of SOURCE_DATE_EPOCH is to statically fix some values (although they may be wrong at the time you are checking your reproducible build). More precisely, you want a build where the output looks as if the build had happened instantly at the time specified in that timestamp.

By the way, SOURCE_DATE_EPOCH is not really meant for "normal" end-users but more for distribution maintainers (so it's still at a lower level for me).

Ok, yep. I was being stubborn; basically I question the robustness of dynamic copyright statements - I think that instead, they should be static, human-written statements about a work. But since they do exist, and because I'm not a lawyer, we should fix any bugs in the behaviour of them. So I'll step aside from this.