Update Python Software Foundation Copyright Year.

[orsenthil]

Make it current.

I searched for \d+ Python Software Foundation. and selectively updated where it made sense.

[willingc]

Perhaps on these where the source was a single year, it should convert to 2004-2017

[Carreau]

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.

[brettcannon]

Maybe change this PR to strip the date range from the first one and leave the other alone? @VanL can you weigh in?

[willingc]

Might wish to look at the conversion from a single date.

[gpshead]

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.

[Carreau]

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.

[orsenthil]

@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.

[zware]

@benjaminp, you have historically done the copyright update, what criteria have you used?

[warsaw]

Here's what I use to bump my copyright years. Feel free to beg, borrow, or steal.

https://gitlab.com/mailman/mailman/blob/master/copybump.py

[benjaminp]

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.)

[malemburg]

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.

[malemburg]

The change in Mac/BuildScript/resources/License.rtf is wrong (you removed 2016). Please also verify other license documents you may have touched.

[benjaminp]

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)

[orsenthil]

Acknowledge. I was suggesting we remove only the PSF Copyright lines in the internal source modules. The author ones will remain in tact.

[malemburg]

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.

[benjaminp]

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.

[malemburg]

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/

[nedbat]

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.

[orsenthil]

I have addressed the review comments.

• Aim is to be non-controversial.