Facts about Debian and Mozilla® Firefox®

There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla® camp, that I, as the Firefox® co-maintainer, the xulrunner maintainer, and (soon) Seamonkey™iceape co-maintainer, have to rectify.

They broke the –enable-official-branding flag Half-true. We just replaced Bon Echo/Deer Park with Firefox® at the appropriate places in the build tree so that we could have Firefox® with the “unbranded” logo instead of the official logo, as Gervase Markham gave us authorization for. You’re still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken.

Firefox® logos being subject to trademarks, Debian thinks they are not free. Trademark and copyright are different things. Mozilla® has unnecessarily given a non-free license to “clarify” the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period.

Debian isn’t properly collaborating with Mozilla®, sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum’s blog) Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in… that’s exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming.

The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas’s blog again). So, let’s dig into our firefox_2.0~rc1+dfsg-1.diff.gz:

  • Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
  • Changes to fix “make distclean” so that it really cleans the build directory,
  • Change not to build the “mangle” utility,
  • Change not to call netstat to generate entropy, which is useless on linux,
  • Changes to make Firefox® build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla® guys don’t seem to care much for,
  • Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
  • Change to allow to build flat chrome without the zip utility,
  • Change to allow to use system library for myspell, instead of statically linking the bundled one,
  • Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
  • Changes to work around bugs with the hidden visibility pragma on gcc,
  • Changes to make the pango backend actually build correctly,
  • Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in’s,
  • Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
  • Change not to build useless chromelist.txt files,
  • Changes to make helper applications with parameters work,
  • Changes to allow builds against GTK 2.8,
  • Changes to work around an Xrender bug,
  • Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences…),
  • Change to allow mice extra buttons to act as something else than a left button,
  • Change to allow to build with -Wl,–as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions’ components,
  • Changes not to shlibsign the NSS modules at build time, since we’re stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.

That’s not that many changes, and most of them were taken from either some Mozilla® CVS trunk or the Mozilla® Bugzilla™. And most of those that were not taken from there have been sent, except those that really don’t make much sense outside Debian. So, where are these frozen API changes ?

And we’re not properly collaborating, huh ?

The Mozilla® project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett’s blog)

That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I’m not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions.

The only main difference now, between the official Firefox® and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won’t explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files.

Now, a little bit about differences the Mozilla® guys don’t seem to care about while they really should: distributions build the Mozilla® products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox® that is linked against libstdc++6. You are lucky if that setup doesn’t crash.

Little extra from comments in Lucas’s blog: Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla’s site. How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more.

Update: Debian is going to replace Firefox® with a GNU fork called Iceweasel Half-true. For the etch release, Iceweasel will only be Firefox® with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox® when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name… that’s quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can’t and won’t do more than a rename for the moment.

Update 2: We (Mozilla®) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla® Corporation or Foundation) Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it’s Ubuntu, it’s fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes.

Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.

2006-10-15 22:49:34+0900

firefox, xulrunner

Both comments and pings are currently closed.

67 Responses to “Facts about Debian and Mozilla® Firefox®”

  1. warpedvisions.org » Blog Archive » Debian versus Mozilla Says:

    […] October 22nd, 2006 in Links A summary of the Debian frustrations with Firefox/Mozilla. Most of the changes sound good, and the non-freeness of the logo is silly. […]

  2. John Gilmore Says:

    I hope that in addition to changing the non-free logo and trademarked name, Debian will also be changing the search box. The Mozilla Foundation makes about 50 million dollars a year from search kickbacks tagged with that “&client=firefox&rls=org.mozilla:en-US:unofficial” string in the URL. By signing up with the major search engines to show their ads in your users’ search results, and changing those default strings in the source code, the Debian foundation (Software In The Public Interest) can start collecting a nice chunk of that revenue.

    Mozilla won’t miss it — Debian users aren’t important enough to them. If Debian users were important, MozFdn wouldn’t be diluting its trademarks among those users. “Firebox? Who cares about Firebox? I want to know when the next Iceweasel release is coming out!”

  3. Stuart Says:

    Greg: Of course Mozilla knows that firefox is another name for the red panda. They used to sell a stuffed toy of a red panda:

    http://www.mozillazine.org/talkback.html?article=4546 http://images.google.com/images?q=firefox%20plush

    The logo does look more fox like, though.

    Here are some more interesting links: http://mozillazine.org/talkback.html?article=4278 http://www.mozilla.org/projects/firefox/firefox-name-faq.html http://www.hicksdesign.co.uk/journal/branding-firefox http://www.bengoodger.com/weblog/archives/week_2004_02_08.shtml#000549

  4. Peter Westlake Says:

    I would really like to see Mozilla and Debian get together and sort this out so that Debian can use the name Firefox again. Please sign the petition asking them to do that:

    http://www.petitiononline.com/debffx/

  5. Matthijs Wensveen Says:

    It’s a bit like the XFree86 licensing issues. X.org is a success, and IceWeasel may become a success too. I do hope Mozilla sees the light though.

    BTW. Man, the non-free debian logo is ugly!

  6. Blah Says:

    “We just replaced Bon Echo/Deer Park with Firefox® at the appropriate places in the build tree so that we could have Firefox® with the “unbranded” logo instead of the official logo”

    Why didn’t you use ‘–with-branding’ for that?

    “as Gervase Markham gave us authorization for” http://lists.debian.org/debian-legal/2005/01/msg00503.html says: “The Foundation grants Debian, and all redistributors of the official Debian packages of the Foundation’s products, the right to label those packages with a name containing the trademark.” and http://www.debian.org/social_contract#guidelines says “all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system” (this did mean that Debian was allowed to apply changes and still label it as Firefox while redistributors were only allowed to label it Firefox it was not modified).

  7. Blah Says:

    Something similiar was proposed this time also (granting a Debian-specific exception) but that was rejected.

  8. glandium Says:

    Why didn’t you use ‘–with-branding’ for that?

    Because it requires creating a full branding directory, while replacing BonEcho by Firefox is only 3 lines of changes, all images and branding being already in place in the normal tree. BTW, when using –with-branding, the application display name (the one that will be put in the UA, IIRC) will be BonEcho whatever you put in the branding directory. So you need to change configure.in anyway…

  9. Blah Says:

    Looking at http://lxr.mozilla.org/mozilla/source/configure#13630 I would assume that building with ‘–enable-official-branding –without-branding’ (or ‘–with-branding=’?) would have had the same effect.

  10. glandium Says:

    Blah: no, –enable-official-branding uses the official branding which is in other-licenses, that, being non-free, we remove from the archive. –with-branding uses a similarly structured directory, but provided by the user. Using none of these options use the “branding” that is in the tree itself, that is, the globe without the fox, and the always changing application name (DeerPark for 1.5, BonEcho for 2.0, etc.). We only changed the latter.

  11. anonymous monkey Says:

    http://lists.debian.org/debian-legal/2005/01/msg00503.html was a proposal, which Gerv said in the same mail may be him overreaching. Direct quote:

    “One final note: I can’t completely exclude the possibility that someone higher up at the Foundation (e.g. Mitchell Baker) will say that I’ve overreached myself. But I don’t know of any reason why that would be the case, and I’m negotiating in good faith. I would, of course, get a final version approved by all necessary parties :-)”

    The proposal violates the social contract, but that was okay because it was violating it in a different way than having non-free artwork, so some rules are ok to break, but not others. If that’s the basis for your constant “we had permission” rhetoric, try “Reading Comprehension 101” Even if it were true, there was no coordinated effort to get fixes approved, and indeed the maintainers seemed pissed that we would ask for such a thing, so its obvious that everyone read 1) and stopped reading.

  12. anonymous monkey Says:

    Ultimately, the concept of a controlled trademark such as Firefox and DFSG guidelines 3, 7, and 8 collide in ways that can only be resolved by one side or the other capitulating. To pretend otherwise was ultimately the wrong decision.

  13. Blah Says:

    “–enable-official-branding uses the official branding which is in other-licenses” Yes, but using that together with –without-branding seems to remove all branding except the name.

    AFAICS -enable-official-branding only sets ‘MOZ_BRANDING_DIRECTORY=other-licenses/branding/firefox’ and ‘MOZ_APP_DISPLAYNAME=Firefox’, and –without-branding (which is checked after that) sets ‘MOZ_BRANDING_DIRECTORY=$withval’ (which is empty by default).

  14. glandium Says:

    Blah: MOZ_APP_DISPLAYNAME is far from being enough by itself to change the name of the application… if it were, we’d be only modifying configure.in… which is not the case.

  15. Blah Says:

    Thanks, I wasn’t aware of that (but could’ve easily have looked it up). Still, IMHO it would have been better to use ‘-–enable-official-branding -–with-branding” as the package was not compileable by anyone but Debian without reverting those changes or getting permission to use the trademark (Gerv only talked about redistributing official Debian packages, not about anything else).

  16. oskar.twoday.net Says:

    Firefox: Die dunkle Seite der Macht…

    Macht verdirbt den Character. Erfolg auch: Mozillas Firefox, früher everybody’s darling und Vorzeigeprojekt der sogenannten „Open Source“ Szene, hat zweistellige Marktanteile erreicht und zeigt nun auch seine häßliche Fratz…

  17. Michael Says:

    Who cares what it’s called? To me it seems the biggest conflict is whether it’s mozilla or debian folk that need to find someone to give them a blowjob asap. I’d call it a draw nil point each by the sounds of it, but there’s always a first time guys and you’ll worry a lot less about what your browser is called afterwards, trust me.

    Anyway, just get 2.0 packaged and in the distro pronto, call it what you like.

    Please :)