536124 - Update browser/toolkit copyright dates to 2010

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Phil Ringnalda (:philor)]

Attachment: hg

+++ This bug was initially created as a clone of Bug #470179 +++

+++ This bug was initially created as a clone of Bug #407635 +++

+++ This bug was initially created as a clone of Bug #365553 +++

As inevitable as death, taxes, and the lack of an hero emerging to fix bug 414939, it's time for another copyright dates bug.

Three hg branches, but one patch fits them all; CVS is horrible and covered with mange, but thank Smokey there's one less this year, since license.html lost its copy.

Comment 1

[Phil Ringnalda (:philor)]

Attachment: CVS

Should have started this earlier, so I'd have more time to beg someone to land the CVS patch for me.

Comment 2

[Phil Ringnalda (:philor)]

Comment on attachment 418600 [details] [diff] [review]
hg

Oh, interesting, can't ask for any of the three approvals I actually need, so I guess I just presume that the quick and dedicated triagers of requests will realize that January will be another year.

Comment 3

[Benjamin Smedberg]

It doesn't make sense to do this until we actually land code which was created in 2010. Why bother landing this on the stable branches at all?

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

This is not a release blocker, IMO.

Comment 5

[Phil Ringnalda (:philor)]

You cannot have useful answers to ancillary questions like "why on branches?" or "when should it land?" without first getting useful answers to the big questions, "why do we include dates at all?" and "what effect do date ranges in copyright date notices have?"

The "internet lawyer whose training is a couple of hours with Google" answer is that dates only matter when we are claiming Universal Copyright Convention
coverage somewhere that we don't have Berne Convention coverage, which I think
is Andorra, Laos, Saudi Arabia, Turkmenistan and Uzbekistan, and date ranges show no actual sign of having any meaning at all.

However, if I am right about that, then the correct response is not to say "well, then we'll take it on the trunk but not at all on this branch and only after this date on this other branch," the correct response is to say "well, then we'll remove the dates." Until you are willing to completely remove them, you are saying that they have some unspecified value, and you are then making decisions about that unspecified value based on convenience. While I'm not sure what, if any, meaning a date range has, I'm absolutely certain that there is no copyright treaty which says "for incrementally changed works, you must affix the range of years in which each incremental change was made, unless doing so is inconvenient because of when your code freezes happen."

The question of what to do when you first publish code written in 2009 on January 5, 2010, without having made any changes in 2010 other than building and publishing, might be interesting, but it's utterly unanswerable without knowing where the date ranges have any meaning.

Comment 6

[Daniel Veditz [:dveditz]]

Comment on attachment 418600 [details] [diff] [review]
hg

Approved for 1.9.1.8, a=dveditz for release-drivers

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 418601 [details] [diff] [review]
CVS

Approved for 1.9.0.18, a=dveditz for release-drivers

Comment 8

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/abbb92b0f08e

Comment 9

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a27adfe241f5

Comment 10

[Phil Ringnalda (:philor)]

browser/app/application.ini 1.16
browser/app/macbuild/Contents/Info.plist.in 1.20
browser/app/macbuild/Contents/Resources/English.lproj/InfoPlist.strings.in 1.6
browser/base/content/credits.xhtml 1.41
browser/locales/en-US/chrome/browser/aboutDialog.dtd 1.13
toolkit/crashreporter/client/macbuild/Contents/Resources/English.lproj/InfoPlist.strings.in 1.6
toolkit/locales/en-US/chrome/global/about.dtd 1.7
toolkit/locales/en-US/chrome/mozapps/help/welcome.xhtml 1.9
toolkit/mozapps/update/src/updater/macbuild/Contents/Resources/English.lproj/InfoPlist.strings.in 1.6

Comment 11

[Daniel Veditz [:dveditz]]

> The question of what to do when you first publish code written in 2009 on
> January 5, 2010, without having made any changes in 2010 other than building
> and publishing, might be interesting, but it's utterly unanswerable without
> knowing where the date ranges have any meaning.

I have no answer to the rest of it, but I assure you that the code which will see wide distribution on Jan 5 2010 was actually made available to the public far in advance of that date. Firefox 3.0.17 and 3.5.7 are available *now*, for instance, and will be given to tens of thousands of people tomorrow through the "beta" update channel.

Comment 12

[Phil Ringnalda (:philor)]

That question is actually one of the least ambiguous bits in the whole ambiguous thing: if you claim to have published in 2010 but actually publish in 2009, it's exactly equivalent to omitting the notice, which is (almost exactly) equivalent to having the notice saying you published in 2009; if you claim to have published in 2009 but actually publish in 2010, it's exactly equivalent to having published in 2009. However, that only makes a difference if you're talking about the copyright term of a "work for hire" which we are mostly claiming that the complete work, as distinct from individual source files, is not, with our "Contributors." In any case the odds that we would care about the difference between 95 years from 2009 and 95 years from 2010 are about as small as the odds that we will still care about the copyrightable changes in 3.0.17 or 3.5.7 70 years after the death of the youngest person who contributed any of them, which is far more likely to be the actual term of our copyright, whether or not any of our notices mistakenly claim it's a work for hire.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 418600 [details] [diff] [review]
hg

a192=beltzner

Comment 15

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6d13e4351efc

Comment 16

[Michael Lefevre]

'The "internet lawyer whose training is a couple of hours with Google" answer is ... the correct response is to say "well, then we'll remove the dates."'

In that case, why not file a bug on asking the actual lawyers who work for Mozilla to consider this issue, and then remove the dates if they don't seem worthwhile, thus avoiding future issues like this (and bug 414939)? The resulting advice might also be useful for other projects.

Comment 17

[Phil Ringnalda (:philor)]

If I were to do such a thing, I would probably want to put the bug in this bug's dependency tree, wouldn't I?

Comment 18

[Michael Lefevre]

Ah... yes, you probably would. You could even go back in time a couple of weeks and pretend you did it before I suggested it... :)

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks fine on 1.9.1 and 1.9.0. No results can be found. Marking as verified fixed.