Skip to content
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

Update copyright dates to 2025. #10512

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update copyright dates to 2025. #10512

wants to merge 1 commit into from

Conversation

TomBener
Copy link
Contributor

@TomBener TomBener commented Jan 7, 2025

No description provided.

@alerque
Copy link
Contributor

alerque commented Jan 7, 2025

My take would be to get of this treadmill altogether. It is not necessary to display the current year in order for the copyright to be valid, only when it was established is enough.

https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code#why-not-bump-the-year-on-change

@jgm
Copy link
Owner

jgm commented Jan 7, 2025

Thanks for the link. If it's true that significant code changes are needed to warrant bumping the copyright year range, then we shouldn't change all of these in this way; we'd need to use git or something to determine which ones should change. And certainly we aren't yet warranted in bumping to 2025 for most of these, since only a few changes have been made this year.

@alerque
Copy link
Contributor

alerque commented Jan 7, 2025

Thanks for the link. If it's true that significant code changes are needed to warrant bumping the copyright year range, then we shouldn't change all of these in this way; we'd need to use git or something to determine which ones should change.

Even more radically than that, even changes or "significant" changes don't need the copyright year bumped to be properly covered.

  1. The change would need to be significant enough to not qualify as a modification of the old work in order to need a new copyright for the new work. Short of rewriting-in-Rust nothing this project does tinkering with code from release to release needs to be considered as a whole new work that needs a new copyright.

  2. At best (and dubiously even at that) extending the date range of a copyright line is just resetting the timer on a 50 year count-down. And even if you kept bumping the copyright date every Jan 1st, at the end of 50 years it still might be meaningless unless there were substantial rewrites during that 50 years that actually made the clock start again.

Just set the copyright date once when the file is first created and forget about it for a 4 decades. If you pass the 40 year mark AND any of the initial contributors still have commit access AND there have been major rewrites/additions to the file then maybe bump it once (and check the details of your will).

For bonus points, the fact that Pandoc is GPL licenced is far far more relevant than the copyright holder, and that doesn't expire at all and does stay fresh based on each contributions origin time anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants