| @@ -1,4 +1,4 @@ | |||
| # Copyright (c) 2004 Python Software Foundation. | |||
| # Copyright (c) 2017 Python Software Foundation. | |||
There was a problem hiding this comment.
Perhaps on these where the source was a single year, it should convert to 2004-2017
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
Maybe change this PR to strip the date range from the first one and leave the other alone? @VanL can you weigh in?
Sorry, something went wrong.
There was a problem hiding this comment.
Might wish to look at the conversion from a single date.
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@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.
|
Sorry, something went wrong.
|
@benjaminp, you have historically done the copyright update, what criteria have you used? |
Sorry, something went wrong.
|
Here's what I use to bump my copyright years. Feel free to beg, borrow, or steal. |
Sorry, something went wrong.
|
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.) |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
The change in Mac/BuildScript/resources/License.rtf is wrong (you removed 2016). Please also verify other license documents you may have touched.
Sorry, something went wrong.
|
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)
|
Sorry, something went wrong.
|
Acknowledge. I was suggesting we remove only the PSF Copyright lines in the internal source modules. The author ones will remain in tact. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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.
…--
Marc-Andre Lemburg
http://www.malemburg.com/
|
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
I have addressed the review comments.
|
Sorry, something went wrong.
Make it current.
I searched for \d+ Python Software Foundation. and selectively updated where it made sense.