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 isthe year of first publication of the work

the noticemay 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?

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

I generally update the ones that cover "all of Python" like the LICENSE andgetcopyright.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.

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.

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.