Thunderbird bz 579023 still not fixed even though there is an upstream fix available
kevin.kofler at chello.at
Sun Apr 25 22:21:33 UTC 2010
Chris Tyler wrote:
> Wait, let's not get silly here.
> Fedora has a great relationship with Mozilla. They're an amazing project
> filled with people that Get It, and we can work out issues with them in
> a cooperative way.
I'm fed up of the "they're great, so let's do all they want" rhetoric. No
matter how nice the other guys are, if what they do conflicts with our
ideals and they aren't flexible enough to change this, we CANNOT work with
I strongly disagree about them "Getting It". They're the ONLY Free Software
upstream insane enough to require approval for EVERY SINGLE patch as a
condition to use their trademark. Imagine if Linus Torvalds did that for the
kernel Linux, or the GNOME and/or KDE developers for their desktop
environments. It would be impossible to maintain a distro under such
conditions! Why does Mozilla get that sort of preferential treatment?
Even some copyright holders who previously enforced this kind of
restrictions in their copyright licenses, e.g. DJB and the UW (PINE), have
seen that patch approval requirements are a major roadblock and made their
software Free Software. So why does Mozilla have to use trademarks to
restrict the freeness of their software?
I also think Mozilla doesn't "Get It" in several other ways. System
integration on GNU/Linux is generally an afterthought and moves very slowly,
e.g. it has taken years to get Firefox to use system icons, and I have no
idea when or even if openSUSE's KDE integration will be merged. Firefox is
set up to send all the URLs you consult to Google by default, which also
means you have to manually disable the relevant settings (which don't even
say anywhere in the dialog that they send all your browsing data to Google!)
if you don't agree with the ToS for Google's anti-phishing service. They
forked libpng to add support for the nonstandard "APNG" extension they added
despite the explicit opposition of the PNG group, bundle that forked version
and don't support building against a system libpng without their patch; they
removed support for the official MNG format which serves the same purpose
for bogus reasons, probably ensuring that no animated PNG format will ever
reach critical mass (which is quite sad considering the obsolescence of GIF,
and which might even contribute to spreading proprietary crap such as
> * Mozilla is currently implementing unit tests *on Fedora* in addition
> to their long-standing tests on CentOS. This benefits both communities.
So what? That has nothing to do with the issues at hand.
> * Mozilla's brands are very well-known: They have 350+ million users
> across multiple platforms (Windows, Mac, Linux), far more than we have
> in Fedora. The ability to use these apps in Fedora helps to assures new
> users that switching costs will be low.
Whether it's called "Firefox" or "Iceweasel" or "Water Buffalo" or whatever
doesn't change how it works at all.
> * The trademark rules are there for a reason. Browser and e-mail clients
> are some of the most common attack points on desktop systems, and
> Mozilla needs to ensure that they don't get a black eye for some
> vulnerability introduced by a distro.
LOL, now that's a funny excuse! They should start fixing their own
vulnerabilities, they have at least an order of magnitude more security
issues than Konqueror. For each one they fix, a new one pops up somewhere
And in addition, this is not a problem for the kernel Linux, for GNOME
(including Epiphany and Evolution), for KDE (including Konqueror and KMail)
and many other software, so why would this be a problem for Mozilla?
> And distros definitely introduce vulnerabilities: think about the Debian
> ssh-keygen patch fiasco as an example.
That was an isolated case. Extrapolating from that that distros introduce
vulnerabilities in all the software they patch is quite silly.
> We wouldn't do something so rash, of course -- or would we? The suggestion
> earlier in this thread that we patch TB and push directly to stable does
> not instill confidence.
Well, it depends on how complicated the patch is. If it's rather trivial and
if the problem is important (which it is), I think pushing it out as fast as
possible is the right thing to do. If the patch is more complex, it needs
> Let's not be brash. If we want to ship TB with one small patch, it's a
> simple matter of asking.
Then let's ask, NOW, so we can get that crasher finally fixed!
But that still doesn't fix the underlying issue in the long run.
More information about the devel