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)
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+
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 #418601 - Flags: approval184.108.40.206?
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.
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 220.127.116.11, a=dveditz for release-drivers
Attachment #418600 - Flags: approval18.104.22.168? → approval22.214.171.124+
Comment on attachment 418601 [details] [diff] [review] CVS Approved for 126.96.36.199, a=dveditz for release-drivers
Attachment #418601 - Flags: approval188.8.131.52? → approval184.108.40.206+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
status1.9.1: --- → .8-fixed
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
> 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.
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.
Attachment #418600 - Flags: approval220.127.116.11? → approval1.9.2+
status1.9.2: --- → final-fixed
'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.
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?
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... :)
Looks fine on 1.9.1 and 1.9.0. No results can be found. Marking as verified fixed.
Keywords: fixed18.104.22.168 → verified22.214.171.124, verified1.9.1
You need to log in before you can comment on or make changes to this bug.