751599 - De-complicate inclusion of license.html

Status: NEW

(Toolkit :: General, defect)

Description

[Gervase Markham [:gerv]]

This bug is an attempt to get the right people together to shave some yaks so I can fix bug 750294.

Currently, "about:license" is toolkit/content/license.html. However, the first problem is that we appear to be shipping 2 copies - one built via /toolkit/content/jar.mn, and the other via /browser/base/jar.mn, which also contains a line to make that copy override the toolkit copy. Each copy is 125k uncompressed, 25k gzipped, so we shouldn't ship two, just one.

The reason we do this, I think, is because of bug 368091 and friends, where 5 years ago we decided that we needed a generic about:license and for everyone to customize it to mention the different EULAs. However, we no longer have EULAs - all Mozilla software is just shipped under the MPL. So perhaps now we can eliminate that and just use the file straight?

The relevance of this to bug 750294 is that the toolkit copy of license.html gets properly pre-processed with the Hg URL, but its overridden by the browser copy, which doesn't. So fixing this would fix that.

Gerv

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to Gervase Markham [:gerv] from comment #0)
> The relevance of this to bug 750294 is that the toolkit copy of license.html
> gets properly pre-processed with the Hg URL, but its overridden by the
> browser copy, which doesn't. So fixing this would fix that.

As would fixing the browser copy (and mail copy, and suite copy, etc.) ;-)

Seriously, though, bug 750294 has exactly the same problem today as bug 368091 had 5+ years ago: trying to satisfy all licensing requirements in a single file which 
a) must serve a dual purpose, as both a source license (hg.m.o/toolkit/content/license.html) and a binary license shown in-product, and
b) where the implementation details of correctly satisfying the licensing requirements vary depending on what product the license is displayed for.

Nothing fundamental has changed about the nature of the problem--we just have problems with repos/build instructions now rather than EULAs, so we can't entirely dispense with having solution to the fundamental problem.

Luckily, in the past 5 years, we've all gotten a lot older and more knowledgeable and Thunderbird has gained content tabs.  So there's a better solution available today than preprocessor-based inclusion, and that's the solution outlined by Axel in bug 456360 comment 15 to fix the similar-to-this problem of showing accurate changeset information in about:buildconfig.  I even prototyped a solution in bug 456360 comment 21/bug 456360 comment 24 (though it never made it into the tree because I had to concentrate on fixing bugs that let me ship releases my users cared about).

The patch there still preprocessed to include the Gecko changeset info (which, in this bug, would be correct for Mozilla-the-platform/XULRunner, as well as Firefox), and then added an XHTML entity that every other app besides Firefox could use (via DTD inclusion) to add the appropriate changeset(s) for their app repository(ies).  Mozilla-the-platform/XR/Fx ships an empty buildconfig.dtd (license.dtd for this bug), so there's nothing for them to do, but everyone else (including outside consumers of Gecko/XR) can generate a buildconfig.dtd full of the required content and use a chrome override so that about:buildconfig includes their version of the buildconfig.dtd.

Note: since the patch never went through review, it's possible that someone would have requested removing the pre-processing and using a .dtd for both Gecko source info and secondary source info; in that case, you'd have to use a dual-dtd solution like netError/netErrorApp for things to be clean for non-Firefox apps; to me that seemed like a lot more hoops to jump through for minimal benefit in the buildconfig case.  However, here it might work a lot better and may be the easiest way to get things right.

Based on your existing patch in bug 750294, I would suggest either
1) preprocessing in only the Gecko repo paragraph, then adding entities for secondary-repos and build-instructions, with the "Gecko" copy of the license.dtd containing an empty secondary-repo entity and the existing build instructions paragraph in the build-instructions entity, allowing non-Firefox consumers to override the license.dtd with the appropriate info for their app in those two entities, or
2) going all-dtd with a dual-dtd solution, with the Gecko licsense.dtd including the existing repo and instructions text in those entities, and an empty secondary-repos entity, and then the non-Firefox consumers would only included the entities for secondary-repos and build-instructions in their licenceApp.dtd.

This DTD-based solution would let you now ship only a single copy of license.(x)html, customized correctly by default for Mozilla-the-platform/XR/Fx, but with the ability for all other apps in the Gecko universe to also comply with the licensing requirements by including their repos and build instructions in a license.dtd/licenseApp.dtd.