Back around the dawn of time, at the end of the bug 236613 relicensing, gerv changed http://mxr.mozilla.org/mozilla-central/source/LICENSE from being MPL/NPL to a paragraph saying you should look at toolkit/content/license.html instead. That broke the SeaMonkey installer (in some way I've forgotten, maybe it showed it as a EULA), so it was reverted. Now, even though the SeaMonkey installer is dead, long live the toolkit installer, we still have a MPL/NPL license file, which Firefox successfully ships in packaged binaries on Linux and Windows, and tries but fails to ship on OS X. Possible solutions, in descending potential for making me happy: * Decide that the paragraph of text in the source tree, not shipped in binaries, was the right thing, and make it happen by stopping apps from copying it around (I know Firefox does, as LICENSE, I think last time I looked SeaMonkey also did, as LICENSE.txt) and changing the file back to the paragraph of text it was for a little while * Decide that a paragraph of text is the right thing, but that it should also be shipped with binaries, and write it so that it works whether or not "in toolkit/content/license.html" could possibly make sense based on where it's being read * Decide that shipping a LICENSE doc is the right thing, and make it less ugly by making it a proper trilicense doc instead of MPL/NPL, and make it actually wind up being shipped on OS X

Official release builds of (I think) all Mozilla projects are now released with the MPL as the EULA. Therefore, having this file contain only the MPL has become the correct thing. Gerv

In which of its contexts? Mac Firefox has broken packaging, but yeah, /Applications/SeaMonkey.app/Contents/MacOS/license.txt is an MPL/NPL which is sort of vaguely appropriate other than the NPL, but does that make it right to have hg clone http://hg.mozilla.org/mozilla-central && cat mozilla-central/LICENSE also be an MPL/NPL? Clearly at the time that you changed it to say "Please see the file toolkit/content/license.html for the copyright licensing conditions attached to this codebase" you believed that mozilla-central/LICENSE ought to refer to the code license, rather than being the source for the LICENSE file for any or all apps (which, since changing filenames is easy, could just as easily come from /mpl-for-binaries.txt). So, rather than the solutions, the questions that we have to answer to choose a solution: Do we have to have a MPL /LICENSE file in binaries? If we don't have to, do we want to? (Firefox is trying but broken, Thunderbird isn't even trying, so have to/want to/don't care matters for the severity of those bugs.) Do we have to have a /LICENSE file in the source? If we don't have to, do we want to? If we want to, what would it say?

The source licences are canonically defined in about:license (or the equivalent in Thunderbird and the other apps; I believe they all have them now). The binary licence is the MPL, again I believe for all apps. > Do we have to have a /LICENSE file in the source? Would it be easier if we just removed it? :-) Remind me again: what would break if we just changed it to say roughly what the two paras I just wrote say? Anything, now? Gerv

Right now, the result would be that C:\Program Files\Mozilla Firefox\LICENSE and, um, wherever we end up installing Firefox on Linux/LICENSE would have your two paragraphs about the source license and how you should look in toolkit/content/license.html, which doesn't exist in binaries. Seamonkey would continue to have their license.txt with the bogus MPL/NPL, since they actually forked that into comm-central/suite/installer/license.txt. Easy? Easy would be saying "we do not need to ship a LICENSE file in binaries, people who want to know about the license can run the app, let's stop doing so." Then I could remove Firefox's broken attempt to do so, and we can change /LICENSE to be a picture of a bunny with a pancake on its head, and if we feel like it we could point out to SeaMonkey that they are shipping an MPL/NPL rather than MPL.

Honestly, by now you'd think I'd know better than to ask questions with anything other than the review flag.

Comment on attachment 428464 [details] [diff] [review] Fix v.1 Seems fine to me. Gerv

Comment on attachment 435438 [details] [diff] [review] Reunrotted fix v.1 phil: it is an honour to serve beside you in the war against random historical entropy bullshit. semper fi. r=shaver