Update copyright date to 2012

[Carreau]

Well, everything in title.
I don't think it has a lot of chance to conflict with anything else.

[jdmarch]

why not 2008-... ?

[minrk]

2010 is probably correct - this file didn't exist in 2008, and the copyright was probably just copied from another file.

[jdmarch]

Otherwise, looks clean.

[minrk]

Thanks, looks good enough for me.

Aside @fperez - Is there any better way that we can express this so we don't have to change the copyright dates in every file every year? That seems incredibly pointless. Something like (C) IPython Development Team, and let dates derive from git log?

[fperez]

I really don't know: I've always seen copyright notices with explicit years, though we obviously let them lapse occasionally and it's no big deal. I've simply followed the tradition I've seen. But looking up online a bit just now, revealed this. Citing the relevant section here from the US Copyright Office in case that link goes down:

Visually Perceptible Copies

The notice for visually perceptible copies should contain three elements. They should appear together or in close proximity on the copies. The elements are:

    The symbol © (the letter C in a circle), or the word “Copyright,�? or the abbreviation “Copr.�?; and
    The year of first publication. If the work is a derivative work or a compilation incorporating previously published material, the year date of first publication of the derivative work or compilation is sufficient. Examples of derivative works are translations or dramatizations; an example of a compilation is an anthology. The year may be omitted when a pictorial, graphic, or sculptural work, with accompanying textual matter, if any, is reproduced in or on greeting cards, postcards, stationery, jewelry, dolls, toys, or useful articles; and
    The name of the owner of copyright in the work, or an abbreviation by which the name can be recognized, or a generally known alternative designation of the owner. Example: © 2004 Jane Doe

Based on that information, we could instead remove all ending dates from all notices, and leave only the beginning years. That would actually be nice, since it would mean never updating these things again :)

I'm +1 for changing things to removing the end years from every notice, based on this.

[jdmarch]

Verging on bike-shedding, but FWIW -- first publication of what?

My lay interpretation of this, and longtime practice, has been that the copyright year in a source file is updated when and only when the source is modified. Thus 2008-2012 would mean that the file contains some code first published in 2008, some code first published in 2012, and possibly some code first published in between.

It seems unlikely that a revision constitutes a "derivative work" or "compilation".

[fperez]

I suspect in a strict interpretation you're right, @jdmarch. But given that copyright exists regardless of registration, we're probably OK if we only put the year of file creation and let things be after that... In reality, the ultimate arbiter of copyright in an open source project would have to be the version control log. I'd be comfortable with leaving only the first year on the files, which has the advantage of being vastly simpler to maintain in the long run.

[minrk]

I think @jdmarch is right, that the dates are all start dates - for the various parts of the file (i.e. it should not say 2012 on a file that hasn't been edited this year).

But the copyright is not actually affected in any way by what we write in the notice, so I would just keep at most the file creation year, and let people ask git about the individual snippets, which are necessarily newer than that date. Otherwise, I would leave the date out altogether, and put a single X-Y date in a top-level file.

I think individual file copyright/license is a stupid practice in general - it's like putting copyright notice on every page of a book, but it is standard.

[fperez]

So if we're all OK with the idea of leaving only start dates everywhere, then we should instead close this PR (sorry @Carreau :) and have one that removes the -END parts from all files, if somebody wants to spend the time... And as we said above, for anybody who is genuinely curious, there's always git log.

[jdmarch]

Legal squinting aside, start year sounds good to me.

[ivanov]

i'm -1 on making sweeping changing like this across the whole codebase in one go. I'd prefer it if we slowly integrate the start-year-only proposal into individual files as we work on them for other reasons. If a file hasn't been touched for a long time, there's no reason to update its copyright now. This, to me, is similar to not having commits that just PEP8 the entire codebase in a bunch of places as one giant commit - whereas fixing PEP8-related things in a particular file of that you're changing in order to fix a bug or add a new feature is totally fine.

[minrk]

@ivanov's proposal sounds sensible to me:

If you touch a file, feel free to edit the copyright to include this first year only copyright edit, if it has X-Y format.

A sweeping copyright fix is less problematic than pep8, because it doesn't touch the code with meaningless changes, but it does touch the file's history in general.

[fperez]

+1 on that too. I agree that big commits that touch everything tend to create more noise than they're worth (and they often make things like rebases and cherry-picks trickier). So let's close this one and go with the above approach moving forward.