-
Notifications
You must be signed in to change notification settings - Fork 167
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
Bump copyright year to 2025 #4514
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is needed in general, and we likely should reconsider how we list the years to reduce the work in the future.
First and foremost copyright according to the Berne convention, https://en.wikipedia.org/wiki/List_of_copyright_duration_by_country is 50 or more years (70 in EU, Australia, Canada, Japan, and the US) after the author's death; so I don't see that updating the publication year matters.
Additionally some claim that one should only bump the year when there are actual changes.
One possibility would be to remove copyright from non-top .mo files, but keep them in the top ones and in other files. For the other files we could either bump them now, bump them when changed, or remove the end-year.
You are probably right. I just did as we did the previous 25 years w/o much questioning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @HansOlsson . Should we even go so far as to remove the year completely everywhere? As far as I can tell (I'm not a lawyer) it shouldn't be required?
I don't have any strong opinions here, but I'm in favor of things that reduce manual work.
04b9e21
to
06a61af
Compare
Honestly, it is not much manual work at all, just search and replace. It's far more work to keep contact data up-to-date, see #4499. |
No description provided.