Avoid claiming copyright for future years

[bmwiedemann]

Avoid claiming copyright for future years

When building today's version in 2025, it should not say Copyright (c) 2003-2025, The Open MPI Community
because nobody did any work in 2025 (yet).

[github-actions]

Hello! The Git Commit Checker CI bot found a few problems with this PR:

e405ded: Avoid claiming copyright for future years

• check_signed_off: does not contain a valid Signed-off-by line

Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks!

[jsquyres]

I'm not sure I understand -- how does dynamically getting the current year via datetime.datetime.now().year return 2025?

[rhc54]

I'm also puzzled, though for a different reason. In openpmix/openpmix#3112, the change was rather different - it allowed an envar to overrride the date to get a reproducible build. As I noted there, one could pass a future year in the envar.

So which do we really want - a fixed date, the current date, or an envar override of the current date?

[jsquyres]

Per @rhc54's comment, I agree: I would prefer something like https://github.com/openpmix/openpmix/pull/3112/files. I.e., I'd rather use the automated date from today (vs. a hard-coded date), but let someone override it with an env variable if desired.

[bmwiedemann]

how does dynamically getting the current year via datetime.datetime.now().year return 2025?

When the system date is set to 2025 - e.g. I use the kvm -rtc base=2025-01-01T01:01:01 parameter for my tests, but you can also use date --set= or just wait 2 years. The effect is always that it claims a 2025 copyright for the 2023's version, which IMHO is a bug.

[rhc54]

When the system date is set to 2025 - e.g. I use the kvm -rtc base=2025-01-01T01:01:01 parameter for my tests, but you can also use date --set= or just wait 2 years. The effect is always that it claims a 2025 copyright for the 2023's version, which IMHO is a bug.

I guess I'm puzzled. If we use the envar to override the system clock, we can do the exact same thing that you describe here. So it seems to me that the only real solution is to hardwire the date - which is not the solution you requested in https://github.com/openpmix/openpmix/pull/3112/files.

You do, therefore, seem to be contradicting yourself 🤷‍♂️

[jsquyres]

The point is probably not invalid, however, that we just claim copyright in whatever the current year is. E.g., if we release version A.B.C in year X, but a user builds the tarball 3 years, later, the claimed copyright will be X+3.

We should probably do something to hard-code the copyright year during make dist.

[rhc54]

Yeah, I agree - though I would think we would only set the copyright when someone actually modifies a specific file? Most of us do that automatically when we commit. If we do it that way, then we can simply remove the code that injects a year into the files and leave them as-is.

My point was just that whatever we do, we should be consistent across our various projects to minimize confusion.

[jsquyres]

Yeah, I agree - though I would think we would only set the copyright when someone actually modifies a specific file? Most of us do that automatically when we commit.

This PR is specifically about the copyright that is emitted in the docs. I think it would probably be "good enough" to hard-code the year in the docs when the release is actually made (i.e., when make dist or related command is executed).

[rhc54]

Yeah, I agree - though I would think we would only set the copyright when someone actually modifies a specific file? Most of us do that automatically when we commit.

This PR is specifically about the copyright that is emitted in the docs. I think it would probably be "good enough" to hard-code the year in the docs when the release is actually made (i.e., when make dist or related command is executed).

Works for me! I doubt it makes that much difference either way. Should probably allow the overwrite of the date by envar like we do for the rest of the code base for consistency, which means that the PR used in PMIx is probably the right one (and not this change).

[github-actions]

Hello! The Git Commit Checker CI bot found a few problems with this PR:

51682c1: Avoid claiming copyright for future years

• check_signed_off: does not contain a valid Signed-off-by line

Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks!

[bmwiedemann]

Was there some progress towards not claiming copyright for "current" year automatically?