On 21-Sep-06, at 1:38 AM, Eric Dorland wrote:
If this isn't possible, could we at least get a stay of execution?
Etch is going into deep freeze in less than a month. Would it be
possible to resolve this after the release?
I would think it makes much more sense to resolve this before you put
another long-lived release into the wild, unless your aim is to delay
compliance. Ignoring the logo issue entirely, I have grave concerns
around the nature and quality of some of the changes the patchset
contains, and I would like to see the changes as a set of specific
patches before I could make any recommendation as to whether we
should
continue to allow use of the trademark. If we were forced to revoke
your permission to use the trademark, freeze state would not
matter, you
would be required to change all affected packages as soon as
possible.
Its not a nice thing to do, but we would do it if necessary, and
we have
done so before.
Well yes I suppose I am trying to delay compliance since you've caught
us at an awkward time, and hoping for a little understanding. But from
the tone of the conversation that doesn't appear to be the
forthcoming.
Its less about "understanding" than the legal requirements for
enforcing trademarks. We can't selectively ignore things because its
inconvenient.
The diff.gz of the source package completely outlines the changes
we've made in a fairly monolithic diff. If you strip out the
regeneration of the configure file and all the debian files the diff
is fairly small. I'm not sure what you would find objectionable,
almost any patches we apply are from your bugzilla and have already
been reviewed, or are minor integration or portability patches.
There's changes for default font style, window sizes, a patch to a
file that shouldn't need patching in 1.5 (since it was fixed in our
CVS three months before we shipped 1.5) and a few other things, just
from a skim.
If you do have this set of patches (a question which you didn't
bother
to answer) a link would be greatly appreciated so I can get them into
our bugzilla and get the right sets of eyes on the code.
Regardless of
whether we're going to circle around on the logo issue, if you
intend to
continue using the mark, you need to do that ASAP.
I don't appreciate the accusatory tone you've taken there. I don't
maintain the changes as patches, but inside a Subversion repository
that contains a complete history of my (and co-maintainer Mike
Hommey's) changes. It's not publicly available, because it's on my
desktop machine for size and speed reasons, but I can make a copy
available to you if you would like.
I'm getting questions from others asking why change X or Y was made,
and I don't have answers. My tone's a little tense because I had to
ask a few times to get a response. Having individual patches means
that if we say "this change is ok" we can put that patch somewhere
accessible to everyone and anyone can use that patch. Having
everyone do one-off patches means less sharing and more forking,
which is the opposite of what I consider open source's biggest strength.
As for your straw man about security bugs, what security bugs
would you
be fixing with your own patches? If there are security bugs, they
should be fixed upstream, not in your own tree. We've had this
discussion repeatedly in the context of the security group, and we
expect that branded builds of x.y.z from <insert distro here> will be
the source tarball/cvs tag for x.y.z plus the set of approved
patches.
We do not want to get into the fools' game of cherry-picking
patches, or
individual distros deciding that Patch A isn't "security-oriented"
enough.
It's not a straw man. We still distribute the 1.0.4 version of firefox
in stable. We've backported security fixes to it (well mostly
Alexander Sack has) and now that security support has been dropped by
Mozilla, we've had to port fixes ourselves. Our policy for stable
releases is to backport security fixes, not new upstream releases. I
understand most distros have given up on this for firefox, but we
haven't yet.
Really, the better way of handling this, in our opinion, would be to
make the changes to mozilla.org CVS and continue to release new
tarballs and source tags. Just because MoCo isn't putting resources
into a branch does not mean no further work can happen under the
mozilla.org umbrella, IBM/Sun/Red Hat maintained the Mozilla Suite
1.4 branch long after mozilla.org switched support to the 1.7
branch. That way things are shared amongst everyone who might want/
need to maintain that branch. Seems like unnecessary forking to me,
unless you are the _only_ ones working on this branch.
This is all something we draw a hard line on, even for distros
that have
people contributing back to the project. There are no free
passes, nor
should there be. I have actually been asked recently by another
distro
maintainer whether everyone is on a fair playing field. Right
now, it
seems to others as if Debian has a special deal, which isn't fair,
and
it needs to change.
There are hundreds of distros out there, many who would like to
distribute firefox. Are you going to monitor them all? I doubt it, so
your process is already unfair.
Keep in mind that there are a set of things that can be modified
without approval, if you just build the stock browser and package it
up, the current policy does allow you to use the marks. If you want
to make additional changes, we need to approve those additional changes.
I hope to set up a framework for "approved patches" to stable
versions, so that if something doesn't make our freeze date, but
affects all/a subset of Linux distros, they can use the same patch
from an approved list. This will be an extension to the currently-
accepted modifications (i.e. if we approve a change for Fedora,
anyone can apply that patch to their distro package).
If someone wants to use the trademarks, and make additional changes,
they're in violation. It is our hope that this will rarely happen,
but if it does we will take the necessary action to preserve the
usefulness of the mark.
To be honest, the more I read about the DFSG, I don't know if its
possible to use our trademarks at all, as someone making a major
change
would not inherit the grant, and would be in violation of our
trademark
requirements, thus it isn't in the spirit of the DFSG. I know
this is
well-trodden ground, but now that we have a process, I'm not sure you
want to go down that path. On the other hand, if by simply
changing a
build option, users can make unlimited changes, I think that's much
saner than "if you make major changes, you need to change anywhere it
says Firefox." The current setup is even more restrictive than just
using the switch, because the exact same restrictions on building a
derivative version apply whether or not you use the switch, but its
harder to be sure you've completely fixed the branding. Debian users
cannot freely create derivative versions of the app with or
without the
switch, so breaking the switch isn't especially helpful.
I'm scared that I had a similar interpretation of the DFSG as you.
Just because I disagree with how its implemented, or how its
enforced, doesn't mean I don't understand the letter and the spirit
behind what you're doing here. We just use different hammers to hit
the nails.
Personally, having had a long drive to/from Toronto to think more on
this, I think the DFSG interpretation we're both looking at is per
the letter of the DFSG, but I think there's an incompatibility
between letter and spirit here. If users can, via a one-line switch
in a build config, strip out any logos/trademarks and accompanying
encumbrances and get a working app that's truly "free", is that not
enough to give users the freedom to fork? If the goal of the DFSG is
to ensure anyone can fork it with a minimum of encumbrances, I would
think that we're closer to that goal than Debian at large, since
there's no central branding setup that makes it easy for users to
unbrand Debian.
Its not much use to say "let anyone use the mark" because we've
already had people distribute hacked versions (which we've been able
to stop because of the trademark/copyright enforcement). Debian
protects their own marks and logos so that users can trust that what
they're getting has the project's mark of approval. We do the same,
and we're being told that we're being heavy-handed and unfair.
Again, I can fix the switch if this would actually help things.
Depends on whether its ok to use our logos as long as users can
easily disable it and fork the software. Otherwise, there isn't much
point in having the switch, since you've stripped the official
branding bits from the source.
-- Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
