Update browser/toolkit copyright dates to 2010

RESOLVED FIXED in Firefox 3.7a1

Status

()

Firefox
General
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: philor, Assigned: philor)

Tracking

({verified1.9.0.18, verified1.9.1})

Trunk
Firefox 3.7a1
verified1.9.0.18, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.6 -
blocking1.9.0.17 -
in-testsuite -

Firefox Tracking Flags

(status1.9.2 final-fixed, status1.9.1 .8-fixed)

Details

Attachments

(2 attachments)

(Assignee)

Description

9 years ago
Created attachment 418600 [details] [diff] [review]
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.
Attachment #418600 - Flags: review?(gavin.sharp)
(Assignee)

Comment 1

9 years ago
Created attachment 418601 [details] [diff] [review]
CVS

Should have started this earlier, so I'd have more time to beg someone to land the CVS patch for me.
Attachment #418601 - Flags: review?(gavin.sharp)
Attachment #418600 - Flags: review?(gavin.sharp) → review+
Attachment #418601 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 2

9 years ago
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.
Attachment #418600 - Flags: approval1.9.2.1?
Attachment #418600 - Flags: approval1.9.1.8?
Attachment #418600 - Flags: approval1.9.0.18?
(Assignee)

Updated

9 years ago
Flags: blocking1.9.0.17?
Flags: blocking-firefox3.6?
(Assignee)

Updated

9 years ago
Attachment #418600 - Flags: approval1.9.0.18?
(Assignee)

Updated

9 years ago
Attachment #418601 - Flags: approval1.9.0.18?

Comment 3

9 years ago
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?
This is not a release blocker, IMO.
Flags: blocking1.9.0.17?
Flags: blocking1.9.0.17-
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
(Assignee)

Comment 5

9 years ago
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 on attachment 418600 [details] [diff] [review]
hg

Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #418600 - Flags: approval1.9.1.8? → approval1.9.1.8+
Comment on attachment 418601 [details] [diff] [review]
CVS

Approved for 1.9.0.18, a=dveditz for release-drivers
Attachment #418601 - Flags: approval1.9.0.18? → approval1.9.0.18+
(Assignee)

Updated

9 years ago
Depends on: 536336
(Assignee)

Comment 8

9 years ago
http://hg.mozilla.org/mozilla-central/rev/abbb92b0f08e
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
(Assignee)

Comment 10

9 years ago
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
Keywords: fixed1.9.0.18
> 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.
(Assignee)

Comment 12

9 years ago
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.
(Assignee)

Updated

9 years ago
Duplicate of this bug: 537346
Attachment #418600 - Flags: approval1.9.2.1? → approval1.9.2+

Comment 16

9 years ago
'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.
(Assignee)

Comment 17

9 years ago
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

9 years ago
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... :)

Updated

9 years ago
Duplicate of this bug: 538325

Updated

9 years ago
Blocks: 540455
Looks fine on 1.9.1 and 1.9.0. No results can be found. Marking as verified fixed.
Keywords: fixed1.9.0.18 → verified1.9.0.18, verified1.9.1
You need to log in before you can comment on or make changes to this bug.