Closed Bug 555935 Opened 14 years ago Closed 8 years ago

Firefox trademark request for Debian

Categories

(Marketing :: Trademark Permissions, task, P3)

Product:
Marketing
Component:
Trademark Permissions
Platform:
All
Other
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: glandium, Assigned: kev)

Details

Attachments

(3 files)

Current patch list applied on 1.9.1 in Debian
5.94 KB, text/plain
Details
Debian packaging data for xulrunner 1.9.1.9
200.88 KB, application/x-gzip
Details
Debian packaging data for iceweasel 3.5.9
143.00 KB, application/x-gzip
Details 
Since the Firefox logo is now free software, we can actually start thinking about re-branding as Firefox in Debian. I went through the trademark licensing information pages on mozilla.org, but I couldn't find something that kind of relates to the Linux distro case.

Anyways, as of today, we distribute Firefox as a rebranded browser, named Iceweasel. (we also have the same kind of rebranding done for TB, SM and SB, but let's already agree on what can be done with Firefox before talking about these)

As many other Linux distributions, we use the browser as a xulrunner application, which means we have two separate packages, one for xulrunner and one for iceweasel, though the source tarball is technically the same for both.

Our source tarballs, however, differ from the mozilla.org ones for a set of copyright issues that are discussed in bug 398728 and bug 541984.

On top of these changes, we apply what could be regarded as a huge load of patches. 107 individual patches on top xulrunner 1.9.1, for instance, but 30 of these are applied on mozilla-central or 1.9.2 (some are even scheduled for 1.9.1.10), 8 more are awaiting checkin, and 14 are awaiting review. Some more patches are applied to iceweasel, most of which are only related to the rebranding and the use of xulrunner.

I do have an exhaustive list of separate patches for xulrunner 1.9.1, that I can attach here if necessary. The list for iceweasel is not ready yet, and work on 1.9.2 is also on its way, that will lead to a new list of patches against xulrunner 1.9.2.

We also have a small set of extra components shipped with xulrunner. 2 of them provide a restart notice when an upgrade of either the application, the GRE/XRE, a plugin, or an extension is detected, and another one allows to dump the current set of extensions and plugins used for use in the bug reports we get from users. 

Another notable difference with mozilla.org builds is the absence of support for APNG files, though I have plans to have this work soon(ish).

I spent a huge amount of time during the last months to improve the quality of the binaries we ship, and now we run 4 test suites on all our architectures (there are 14 of these, even if they are not all release architectures): xpcshell-test, check, reftest and crashtest. Most of the test suites now pass on most of our architectures, though we found several severe breakages on several architectures, which are now fixed in our builds, and either pending review or checkin on m-c.

Debian has 5 "branches": oldstable, stable, testing, unstable and experimental. A package enters unstable, and if within 10 days no release critical bugs have been found, the package automatically enters testing. Once the Debian Release Managers decide it's time to start the release process, testing is frozen, which means (mostly) only release critical bugs can be fixed in testing. Once the release critical bugs count is low enough, a release is done, and the content of testing becomes "stable", while the previous content of stable becomes "oldstable". The experimental suite is used for various (not necessarily experimental) purposes, but for mozilla related products, I intend to use it for non release target builds. For instance, in a few days, xulrunner 1.9.2 and iceweasel 3.6 should hit the experimental repository.

As can be deduced from the above, the current release target for the next Debian release is (unfortunately) iceweasel 3.5. There are several reasons for this, that I can give if necessary, but this request is already long enough without that. Anyways, we plan to provide security support for iceweasel 3.5 for as long as we can, though with the current state of affairs, it would be very difficult (we don't have access to the security related bugs, despite a request has been made a quite long time ago).

There are a few things that would obviously need to be worked out if we'd be allowed to ship with the Firefox mark. Off the top of my head:
- Users and redistributors should be allowed to do further modifications to the packages. That could mean keeping the iceweasel "brand" for these.
- Debian stable packages are only supposed to receive security fixes. At the moment, with no access to the security bugs, and no mercurial tree for the version currently in stable (3.0.x/1.9.0.x), we just ship the new releases, which is far from being the typical Debian way of doing things. We should be allowed to continue to support these versions even after mozilla stops supporting them. That would mean still be allowed to use the trademark on these builds (though we won't be switching the current stable to the trademark, and I'm not sure if we'd have enough time to get a Firefox in before the testing freeze)
- Getting feedback from mozilla usually takes time, and we sometimes need to streamline our changes, at the very least to validate them. Needing to unbrand these builds would be very inconvenient.
I almost forgot:
- We would need some kind of assurance that the agreement, if one happens, is not going to be unilaterally revoked, like it happened with the previous agreement we had, that allowed us to use the Firefox name without the corresponding logo.
(In reply to comment #1)
> I almost forgot:
> - We would need some kind of assurance that the agreement, if one happens, is
> not going to be unilaterally revoked, like it happened with the previous
> agreement we had, that allowed us to use the Firefox name without the
> corresponding logo.

To clarify this point, there was some discussion that led Debian to conclude, incorrectly, that there was an approved agreement in place.  There was a suggestion of a possible approach by one individual on a mailing list, with a caveat that the person suggesting it needed to get approval for the plan, which was never granted, to my knowledge.  This was an unfortunate mis-communication on both sides.

I'm not sure what level of assurance you're expecting, tbh.  Ultimately, a real trademark usage agreement would likely be contractual in nature, and would spell out the terms under which Debian would be allowed to use the trademark.  Violation of those terms would then be grounds for termination of permission, which may or may not meet your definition of "unilateral" revocation...
Mike H: Thanks very much for getting in touch with us, and for your detailed write-up. Please give us some time to look into it.

This bug is currently in a group where Luis and Harvey can't see it by default. That suggests to me that it's probably the wrong one, but I can't change it. 

Mike H: do you have any need for your request to be confidential?

Gerv
(In reply to comment #3)
> Mike H: do you have any need for your request to be confidential?

Not at all, I was actually surprised it ended up confidential. Did I do something wrong or is it the default level ?

(In reply to comment #2)
> I'm not sure what level of assurance you're expecting, tbh.  Ultimately, a real
> trademark usage agreement would likely be contractual in nature, and would
> spell out the terms under which Debian would be allowed to use the trademark. 
> Violation of those terms would then be grounds for termination of permission,
> which may or may not meet your definition of "unilateral" revocation...

If the agreement we have is written and well understood by all parties, i.e. can't be subject of any misunderstanding, that should be fine, I guess. All I want to avoid is to have another bad surprise some day, though the main problem back then has been resolved by the license change of the logos.
(In reply to comment #0)
> Since the Firefox logo is now free software, we can actually start thinking
> about re-branding as Firefox in Debian. I went through the trademark licensing
> information pages on mozilla.org, but I couldn't find something that kind of
> relates to the Linux distro case.

We're currently dealing with things as one-offs, but there's a longstanding need to clarify things.  I'll try to get a draft out soon.
 
> Our source tarballs, however, differ from the mozilla.org ones for a set of
> copyright issues that are discussed in bug 398728 and bug 541984.

AIUI, Ubuntu strips the same things, so no real issues here.
 
> On top of these changes, we apply what could be regarded as a huge load of
> patches. 107 individual patches on top xulrunner 1.9.1, for instance, but 30 of
> these are applied on mozilla-central or 1.9.2 (some are even scheduled for
> 1.9.1.10), 8 more are awaiting checkin, and 14 are awaiting review. Some more
> patches are applied to iceweasel, most of which are only related to the
> rebranding and the use of xulrunner.
> 
> I do have an exhaustive list of separate patches for xulrunner 1.9.1, that I
> can attach here if necessary. The list for iceweasel is not ready yet, and work
> on 1.9.2 is also on its way, that will lead to a new list of patches against
> xulrunner 1.9.2.

A (preferably linked) list of patches (with explanations) will be needed.  This is a really large set of changes, though hopefully many are more to do with portability than messing with functionality.

> We also have a small set of extra components shipped with xulrunner. 2 of them
> provide a restart notice when an upgrade of either the application, the
> GRE/XRE, a plugin, or an extension is detected, and another one allows to dump
> the current set of extensions and plugins used for use in the bug reports we
> get from users. 

The latter case is concerning, depending on implementation.  Note about:support in 3.6 and higher has a user-initiated way of copying a bunch of this data, so I would like to drop and/or merge this stuff.

> Another notable difference with mozilla.org builds is the absence of support
> for APNG files, though I have plans to have this work soon(ish).

This is a concern... differing Gecko capabilities is generally a blocker for trademark reqs.  What's the timeline on getting this working?

> I spent a huge amount of time during the last months to improve the quality of
> the binaries we ship, and now we run 4 test suites on all our architectures
> (there are 14 of these, even if they are not all release architectures):
> xpcshell-test, check, reftest and crashtest. Most of the test suites now pass
> on most of our architectures, though we found several severe breakages on
> several architectures, which are now fixed in our builds, and either pending
> review or checkin on m-c.

This is awesome to see.  Really really awesome!

> Debian has 5 "branches": oldstable, stable, testing, unstable and experimental.
> A package enters unstable, and if within 10 days no release critical bugs have
> been found, the package automatically enters testing. Once the Debian Release
> Managers decide it's time to start the release process, testing is frozen,
> which means (mostly) only release critical bugs can be fixed in testing. Once
> the release critical bugs count is low enough, a release is done, and the
> content of testing becomes "stable", while the previous content of stable
> becomes "oldstable". The experimental suite is used for various (not
> necessarily experimental) purposes, but for mozilla related products, I intend
> to use it for non release target builds. For instance, in a few days, xulrunner
> 1.9.2 and iceweasel 3.6 should hit the experimental repository.
> 
> As can be deduced from the above, the current release target for the next
> Debian release is (unfortunately) iceweasel 3.5. There are several reasons for
> this, that I can give if necessary, but this request is already long enough
> without that.

By this you mean the next long-lived Debian stable release?  What kind of timeline are you expecting/needing to support 1.9.1 for?

> Anyways, we plan to provide security support for iceweasel 3.5
> for as long as we can, though with the current state of affairs, it would be
> very difficult (we don't have access to the security related bugs, despite a
> request has been made a quite long time ago).

Let's split this off for the moment, I know there was some followup discussions that were supposed to happen, but this was never looped back to s-g.

> There are a few things that would obviously need to be worked out if we'd be
> allowed to ship with the Firefox mark. Off the top of my head:
> - Users and redistributors should be allowed to do further modifications to the
> packages. That could mean keeping the iceweasel "brand" for these.

In general, people making changes to their own builds is fine.  Downstream distributions without modifications are generally fine (there may be an edge case, IANAL).  Redistribution with branding _and_ further modifications would require explicit approval from Mozilla, and possibly a trademark usage agreement.  If branding is turned off, this is an non-issue in all cases.

> - Debian stable packages are only supposed to receive security fixes. At the
> moment, with no access to the security bugs, and no mercurial tree for the
> version currently in stable (3.0.x/1.9.0.x), we just ship the new releases,
> which is far from being the typical Debian way of doing things. We should be
> allowed to continue to support these versions even after mozilla stops
> supporting them. That would mean still be allowed to use the trademark on these
> builds (though we won't be switching the current stable to the trademark, and
> I'm not sure if we'd have enough time to get a Firefox in before the testing
> freeze)

There's two parts here: cherry-picking and post-EOL-support.

Cherry-picking of patches: We have consistently argued against this practice, as it creates potential problems where a security fix depends on a non-security fix.  All current trademark agreements (to my knowledge) require distros to use our release tags/tarballs + their patch set.  We try to be conservative in the general case, with a firm eye on branch compatibility and stability, and we have a very large and diverse user base depending on these changes, so I see no reason to make an exception for Debian.

Post-EOL-support: This is a fuzzy part of our trademark process right now, we've typically allowed this up to some point, but clearly at some point the brand risk is suboptimal.  I suspect we need a clearer policy across the board for downstream consumers.

> - Getting feedback from mozilla usually takes time, and we sometimes need to
> streamline our changes, at the very least to validate them. Needing to unbrand
> these builds would be very inconvenient.

I am not sure why this would be so inconvenient.  Enabling/disabling branding is a build-time switch.  It seems like it would not be a significant problem to only use branding for builds in "stable" and "oldstable" in the Debian case, but I don't know if I understand your process well enough to comment here.
Group: marketing-private
(In reply to comment #5)
> AIUI, Ubuntu strips the same things, so no real issues here.

We currently strip a bit more, first because we still remove the previously non-free logos, and second because Ubuntu doesn't address the search plugins images that I talk about in bug 541984 (though I should probably file a new bug for that). FWIW, next iceweasel version will use direct urls to the favicons in the search plugin files, so that means the icons in the search box will be downloaded the first time, and then kept in cache on next application start.
 
> A (preferably linked) list of patches (with explanations) will be needed.  This
> is a really large set of changes, though hopefully many are more to do with
> portability than messing with functionality.

I'll attach my list in its current form. It's only a list of patches + bug number and status or small explanation. The patches are not separately published *yet*, only in a big .diff.gz form for now. The next xulrunner package upload, due this week, will have the separated patches, so I'll be able to point there.

> The latter case is concerning, depending on implementation.  Note about:support
> in 3.6 and higher has a user-initiated way of copying a bunch of this data, so
> I would like to drop and/or merge this stuff.

Our implementation gets the data automatically when the user runs our bug report tool. It also gets full path for the plugins and extensions (but doesn't display the full path for path under the user profile), so that it is possible to cross-reference with the dpkg package database to know whether these come from Debian packages, what they are, and their package version. The source code is available in the big .diff.gz for now, and will be in a .tar.gz in next xulrunner package.

> > Another notable difference with mozilla.org builds is the absence of support
> > for APNG files, though I have plans to have this work soon(ish).
> 
> This is a concern... differing Gecko capabilities is generally a blocker for
> trademark reqs.  What's the timeline on getting this working?

I hope to be able provide APNG support before the next stable release, if time permits.

> By this you mean the next long-lived Debian stable release?  What kind of
> timeline are you expecting/needing to support 1.9.1 for?

That pretty much depends on when the next next stable release will happen. But that is expected to be somewhere between 1 and 2 years, at least. I don't expect shipping 3.6 to help us much considering this timeline, especially considering we will also ship seamonkey 2.0, and thunderbird 3.0, all based on 1.9.1. So we'd have to support 1.9.1 anyways.

> In general, people making changes to their own builds is fine.  Downstream
> distributions without modifications are generally fine (there may be an edge
> case, IANAL).  Redistribution with branding _and_ further modifications would
> require explicit approval from Mozilla, and possibly a trademark usage
> agreement.  If branding is turned off, this is an non-issue in all cases.

IANAL either, but shouldn't non redistributed builds with branding _with_ further modifications be fine ? That would IMHO help making the policy less a hassle for e.g. users that just want to change a few things for their own use.

> There's two parts here: cherry-picking and post-EOL-support.
> 
> Cherry-picking of patches: We have consistently argued against this practice,
> as it creates potential problems where a security fix depends on a non-security
> fix.  All current trademark agreements (to my knowledge) require distros to use
> our release tags/tarballs + their patch set.  We try to be conservative in the
> general case, with a firm eye on branch compatibility and stability, and we
> have a very large and diverse user base depending on these changes, so I see no
> reason to make an exception for Debian.

If we were to release with, e.g., 3.6.2, that would mean that we'd have to update with a new version implementing OOPP, which is definitely not something we usually do. I would have been okay with no cherry-picking if mozilla were to keep its previous policy for updates (though that would already be pretty lax, there have been a lot of obviously non-security related fixes in "stable" releases), but with the new policy, where OOPP is going to be pushed in a 3.6.x release, it's more concerning.

> Post-EOL-support: This is a fuzzy part of our trademark process right now,
> we've typically allowed this up to some point, but clearly at some point the
> brand risk is suboptimal.  I suspect we need a clearer policy across the board
> for downstream consumers.

On the other hand, you still distribute old EOL'ed versions on your own ftp servers...

> I am not sure why this would be so inconvenient.  Enabling/disabling branding
> is a build-time switch.  It seems like it would not be a significant problem to
> only use branding for builds in "stable" and "oldstable" in the Debian case,
> but I don't know if I understand your process well enough to comment here.

We actually have a lot of people who use the "testing" branch to get more bleeding edge software. It would somehow be weird that stable people can get Firefox while others get an unbranded thing. Also, depending on how much you want to technically enforce unbranding, that can be problematic. For example, if the package can't be named firefox, or if the binaries can't be named firefox.

At some point in our release process, anyways, the package will *have* to be firefox and to be branded in unstable, then testing, as this will be what is going to be released at that moment.
(In reply to comment #6)
> I'll attach my list in its current form. It's only a list of patches + bug
> number and status or small explanation. The patches are not separately
> published *yet*, only in a big .diff.gz form for now. The next xulrunner
> package upload, due this week, will have the separated patches, so I'll be able
> to point there.

Note, however, that most of the patches that have a corresponding bug number are attached in the bug, though I haven't checked all status yet (like is the patch in the BR outdated relatively to the current patch, etc.).

As I was looking at the patch list once more, I noticed that clean/0006 can actually be squashed into debian-hacks/0029, and the combination of both is what i sent on the corresponding bug already.
(In reply to comment #6)
> We actually have a lot of people who use the "testing" branch to get more
> bleeding edge software.

FWIW, we had around 50k users using iceweasel 3.5.8 on testing/unstable, and that went up to 100k when it reached backports, which is another branch I didn't talk about, that is not (yet) officially supported by Debian, and provides some rebuilds of packages from testing for use on "stable" systems. Usually, they are the exact same package as the one in testing, but rebuilt in a "stable" (possibly + backport) environment so that it gets the right package dependencies.

It would feel wrong to tell these users they can't have Firefox, while "stable" users can.
(In reply to comment #6)
> (In reply to comment #5)
> > AIUI, Ubuntu strips the same things, so no real issues here.
> 
> We currently strip a bit more, first because we still remove the previously
> non-free logos, and second because Ubuntu doesn't address the search plugins
> images that I talk about in bug 541984 (though I should probably file a new bug
> for that). FWIW, next iceweasel version will use direct urls to the favicons in
> the search plugin files, so that means the icons in the search box will be
> downloaded the first time, and then kept in cache on next application start.

This is not awesome from a privacy standpoint, since that translates to "first time, then every cache expiry/clearing afterwards, I'll ping a bunch of websites in the background."  Would need to see how this works with the Privacy Policy for Firefox (http://www.mozilla.com/en-US/legal/privacy/firefox-en.html)

> > The latter case is concerning, depending on implementation.  Note about:support
> > in 3.6 and higher has a user-initiated way of copying a bunch of this data, so
> > I would like to drop and/or merge this stuff.
> 
> Our implementation gets the data automatically when the user runs our bug
> report tool. It also gets full path for the plugins and extensions (but doesn't
> display the full path for path under the user profile), so that it is possible
> to cross-reference with the dpkg package database to know whether these come
> from Debian packages, what they are, and their package version. The source code
> is available in the big .diff.gz for now, and will be in a .tar.gz in next
> xulrunner package.

Does the user have control over whether this data is collected, and/or given the opportunity to edit this data before bug submission?

> > > Another notable difference with mozilla.org builds is the absence of support
> > > for APNG files, though I have plans to have this work soon(ish).
> > 
> > This is a concern... differing Gecko capabilities is generally a blocker for
> > trademark reqs.  What's the timeline on getting this working?
> 
> I hope to be able provide APNG support before the next stable release, if time
> permits.

Okay... I think this is a clear requirement for trademark usage, since it's web compatibility.

> > By this you mean the next long-lived Debian stable release?  What kind of
> > timeline are you expecting/needing to support 1.9.1 for?
> 
> That pretty much depends on when the next next stable release will happen. But
> that is expected to be somewhere between 1 and 2 years, at least. I don't
> expect shipping 3.6 to help us much considering this timeline, especially
> considering we will also ship seamonkey 2.0, and thunderbird 3.0, all based on
> 1.9.1. So we'd have to support 1.9.1 anyways.

Depends on how you care about SeaMonkey, since Thunderbird 3.1 will be 1.9.2-based.
 
> > In general, people making changes to their own builds is fine.  Downstream
> > distributions without modifications are generally fine (there may be an edge
> > case, IANAL).  Redistribution with branding _and_ further modifications would
> > require explicit approval from Mozilla, and possibly a trademark usage
> > agreement.  If branding is turned off, this is an non-issue in all cases.
> 
> IANAL either, but shouldn't non redistributed builds with branding _with_
> further modifications be fine ? That would IMHO help making the policy less a
> hassle for e.g. users that just want to change a few things for their own use.

That was what my opening statement was meant to convey.  Changes for your own builds are entirely worry-free, it's when you distribute something that this becomes problematic.

> > There's two parts here: cherry-picking and post-EOL-support.
> > 
> > Cherry-picking of patches: We have consistently argued against this practice,
> > as it creates potential problems where a security fix depends on a non-security
> > fix.  All current trademark agreements (to my knowledge) require distros to use
> > our release tags/tarballs + their patch set.  We try to be conservative in the
> > general case, with a firm eye on branch compatibility and stability, and we
> > have a very large and diverse user base depending on these changes, so I see no
> > reason to make an exception for Debian.
> 
> If we were to release with, e.g., 3.6.2, that would mean that we'd have to
> update with a new version implementing OOPP, which is definitely not something
> we usually do. I would have been okay with no cherry-picking if mozilla were to
> keep its previous policy for updates (though that would already be pretty lax,
> there have been a lot of obviously non-security related fixes in "stable"
> releases), but with the new policy, where OOPP is going to be pushed in a 3.6.x
> release, it's more concerning.

Gecko compatibility is generally a hard requirement, as I said, and so is feature support.  OOPP is a key feature that will be part of Firefox 3.6.x as a product, and as such I would expect it to be non-optional (like all other features).  The trademark is a brand promise, and our goal is to ensure that Firefox == Firefox from an end user and web compat standpoint.

> > Post-EOL-support: This is a fuzzy part of our trademark process right now,
> > we've typically allowed this up to some point, but clearly at some point the
> > brand risk is suboptimal.  I suspect we need a clearer policy across the board
> > for downstream consumers.
> 
> On the other hand, you still distribute old EOL'ed versions on your own ftp
> servers...

We have an archive of old builds, but we don't advertise them, etc.
(In reply to comment #9)
> (In reply to comment #6)
> > We actually have a lot of people who use the "testing" branch to get more
> > bleeding edge software.
> 
> FWIW, we had around 50k users using iceweasel 3.5.8 on testing/unstable, and
> that went up to 100k when it reached backports, which is another branch I
> didn't talk about, that is not (yet) officially supported by Debian, and
> provides some rebuilds of packages from testing for use on "stable" systems.
> Usually, they are the exact same package as the one in testing, but rebuilt in
> a "stable" (possibly + backport) environment so that it gets the right package
> dependencies.
> 
> It would feel wrong to tell these users they can't have Firefox, while "stable"
> users can.

Our bleeding edge users never see a Firefox icon.  As a general rule, the official branding would not allowed for a build that has anything other than mozilla.org tag/tarball + officially approved patches.  If you want to push only builds meeting that criteria to unstable, that's fine.  It's when you want to bake fixes that haven't had feedback or approval that the branding issue comes into plan.
(In reply to comment #10)
> This is not awesome from a privacy standpoint, since that translates to "first
> time, then every cache expiry/clearing afterwards, I'll ping a bunch of
> websites in the background."  Would need to see how this works with the Privacy
> Policy for Firefox (http://www.mozilla.com/en-US/legal/privacy/firefox-en.html)

Well, if you have valid proof that the images associated with the searchplugins are licensed under the terms they are claimed to be licensed under, I will be more than happy to use them. But in the meanwhile, I have nothing much better to propose, except removing the searchplugins altogether, or don't display icons at all. I'm still not quite sure what is worse.
 
> Does the user have control over whether this data is collected, and/or given
> the opportunity to edit this data before bug submission?

Yes, the bug report tool starts an editor with a mail template that will be sent to our bug tracking system, with the collected data in it. The user can remove anything they want from there.

> > I hope to be able provide APNG support before the next stable release, if time
> > permits.
> 
> Okay... I think this is a clear requirement for trademark usage, since it's web
> compatibility.

That would be Gecko compatibility, not web compatibility ;) (well, okay, Opera jumped on the bandwagon). This is OT here, but I really think mozilla has not been doing the right thing to push this "standard".

> Depends on how you care about SeaMonkey, since Thunderbird 3.1 will be
> 1.9.2-based.

TB 3.1 is likely to come too late. We also prefer to avoid having to support too many branches of the mozilla codebase, as we only have volunteer resources, and that the current volunteer resources to handle the security updates for mozilla based products in Debian currently are sparse: only me.
 
> Gecko compatibility is generally a hard requirement, as I said, and so is
> feature support.  OOPP is a key feature that will be part of Firefox 3.6.x as a
> product, and as such I would expect it to be non-optional (like all other
> features).  The trademark is a brand promise, and our goal is to ensure that
> Firefox == Firefox from an end user and web compat standpoint.

But Firefox 3.6.2 is not Firefox 3.6.x (still in the hypothetical example where we would release with Firefox 3.6.2). Part of cherry picking fixes is to only cherry pick fixes, not to bump version number. Also, in Debian, the xulrunner code base is used by much more than Firefox. We'd prefer not to have to introduce disruptive changes in a security upgrade (arguably, security only fixes can have bad side effects, but that's pretty rare (but already happened)).

And while I'm just writing this, guess what happens when I try to build the 3.0.19 security upgrade ? It breaks building (only against system libpng) because it lacks definitions of gfxPlatform::GetCMSMode(), and eCMSMode enum. And the bug closed by the corresponding commit is private, which suggests the patch being a security fix, with no corresponding MFSA... The interesting thing is that all this can mean is that when using non-system libpng, PNG_USER_MEM_SUPPORTED is *not* defined, making the patch itself not do anything at all.

> > On the other hand, you still distribute old EOL'ed versions on your own ftp
> > servers...
> 
> We have an archive of old builds, but we don't advertise them, etc.

There is still a difference between the EOL'ed versions you still distribute and the hypothetical (mozilla) EOL'ed versions that would still receive (non-mozilla) support. Note that past a certain point, we just declare that we don't support some stuff anymore. Normally, we support oldstable one year after a new stable is released, but we actually stopped supporting iceweasel before that for last release.
(In reply to comment #11)
> Our bleeding edge users never see a Firefox icon.  As a general rule, the
> official branding would not allowed for a build that has anything other than
> mozilla.org tag/tarball + officially approved patches.  If you want to push
> only builds meeting that criteria to unstable, that's fine.  It's when you want
> to bake fixes that haven't had feedback or approval that the branding issue
> comes into plan.

Your bleeding edge users run alpha and beta versions. Debian testing/unstable users usually run released software, i.e. mozilla.org tarballs + approved or not approved patches. Can't we agree on something like "whatever is called Firefox in debian testing needs to only have approved patches, and whatever is called Firefox in debian unstable can occasionally implement not (yet) approved changes, with the assurance that non-approved versions would never get into testing (we do have processes to block the 10 days transition from unstable to testing).

Disclaimer: I'm currently only speaking for myself, still with my debian developer hat on, but while the above would IMHO be a nice tradeoff, some other people within debian may not agree with me. I'll get in touch with other people @debian when we'll start to have some common ground, if we ever get to that point.
(In reply to comment #6)

> If we were to release with, e.g., 3.6.2, that would mean that we'd have to
> update with a new version implementing OOPP, which is definitely not something
> we usually do. [...] with the new policy, where OOPP is going to be pushed in
> a 3.6.x release, it's more concerning.

Just to add a bit of context here:

Mozilla updates are "security and stability" updates, and OOPP is directly tied to the latter part. Crash data indicates plugins are responsible for ~1/3 to ~1/2 of all crashes -- so shipping OOPP as a stability update makes a lot of sense.

How that jives with Debian update policy, I have no opinion on. :)
Assignee: liz → handerson
There is a change in the patches compared to the list I already attached. I squashed clean/0006 into debian-hacks/0029, which means clean/0007 to clean/0010 have been renumbered.

All patches are in debian/patches, you may also want to look at debian/test.mk for a list of skipped xpcshell tests, to debian/mozconfig for the build options and to debian/extra-stuff for the extra components I was talking about. You can also look at debian/rules, which has some more build and install tricks, if that matters to you.

You may also want to look at the patches against nspr and nss, which are built separately, respectively available on:
- http://git.debian.org/?p=pkg-mozilla/nspr.git;a=tree;f=debian/patches
- http://git.debian.org/?p=pkg-mozilla/nss.git;a=tree;f=debian/patches
I guess these are more or less similar to what Ubuntu has.
I also wanted to add that part of the reason why we have so many patches is that I've been in "keep up" mode for a while, now. Which means we actually get to the issues once it's too late to have the fixes applied to the released branch.

It is also why I'm currently spending most of my (unemployed) time to clean up my yard, package 1.9.2 branch (which is almost ready), and then, even better, package latest 1.9.3 alpha release. I hope time will still permit to package these alpha releases, so that we can detect issues before mozilla.org releases, which would indirectly reduce the number of patches we apply. This is also why I filed bug 555979.
BTW, let's not over-rotate on the searchplugin images issue. I'm sure we can find a fix, even if it's contacting the organizations and asking for appropriate copyright licensing terms for their logos, or writing that into our agreements in future, or whatever, or downloading them first time and storing them in non-evictable cache. We'll think of something. It affects us as well as Debian.

Gerv
I don't have a list with corresponding bugs, but IIRC some of the patches in there have a corresponding bug.
Almost half of the patches are only related to rebranding.
Could we at least agree on the principles if not on the implementation details (which already changed since I attached the patches) ?
Hi Mike, apologies for the delay here. I work on distribution agreements, and agree that coming to an agreement on principles and then details makes a lot of sense. My role at Mozilla is to working out what those principles are, and getting the right people on our side involved in the discussions. I'll shoot you an email with my contact information, and I'll work on a summary of this bug as well. Looking forward to continuing this.
Assignee: handerson → kev
Any progress on this one? It's more than a year since the last shown activity.
Any progress on this? 

There are a lot of Firefox fans who use Debian and other unix distributions based on it that would love to see this happen!
(In reply to Arturo Martinez from comment #22)
> Any progress on this? 
> 
> There are a lot of Firefox fans who use Debian and other unix distributions
> based on it that would love to see this happen!

There have been discussions privately in the last year and they did not result in any progress. Mike Hommey now works for Mozilla and is the maintainer of iceweasel in Debian so I would think this might make things easier in terms of reaching an agreement on any artwork used but honestly there has not been any progress based on the exchanges I have had and seen. 

Would love to see a deal reached though and have Firefox ship in Debian.
I guess this can be closed now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
And a pretty good summary here: https://lwn.net/Articles/676799/
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: