Closed Bug 302080 Opened 18 years ago Closed 18 years ago

Mac products need to display EULA

Categories

(Firefox Build System :: General, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jaas, Assigned: mark)

References

Details

(Keywords: verified1.8, Whiteboard: Bits posted. Tell me what you think.)

Attachments

(4 files)

We need to display a EULA when users install Firefox and Thunderbird on Macs.
This bug isn't about how we do that, we just need to do it. This should block
all further releases as it is a legal liability for us.
can't we do it as part of the disk image mounting process? this is what we used
to do i think.
Flags: blocking1.8b4+
Camino too right?

Josh here is the SKD for it...
ftp://ftp.apple.com/developer/Development_Kits/SLAs_for_UDIFs_1.0.dmg
Blocks: 286151
FireStorm can generate the bits for a disk image that shows a EULA, iirc.
I've already got this working, I just need to integrate it into the build.  Also
bug 257854, bug 283598, and Camino equivalent bug 180837.  Note localization imapct.
Component: General → Build Config
Product: Firefox → Core
QA Contact: general → build-config
Please could one of the legal people take a moment to explain the "legal
liability" that arises from not showing the EULA?

Showing an EULA (especially with lots of CAPITAL LETTERS AND OTHER SCARY LOOKING
STUFF) is deeply user unfriendly.

We should make sure that we are happy the extra legal security is worth the loss
of useability. This will damage the (valuable) perception that we're open, 
friendly and on the users' side. We'll look like corporate-ware with (often
draconian) EULAs, and people (who won't read the EULA) may just assume we're of
the same ilk and have something to hide.
We are showing a EULA before we ship. Legal explanation not necessary. Sorry,
but it isn't an arguable point.
Bruce,

The legal "legal liability" issue was addressed in a bug long long ago... I even
question logic/rational the first time around... as I hated always having to
agree to the EULA each time I updated my nightly (Mozilla Suite at the time)...
I've wish the EULA would only pop-up on the first run after a major upgrade say
1.0.x to 1.5 or when a new user profile is created... however that isn't likely...
Is the same EULA to be used both in official and unofficial ("DeerPark") builds?

Localization: only English and Japanese EULAs exist.  It looks now like the
Japanese build will get jp and en, and everything else will get en.
I've got a new dmg packager that will handle this, bug 180837, bug 257854, and
bug 283958.  I need to work Jaguar support back in, since the Seamonkey builders
aren't budging.  I expect it to be ready in a day or two.
Isn't 286779 a dup ?
Blocks: 286779
Whiteboard: Will have bits 0808 evening
Blocks: 180837, 257854, 283598
Attached file Mac packaging files
These are the EULA resources and dmg icons and backgrounds.  No provisions for
l10n yet.  The EULA is only available in en and jp, and per discussion with
Mike Beltzner, current installers only display the en EULA with English "click
here to accept" instructions and this message (in English) at the top:

FOR TRANSLATIONS OF THIS LICENSE INTO SELECTED LANGUAGES, PLEASE VISIT
WWW.MOZILLA.ORG/LICENSING.

These click-throughs behave identically.  I used the offical Mozilla Firefox
and Mozilla Thunderbird text for official builds.  Thunderbird unofficial
builds also use the official Mozilla Thunderbird text.	Unofficial Firefox
builds replace Mozilla Firefox with Deer Park (this will need to become Gecko
Browser on the trunk after branching, I suppose); Camino replaces it with
Camino.  I assume that this was the correct thing to do, but please verify
this.

For l10n of the dmg backgrounds, see bug 283598.  It would be nice to sidestep
the problem by eliminating the text altogether.
This replaces make-diskimage.  A patch to make-diskimage (in the next patch
set) allows it to use the new tool to package disk images.  This new script
contains full support for resources, backgrounds, and icons, things which were
partially implemented or not fully functional in the old script.  It also
produces slightly smaller disk images than the old script, and ones that should
mount more quickly.
Attachment #192035 - Flags: superreview?(sfraser_bugs)
Attachment #192035 - Flags: review?(joshmoz)
This patch updates packager.mk to use the new dmg packager directly.  Firefox
and Thunderbird are updated to inform the packager of their licenses and glitz
from the .tar.bz2 archive.  In-tree packaging support is added to Camino as
well.

This patch depends on the two preceding attachments.
Attachment #192036 - Flags: superreview?(benjamin)
Attachment #192036 - Flags: review?(joshmoz)
Whiteboard: Will have bits 0808 evening → Bits posted. Tell me what you think.
Attachment #192036 - Flags: superreview?(benjamin) → superreview?(cls)
Attachment #192036 - Flags: superreview?(cls) → review?(cls)
1) the blank png files for products other than Camino are intentional, right? I
just want to make sure they are placeholders.

2) Is there any way we can share the same licensing text file that other
platforms use so that when that text file gets updated it gets updated in both
locations at once? Can we build the .r file dynamically or avoid the .r altogether?
(In reply to comment #14)
> 1) the blank png files for products other than Camino are intentional, right?
> I just want to make sure they are placeholders.

They're placeholders.  Artwork is being developed in bug 283598.  I made a
request for artwork for the unbranded products there too.

> 2) Is there any way we can share the same licensing text file that other
> platforms use so that when that text file gets updated it gets updated in both
> locations at once? Can we build the .r file dynamically or avoid the .r
> altogether?

In a word, formatting.

Each .r (except for the two Thunderbird versions) is different, to reflect the
different product names.  We COULD set up license.r.in files and transform them
with sed, but the styl resources would get messed up because they contain
indices into the text.  You'd lose the boldfacing.  It would get even uglier,
and quickly.

The packager is equipped to take a plain text file and build a resource from it,
but again, it's plain text and therefore ugly for the same reason.  Also, you'd
lose the "You are about to install PRODUCT" message, which is kind of nice.  You
wouldn't believe how much difference it makes when the title is emboldened.

The eventual goal would be to set the packager up to accept rtf (or something
else that's not plain text) input and turn it into a suitable .r.  It's not
there yet.

The source tree already contains one plain-text EULA for Firefox and one for
Thunderbird.  They look like ass when they're fed directly to the packager.
My default view is column view, and when I agree to the license agreement, a
sized (squished) column view window opens instead of a window with a background.
We should get updated ds_stores to force a certain view.
We might want a more boring but more intuitive name for the dmg packager than
"dimmidge". It isn't clear from debugging data what that means. Something like
"moz_dmg_packager" would clarify the build output significantly.
Comment on attachment 192035 [details] [diff] [review]
New Mac OS X disk image (.dmg) packager

Please rename "dimmidge" to something more intuitive. With that done, r+.
Sorry, but I think this should be done on technical grounds. See comment 17.
Attachment #192035 - Flags: review?(joshmoz) → review+
Note for anyone else trying this out:

you need to chmod 700 the disk image packaging script (named "dimmidge" right now)
The .DS_Store files are fine, but there's an Apple bug that causes read-only
disks to use the column view if that pref is set in certain circumstances. 
Fortunately, there's already a workaround in the packager.  In dimmidge (or
whatever it'll be called), we need to set 'makehybrid' => 0, and then to work
around another Apple bug, 'partition_table' => 1.
Comment on attachment 192036 [details] [diff] [review]
Use the new packager to package the new files

looks good, tested on Firefox and Thunderbird
Attachment #192036 - Flags: review?(joshmoz) → review+
Comment on attachment 192035 [details] [diff] [review]
New Mac OS X disk image (.dmg) packager

rs=me
Attachment #192035 - Flags: superreview?(sfraser_bugs) → superreview+
Attachment #192036 - Flags: review?(cls) → review?(bryner)
Attachment #192036 - Flags: review?(bryner) → review+
Comment on attachment 192035 [details] [diff] [review]
New Mac OS X disk image (.dmg) packager

This will go in with the above changes under the name package-dmg, or something
else suitably boring.
Attachment #192035 - Flags: approval1.8b4?
Attachment #192036 - Flags: approval1.8b4?
Comment on attachment 192033 [details]
Mac packaging files

The artwork will change, see bug 283598.  There's nothing wrong with the
artwork in this archive, it's just not l10n-friendly and the dmg backgrounds
for unofficial builds are intentionally blank.
Attachment #192033 - Flags: approval1.8b4?
For reference, the consolidated and updated code portion.  This is ready for
checkin on the trunk and, pending approval, the branch.  Applies cleanly to
each.  Changes noted above are included in this patch.	Two previously missing
diffs to makefiles in other-licenses are included.  An attribute-setting option
is added to the packager; it is only used by Camino at the moment to turn off
the display of extensions on the two read-me files included in its dmg.  The
Camino background's filename has changed to match the change in format from png
to jpg.  The new Camino artwork is in attachment 192657 [details]; an accompanying
.DS_Store file has been generated.  The other packaging files in the archive
are still current, for the time being.
Attachment #193022 - Flags: approval1.8b4?
Attachment #192035 - Flags: approval1.8b4?
Attachment #192036 - Flags: approval1.8b4?
Fixed on trunk.  Leaving open for 1.8.
Attachment #193022 - Flags: approval1.8b4? → approval1.8b4+
Attachment #192033 - Flags: approval1.8b4?
Checked in to 1.8 branch.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
Verified on Mac DP 2005-08-19-08-mozilla1.8
Status: RESOLVED → VERIFIED
This checkin seems to have caused a major regression, see bug 305470
Depends on: 305517
Blocks: 305686
Keywords: fixed1.8verified1.8
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.