Update Python Software Foundation Copyright Year. by orsenthil · Pull Request #4 · python/cpython (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation24 Commits4 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Make it current.
I searched for \d+ Python Software Foundation. and selectively updated where it made sense.
| @@ -1,4 +1,4 @@ |
|---|
| # Copyright (c) 2004 Python Software Foundation. |
| # Copyright (c) 2017 Python Software Foundation. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps on these where the source was a single year, it should convert to 2004-2017
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually Copyright (c) <year> means <year>-present, IMHO this should stay 2004. and 2017 -> Present.
This avoid churn on file and to keep them updated.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe change this PR to strip the date range from the first one and leave the other alone? @VanL can you weigh in?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might wish to look at the conversion from a single date.
I strongly recommend NOT doing this.
I believe this has come up before, do not edit the date or otherwise turn it into a sequence or range of dates in a copyright notice in existing files. Leave the date in the file as it was originally written. It is meaningless churn at best.
http://www.copyrightlaws.com/copyright-basics/copyright-notice-year/ :
The general rule is that the year to include in a copyright notice is the year of first publication of the work
the notice may include a range of years (e.g., 2009-2013), starting from the date of the oldest published elements and ending with the date of the newest published elements.
Emphasis mine. Also the last year should be changed only if the content of the file have changed, so I would also favor the 1 year entry only.
@gpshead - you mean no to the entire change? I know this has come up earlier.
How about removing the copyright line from the modules headers altogether (when appropriate) ? It is mentioned in the README.
- For ranges which are wrong like 2001-2007 Python Software Foundation. There is no controversy, we should either remove it or update it.
- For range copyright start year. As others have pointed out, leaving it start year seems like a good idea.
@benjaminp, you have historically done the copyright update, what criteria have you used?
I generally update the ones that cover "all of Python" like the LICENSE and getcopyright.c. My preference would be removing all PSF copyright headers from internal files and rely on the repository-level ones. (Ones for contributed-and-licensed code should just be left alone.)
Please don't remove the copyright notices from the files. The origin of the code and copyright status is already hard to determine given Python's history. Removing the notices would make this even harder.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change in Mac/BuildScript/resources/License.rtf is wrong (you removed 2016). Please also verify other license documents you may have touched.
I do not believe copyright notices referring to anything but the PSF should be removed.
On Sat, Feb 11, 2017, at 05:21, Marc-Andre Lemburg wrote: Please don't remove the copyright notices from the files. The origin of the code and copyright status is already hard to determine given Python's history. Removing the notices would make this even harder. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:#4 (comment)
Acknowledge. I was suggesting we remove only the PSF Copyright lines in the internal source modules. The author ones will remain in tact.
Just like with all copyright notices, removals of PSF copyright notices is something only the PSF board can decide.
IMO, it would be better to find a short PSF notice text (e.g. one without year, so that we don't have to touch the files once every year) and add it to all files which currently do not have it, just like GNU projects do. It makes tracking copyrights much easier.
Just like with all copyright notices, removals of PSF copyright notices is something only the PSF board can decide.
We should ask them then.
IMO, it would be better to find a short PSF notice text (e.g. one without year, so that we don't have to touch the files once every year) and add it to all files which currently do not have it, just like GNU projects do. It makes tracking copyrights much easier.
Not having copyright headers distributed around the entire sounds easiest to me. It's also not clear to me that adding a copyright header to every cpython source file would be correct, since contributing to Python does not require copyright assignment.
On 13.02.2017 08:25, Benjamin Peterson wrote: > IMO, it would be better to find a short PSF notice text (e.g. one without year, so that we don't have to touch the files once every year) and add it to all files which currently do not have it, just like GNU projects do. It makes tracking copyrights much easier. Not having copyright headers distributed around the entire sounds easiest to me. It's also not clear to me that adding a copyright header to every cpython source file would be correct, since contributing to Python does not require copyright assignment.
It would be correct for all files where the PSF does have the copyright (we do have copyright assignments for quite a bit of code as well), but I see your point. Trying to do this correctly will be a project on its own.
For the main README file: the long list of years is in the file twice. Surely we don't need to state it twice. Let's get rid of the one at the top of the file, which is just clutter preventing people from reading the file.
I have addressed the review comments.
- Aim is to be non-controversial.
nanjekyejoannah added a commit to nanjekyejoannah/cpython that referenced this pull request
7: Add warnings for sorting and comparison r=ltratt a=nanjekyejoannah
Most of the warnings are covered on the list sort method.
I added the missing warnings for the cmp and __cmp__ method.
This replaces python#4
Co-authored-by: Joannah Nanjekye jnanjekye@python.org
jaraco pushed a commit that referenced this pull request
nanjekyejoannah added a commit to nanjekyejoannah/cpython that referenced this pull request
5: Add 2.x related warnings r=ltratt a=nanjekyejoannah
I have broken away the warning bit from the flag and the port PR. Well, the way function calls are done between C and Python is confusing, nothing scary anyway, review maybe a bit annoying.
Review this PR before python#4
Co-authored-by: Joannah Nanjekye jnanjekye@python.org
nanjekyejoannah added a commit to nanjekyejoannah/cpython that referenced this pull request
7: Port cmp with no extra slot r=ltratt a=nanjekyejoannah
Due to segfaults introducing a new tp_compare slot proved problematic. I have found a way of supporting cmp without a new slot. Tests are updated to match the new functionality where Py2.x doesn't fail.
I wanted to force push on [this branch] (https://github.com/softdevteam/pygrate3) but maybe you wanted to compare before I force push.
This replaces python#4
Co-authored-by: Joannah Nanjekye jnanjekye@python.org
barneygale added a commit to barneygale/cpython that referenced this pull request
This was referenced
Feb 11, 2025
Reviewers
