Replace /LICENSE with a mention of where the canonical license info lives, and stop shipping it with binaries

RESOLVED FIXED in mozilla1.9.3a4

Status

()

defect
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: philor, Assigned: philor)

Tracking

Trunk
mozilla1.9.3a4
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

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.
Posted patch Fix v.1 (obsolete) — Splinter Review
Honestly, by now you'd think I'd know better than to ask questions with anything other than the review flag.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #428464 - Flags: review?(shaver)
Attachment #428464 - Flags: review?(gerv)
Comment on attachment 428464 [details] [diff] [review]
Fix v.1

Seems fine to me.

Gerv
Attachment #428464 - Flags: review?(gerv) → review+
Posted patch Unrotted fix v.1 (obsolete) — Splinter Review
Attachment #428464 - Attachment is obsolete: true
Attachment #432067 - Flags: review?(shaver)
Attachment #428464 - Flags: review?(shaver)
Attachment #432067 - Attachment is obsolete: true
Attachment #435438 - Flags: review?(shaver)
Attachment #432067 - Flags: review?(shaver)
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
Attachment #435438 - Flags: review?(shaver) → review+
http://hg.mozilla.org/mozilla-central/rev/1584ba8c1b86
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Summary: Fix or remove /LICENSE (yet again) → Replace /LICENSE with a mention of where the canonical license info lives, and stop shipping it with binaries
Target Milestone: --- → mozilla1.9.3a4
You need to log in before you can comment on or make changes to this bug.