Fix SOURCE_DATE_EPOCH for multi-line copyright values

[picnixz]

Closes #11514

@AA-Turner When implementing this patch, I found that there is also a configuration value project_copyright which is not updated according to SOURCE_DATE_EPOCH. The copyright value is by default set to project_copyright, but should we also change the project_copyright according to SOURCE_DATE_EPOCH ? It also appears that project_copyright is never used elsewhere but is documented as an alias of copyright (which is actually not true since copyright is the one being aliased by default):

sphinx/sphinx/config.py

Lines 94 to 95 in 5cf3dce

	'project_copyright': ('', 'html', [str, tuple, list]),
	'copyright': (lambda c: c.project_copyright, 'html', [str, tuple, list]),

However, in order to make things right, we need to change the implementation of Config for the project_copyright entry, but I'm not sure whether this may break projects in general.

[jayaddison]

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.

[picnixz]

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).

[jayaddison]

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.

[picnixz]

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).

[jayaddison]

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.