* Mike Connor ([EMAIL PROTECTED]) wrote: > > 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.
I understand, but this is not a new issue. The situation has been stable for over a year. It's unclear to me where the urgency is coming from. But in any case, we will be complying shortly. > >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. Could you be more specific to which file is patched unnecessarily? Certainly all the changes are there to fix real bugs, and I'd be happy to discuss any and all changes we've made. The majority tend to be already reviewed patches in the bugzilla. > >>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. I'm not a big fan of patch based build systems, which is why I use subversion. The changes are copiously detailed in the debian/changelog and again I'd be happy to answer any questions you might have if the changelog is not enlightening. > >>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 the first time this kind of collaboration has been offered as far as I know. You should probably discuss this with Alexander Sack <[EMAIL PROTECTED]>, since he is leading most of the mozilla security efforts for Debian. It may very well be that we're the only distro trying to backport these fixes. > >>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. The guarantee that we're providing to our users is that the copyright licenses on things in main will meet the DFSG. So the logo is pretty clearly not DFSG free. There are concessions in there about names and version numbers needing to be changed, but not that we can include things with restrictive licenses if they're "easy" to strip out. Interestingly enough I just did the Montreal-Toronto run myself not too long ago :) > 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. It's never been well explained why just trademark enforcement wouldn't be enough to stop things like hacked versions. And really, if someone is distributing a version of Firefox to do something nefarious, a trademark isn't going to stop someone. > >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. Again, as it stands now, the logo doesn't appear to be acceptable to the project. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
signature.asc
Description: Digital signature
