* Mike Connor ([EMAIL PROTECTED]) wrote: > Eric Dorland wrote: > >Please see Gerv's comments here: > >http://lists.debian.org/debian-legal/2005/01/msg00757.html to see > >where he agreed we did not have to use the logo. > > > > Fair enough, he did make that statement. At the time, we obviously > weren't taking that part seriously. We are now, and we're saying its > not ok.
Clear enough. > He also stated that the logos were not in the tarball, which may have > been true at the time, but is certainly no longer true. (see > mozilla/other-licenses in the 1.5.0.7 tarball) I have been stripping out the contents of other-licenses from the tarball because of it's non-free nature before uploading to Debian. > >>In that light, you should consider this, as I previously said, notice > >>that your usage of the trademark is not permitted in this way, and we > >>are expecting a resolution. If your choice is to cease usage of the > >>trademark rather than bend the DFSG a little, that is your decision > >>to make. > >> > > > >Is there no way that you could be convinced to split the license on > >the logo to have a DSFG-free copyright license and the same, > >restrictive trademark license. That would basically clear up the issue > >from our perspective and IMHO not weaken your ability to enforce your > >trademarks. > > > > At this point, its highly unlikely.that we would allow any changes to > the license that would be compliant with the DFSG, certainly not > creation of derived works. The logo is a powerful brand and mark on its > own, and it would be fairly silly to give up the control of that mark in > such a way. > > >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. 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. > 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. > >Because Gerv is not responsible anymore for the trademark permissions > >and approvals, that means any agreements reached with him are null and > >void? > > > > Not necessarily, just saying I don't see a need to consult him, > especially if something he thought was ok (splitting logos from > wordmark) has been confirmed to not be. > > >So this means any patch we wish to apply to the source must be signed > >off by Mozilla corporation before we can upload packages? What if this > >is a security update, do we need to wait for you before we can update > >the package? > > Yes, if you are shipping a browser called Firefox, we should be signing > off on every deviation from what we ship. Yes, its time consuming, and > yes, I can find more entertaining ways to spend my time, but its a > necessary evil. > > 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. > 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. > 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. Again, I can fix the switch if this would actually help things. > Following up with another comment to sum up. -- 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
