Do not claim copyright for future years

[bmwiedemann]

When building today's python-pytest-doc openSUSE package
in the year 2033, the documentation .html files state
Copyright 2015-2033 , holger krekel and pytest-dev team.

That cannot be correct, because nobody did anything copyright-worthy
for this file in 2033.

See also https://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated

Additionally, this change makes the package build reproducible.
See https://reproducible-builds.org/ for why this is good.

[RonnyPfannschmidt]

the point about being reproducible is important! , thanks

however i'd like to remove the need to update the end of the year range
anyone fluent with copyright up for providing a idea

if i recall correct the start year can be used solely

[bmwiedemann]

As I understood it, copyright is automatic and the statement and year is just there to make proof easier in case you want to sue a violator for damages.

Expiry is usually 70 years after your death, so nothing you need to worry about.

[coveralls]

Coverage increased (+0.05%) to 92.655% when pulling 2e344d4 on bmwiedemann:date into f761425 on pytest-dev:master.

[RonnyPfannschmidt]

@nicoddemus i'd like to have your input as well

im going to approve since a repeatable build is the sensible/desirable thing

we may want to follow up with something to set the dates straight and to create a detail setup

[nicoddemus]

I have no idea as well. I will setup a calendar reminder to update this yearly, seems simple enough and will avoid this headaches. 😁

[RonnyPfannschmidt]

@asottile i'm wondering - would this be an interesting item for a pre-commit hook that autofixes?

[asottile]

@RonnyPfannschmidt I've had a similar idea since 2015 it seems 😆 pre-commit/pre-commit-hooks#94

In this case though, it probably makes more sense as a "copyright year update bot" which swings by once a year to spruce up the comments / years (since you probably wouldn't want a pre-commit hook to suddenly start failing: happy new year 🎉)

[nicoddemus]

Automatize a once-a-year single-digit change (or 2 em 2 years) seems overkill to me TBH. 😁

I see value though if this is a bot that open PRs for a bunch of projects once a year. Then it definitely would be nice.

[asottile]

oh yeah for sure, it would have to be something other people would use for it to be worth it 😆

[nicoddemus]

A repository which can people submit their repositories as PRs, and configure which files need updating.

A heroku account with a cron job once a year downloads that repository, and goes over all repositories opening PRs.

Heh sounds like a fun project. 😁

[bmwiedemann]

Except that you do not even have to update this yearly. Just every 70+ years.
So the bot task would be rather moot.

[RonnyPfannschmidt]

this shouldnt be a bot - this should be a hook that when using year ranges updates those ranges for users on commits, so a new pull request would include the updates

[blueyed]

The copyright year is not necessary, see http://www.contentious.com/2007/01/07/copyright-notice-is-the-year-really-necessary/ (via davidhalter/parso#25).

[nicoddemus]

Thanks for the research @blueyed. If nobody opposes, I'm OK with changing it.