Continuous integration: SOURCE_DATE_EPOCH and testing

[kpcyrd]

On 1/9/25 2:28 AM, James Addison via rb-general wrote:
> A recent change that I made in the Sphinx codebase, related to
> copyright notices and SOURCE_DATE_EPOCH, has caused unit test failures
> during package builds for a couple of Linux distributions.  Although
> the precise details aren't germane to my posting this thread, please
> let me know if you'd like more information and I'll be glad to
> explain.

This test is likely asserting incorrect assumptions about copyright law 
and probably shouldn't exist in the first place:

https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code

There's an explicit section about this:

 > (!) Do not bump the year during build time
 >
 > Bumping the year manually is bad, but automating year bumping during
 > build time is taking it to another level!
 >
 > One could argue – and I suspect this is where it originates from –
 > that since compiling is translation and as such an exclusive right of
 > the copyright holder. But while translation from one programming
 > language to another clearly can take a lot of mental effort and might
 > require different ways how to express something, a machine-compilation
 > from human-readable source code to machine-readable object/binary code
 > per se is extremely unlikely to have added a new copyrightable
 > component into the mix. That would be like saying an old song would
 > gain new copyright just because it was released in a new audio format
 > without any other changes.
 >
 > Bumping the year during build time also messes up reproducible builds.

"reproducible builds" is hyperlinked to a fediverse post by vagrantc on 
compiling "by definition" not being copyrightable creative work.

The reasonable choice for sphinx is probably not making any claims about 
copyright unless explicitly set in a config file. My binaries don't have 
copyright claims compiled into them either, yet I believe the GPL still 
holds for them.

cheers,
kpcyrd