New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not claim copyright for future years #3710

Merged
merged 1 commit into from Jul 23, 2018

Conversation

Projects
None yet
6 participants
@bmwiedemann
Contributor

bmwiedemann commented Jul 23, 2018

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.

Do not claim copyright for future years
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

This comment has been minimized.

Member

RonnyPfannschmidt commented Jul 23, 2018

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

This comment has been minimized.

Contributor

bmwiedemann commented Jul 23, 2018

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

This comment has been minimized.

coveralls commented Jul 23, 2018

Coverage Status

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

This comment has been minimized.

Member

nicoddemus commented Jul 23, 2018

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

@nicoddemus nicoddemus merged commit b7419bd into pytest-dev:master Jul 23, 2018

1 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@RonnyPfannschmidt

This comment has been minimized.

Member

RonnyPfannschmidt commented Jul 23, 2018

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

@asottile

This comment has been minimized.

Member

asottile commented Jul 23, 2018

@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

This comment has been minimized.

Member

nicoddemus commented Jul 23, 2018

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

This comment has been minimized.

Member

asottile commented Jul 23, 2018

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

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Jul 23, 2018

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

This comment has been minimized.

Contributor

bmwiedemann commented Jul 23, 2018

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 comment has been minimized.

Member

RonnyPfannschmidt commented Jul 23, 2018

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

@bmwiedemann bmwiedemann deleted the bmwiedemann:date branch Aug 3, 2018

@blueyed

This comment has been minimized.

Contributor

blueyed commented Aug 25, 2018

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Aug 26, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment