Update copyright headers to 2017 (master)

[SammyK]

I hope I got them all. :)

[krakjoe]

I'm pretty sure you need to target as low as 7.0 ... and it looks like different patches will be required for 7.0 and 7.1, and possibly master ...

Sorry about that ... thanks for the effort ;)

[SammyK]

Hey @krakjoe! So this one is still good and I just need to do another one for 7.0 and 7.1, right? :)

[krakjoe]

Before you spend any time on other PR's, it may be prudent to wait for someone else to get involved in the conversation ... I'll summon some more humans ...

[staabm]

according to the "jquery lawyers" those dates are not required:
jquery/jquery#1983 (comment)

dropping them would make maintenance way easier.

[krakjoe]

I think we are too poor for lawyers ... don't even know who to ping about that ... if anyone knows, begin pinging ...

[Danack]

The copyright information is more accurately encoded in the git commit logs. These are accurate per line, which will make all the difference in 2100, when a function edited in 2015 will enter the public domain, but a function last edited in 2016 will only enter the public domain in 2101.

btw it is slightly bogus to put a copyright notice of 2017 on a file that has not had any copyrightable changes to it this year. Although it's unlikely any harm would come from it, someone could argue that it's acting in bad faith, and use it as a bizarre rationalization for why they should be allowed to ignore the copyright entirely.

[evert]

This depends on your jurisdiction, but at least in US copyright law it's not needed anymore. Some details here:

https://www.copyright.gov/circs/circ03.pdf

I think updating the year every year is unneeded and frustrating. It messes with merges across branches and adds a completely unneeded commit in the history of every file.

But even if we were following pre-1989 rules, it can still be argued that the entire PHP source is the 'copyrighted work' and not every individual file. In that context, you still only needed to put the copyright in one file. You can argue that it would be similar to putting copyright information on every page in a book.

btw it is slightly bogus to put a copyright notice of 2017 on a file that has not had any copyrighted changes to it this year. Although it's unlikely any harm would come from it, someone could argue that it's acting in bad faith, and use it as a bizarre rationalization for why they should be allowed to ignore the copyright entirely.

This depends on if you consider the entire project the 'copyrighted work' or every individual file. But in either case it's a moot point. Putting an inaccurate year there does not change anyones rights to the work.

Disclaimer: Not a lawyer

[KalleZ]

Hi @SammyK , happy new years to you!

@krakjoe recently merged a PR, so there is a new file in master for your PR: main/explicit_bzero.c

[SammyK]

Happy new year @KalleZ! :) Resolved conflict and updated date in new file. Should I send another PR to 7.0 and 7.1 branches?

[krakjoe]

I hadn't forgotten about this, I got in touch with some lawyers to determine if date ranges are really necessary ... no reply yet.

There is no real harm in merging it this time, but making several thousand changes, touching every source file in the repo at the start of every year is not at all appealing, and seems worth avoiding if modern applicable copyright law will allow it.

[madorin]

My vote is to remove at all years from headers, leaving just "Copyright by" text, and keep the year updated just in License file.

Some cuts from this document: https://www.copyright.gov/circs/circ03.pdf

1. U.S. law no longer requires the use of a copyright notice, although placing it on your work is often beneficial.

2. The notice must consist of the symbol © (the word “copyright” or the abbreviation is not acceptable), the year of first publication, and the name of the copyright proprietor

It's frustrating when tracking a file for some changes in Git you have a lot of "year" updates.

[krakjoe]

The long and the short of it is this:

We have to bear in mind all the time that the audience for PHP is a global one, covering, in effect, all jurisdictions on the planet.

We could place the copyright notice in a global place in the repository, however, this leaves open the defence of ignorance. While ignorance is not a defence in criminal cases, it can be a valid claim to innocence in IP cases in some jurisdictions: Should the source code and copyright notice be separated from one another for whatever reason, you have the basis of a valid claim to innocence based on ignorance. To cover yourself against this, you are supposed to have a copyright notice in the header of each file, as we do have. However, the copyright notice is not meant to blindly use a range of dates, but is supposed to contain fine grained information, only mentioning the dates/years the file was changed, and where applicable who made the change.

When the JQuery project took the decision to remove the copyright year from their headers, they were not wrong to do that, but the difference is that they have lawyers to defend their IP and we do not. Our only defence is to try to cover all bases by adding individual notices into each source file.

Our only saving grace is that should we ever need to defend the IP of the project, the VCS may provide the kind of fine grained information about changes to individual files that we may need.

All of this means that we have little choice but to continue as we are, however questionably effective and inconvenient that would appear.

@SammyK please can you open a PR for 7.0 and 7.1, in addition it would appear that updating the copyrights in 5.6 is also required, although I'll defer to a release manager of the 5 series to do that merge.

[krakjoe]

Merged c8aa6f3

Thanks.

[cmb69]

Please note that ext/calendar/calendar.c is encoded in "Latin-1", and must not be converted to UTF-8; otherwise parts of the Calendar extension would break.

[SammyK]

Thanks for doing all that research @krakjoe! I'll get those PR's rocking in just a bit. :)