Closed Bug 355764 Opened 18 years ago Closed 18 years ago

Review Debian SeaMonkey package diff for trademark-incompatible changes

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: WeirdAl, Unassigned)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

SeaMonkey 1.1 codebase changes
93.90 KB, patch
Details | Diff | Splinter Review
SeaMonkey 1.0.5 codebase changes
315.36 KB, patch
Details | Diff | Splinter Review 
There has been a very large brouhaha between the Debian community and mozilla.org over trademarks and unapproved patches.  Reference:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622
http://cbeard.typepad.com/mozilla/2006/10/mozilla_tradema.html

I'd like SeaMonkey council members, along with myself, to examine the differences between standard SeaMonkey code and the requested Debian-specific changes, in order to tell us which ones are not acceptable for trademark reasons on the SeaMonkey side.

Similarly, I'd like feedback from the Debian package maintainers and other interested people in the Debian community on the same differences, to see which ones are not acceptable on the Debian side.

If either side vetoes a particular change, we should work together to find a solution.  Fortunately, SeaMonkey has not been released as a Debian package yet, so we have some time to nip any problems in the bud.

I'll attach current patches for SM 1.0.5 and SM 1.1 as they currently stand from the URL field.  This will allow us to use Bugzilla's attachment editing system to comment on specific pieces of the patch as needed.
Flags: blocking-seamonkey1.1b?
Flags: blocking-seamonkey1.0.6?
(In reply to comment #2)
> Created an attachment (id=241490) [edit]
> SeaMonkey 1.1 codebase changes
> 

copied from http://bluebox.passys.nl/Debian/Experimental/seamonkey_1.1a-3/seamonkey_1.1a-3.diff.gz
this time, properly gunzipped.
Attachment #241488 - Attachment is obsolete: true
(In reply to comment #4)
> Created an attachment (id=241492) [edit]
> SeaMonkey 1.0.5 codebase changes
> 
> this time, properly gunzipped.
> 

Is seamonkey trademarked at all?
We (through Mozilla Foundation) are currently in the progress of registering the trademark(s), but that's not done yet.
Because of that, no trademark policy is out there, but we want to handle our trademark usages more liberal as Firefox.

Without having a trademark, it's hard to do trademark reviews...
(In reply to comment #6)
> We (through Mozilla Foundation) are currently in the progress of registering
> the trademark(s), but that's not done yet.
> Because of that, no trademark policy is out there, but we want to handle our
> trademark usages more liberal as Firefox.
> 
> Without having a trademark, it's hard to do trademark reviews...
> 

But maybe you can give a prospect? Will you make your logo non-free? Will you induce a review process on distributor modifications in order to use the "seamonkey" name?
(In reply to comment #7)
> (In reply to comment #6)
> > We (through Mozilla Foundation) are currently in the progress of registering
> > the trademark(s), but that's not done yet.
> > Because of that, no trademark policy is out there, but we want to handle our
> > trademark usages more liberal as Firefox.
> > 
> > Without having a trademark, it's hard to do trademark reviews...
> > 
> 
> But maybe you can give a prospect? Will you make your logo non-free? Will you
> induce a review process on distributor modifications in order to use the
> "seamonkey" name?
> 

Just to state it right away ... as we have to debrand firefox/thunderbird now, I guess we won't be willing to enter a deal for seamonkey that requests us to get positive-reviews for changes we introduce in order to use the name/logo.

As seamonkey is about to land in debian soon, please be honest, so we won't have to rename afterwards.

(In reply to comment #7)
> (In reply to comment #6)
> > We (through Mozilla Foundation) are currently in the progress of registering
> > the trademark(s), but that's not done yet.
> > Because of that, no trademark policy is out there, but we want to handle our
> > trademark usages more liberal as Firefox.
> > 
> > Without having a trademark, it's hard to do trademark reviews...
> > 
> 
> But maybe you can give a prospect? Will you make your logo non-free? Will you
> induce a review process on distributor modifications in order to use the
> "seamonkey" name?
> 

As I understand it, we *must* do a review process, or the trademark becomes worthless (for example, you could just "patch" seamonkey with a patch that removes all the SeaMonkey code and adds in the konqueror code and still call the result SeaMonkey).  I don't know if making a trademarked logo "free" makes any sense given that we'd probably have to go after anyone who modifies it anyway... but as far as I know, we're not planning to use a non-free copyright license on it. I'm not a lawyer.

These patches as attached are *NOT* acceptable, as they improperly capitalize SeaMonkey.

I'm sort of curious what exactly you're doing to venkman.

Stuff like
> +-CPPSRCS =         affentry.cpp \
> ++CPPSRCS =         mozMySpell.cpp \
also makes this horribly difficult to read - are you including patches as the result of your patch set?  If so, it's not clear to me why we would care about them, since they're presumably not affecting the resulting binary.  It would certainly be easier to look at the XPM changes as "before" and "after" pictures.
In advance ... debian did not request any review here. The outcome of this is not our fault, but your failure to act in good faith.

(In reply to comment #9)
> 
> As I understand it, we *must* do a review process, or the trademark becomes

No thats not true ... you just have to ensure quality standards that you can declare on your own. As long as you do care to some degree, you won't loose your trademark. For instance you can say, that debian has a QA process that you trust and its fine.

Just note that there is a difference between "enforcing a trademark" and "maximizing brand value". The latter is done for firefox/thunderbird and if you follow that road for seamonkey which is not a mozilla product, than its a shame imo.

> 
> Stuff like
> > +-CPPSRCS =         affentry.cpp \
> > ++CPPSRCS =         mozMySpell.cpp \

Its not our fault that people look at the complete diff. The diff is the diff compared to your original tarball which contains the debian/ directory that exists solely for packaging reasons.

Most hunks in that diff attached are just debian packaging code. Those double patches are the patches we keep inside the debian/patches directory in a distinct fashion. You usually just want to look at those.

> also makes this horribly difficult to read - are you including patches as the
> result of your patch set?  If so, it's not clear to me why we would care about
> them, since they're presumably not affecting the resulting binary.  It would
> certainly be easier to look at the XPM changes as "before" and "after"
> pictures.

Anyway, as mozilla removed a former agreement we had based on the assumption that we have a high QA process and good will, I guess we will not do this fault for seamonkey again and rename it right from the beginning.

I am not happy with that, but we are walking on burned ground here.

Note: this is just my opinion and I don't speak for other debian folks - though I doubt they will think different.

Anyway, I will raise this in our project, but I guess debranding is the only way to go for us as well as for lots of other distributors.

Feel free to close this bug as invalid, as there is no issue from the debian side here.

> The outcome of this is not our fault, but your failure to act in good faith.

In what way am I/we not acting in good faith?  You're aware we're (SeaMonkey counicil) completely unrelated to the Mozilla Corporation / Foundation, right?  Personally I'd be happier to have people see "SeaMonkey" when using a browser on Linux than for them to see something else.
Whoa, whoa, time out.  *I* requested this as a matter of good faith pre-emptively between the two groups.  This is the attempt to head off a confrontation by taking a look at the differences before they become problematic.

I'm not a member of either Debian's development or the SeaMonkey council; I'm an unofficial liaison between the two.  Let's not jump to conclusions; let's be civil and polite.

(In reply to comment #8)
> Just to state it right away ... as we have to debrand firefox/thunderbird now,
> I guess we won't be willing to enter a deal for seamonkey that requests us to
> get positive-reviews for changes we introduce in order to use the name/logo.

That's not what this bug is about.  This bug is about determining what blocks acceptance (vetoes), and working around that.  Believe me, everyone on this bug wants SeaMonkey in Debian.
(In reply to comment #9)
> These patches as attached are *NOT* acceptable, as they improperly capitalize
> SeaMonkey.

So it's a typo.  We fix it, we go on.
(In reply to comment #11)
> > The outcome of this is not our fault, but your failure to act in good faith.
> 
> In what way am I/we not acting in good faith?  You're aware we're (SeaMonkey
> counicil) completely unrelated to the Mozilla Corporation / Foundation, right? 
> Personally I'd be happier to have people see "SeaMonkey" when using a browser
> on Linux than for them to see something else.
> 

Using the term "not acceptable" is always wrong and never good faith. Just trust us and suggest improvements. But don't force anything on us.

>In reply to comment #14)
> Using the term "not acceptable" is always wrong and never good faith. Just
> trust us and suggest improvements. But don't force anything on us.

Improvements on the intended patch is what this bug is all about.  Nothing more.

As this is getting quite sensible ... can you guys if posting a comment please point-out what role you have in seamonkey project so we can weight your comment properly?

BTW, who will be the owner of seamonkey trademark?

asac:
For the roles, it's easy to find if you try that there's a list of SeaMonkey Council members at http://wiki.mozilla.org/SeaMonkey:Project_Organization - all others here are contributors in some way. If they're commenting here, they probable are ones that want this issue resolved positively.
And you'll find that even Council members may have different opinions on some things. As we don't have a brainwashing process for entering the project, we think of diversity as a strength here - but we stick to our agreements and decisions.

I think getting to an agreement shouldn't be really hard and we should try to. I know it's sometimes hard with the sense of so-called "purity" that Debian wants (and only their custom rules count for anything they release), but we'll get somewhere.
What I wonder though is why you need to ship a changed SeaMonkey anyways and not the real release versions? It's always better to push for the changes getting integrated upstream instead of in some distro - and if they don't get merged upsteam, then there are probably reasons for that.

The formal owner of the SeaMonkey trademarks (on the word and the logo) will be the Mozilla Foundation, as it's the formal body that backs us. We as the SeaMonkey Council will have our own measurements and basically sovereignty as to how to protect these trademarks though.
(In reply to comment #17)
> 
> I think getting to an agreement shouldn't be really hard and we should try to.

There is no need for an agreement, as we just do what is necessary to provide high-quality packages ... you should just trust us and provide feedback if you see something really going wrong. That's how thounsand of other software pieves get distributed by us and thats the way it works.

> I know it's sometimes hard with the sense of so-called "purity" that Debian
> wants (and only their custom rules count for anything they release), but we'll
> get somewhere.

That is just not true. We distribute things you provide ... we have no other rules than that things we distribute give our users the freedom they expect from us.

> What I wonder though is why you need to ship a changed SeaMonkey anyways and
> not the real release versions? It's always better to push for the changes
> getting integrated upstream instead of in some distro - and if they don't get
> merged upsteam, then there are probably reasons for that.

Almost all changes we have are either submitted in bugzilla (mostly with a positive review or already landed on trunk) or we took them from bugzilla (usually with a positive review).

We don't hack around for fun ... so please don't question why we have to ship modified versions. FWIW, our modifications are not in seamonkey code ... they are usually in architecture dependent code so maybe you don't recognize that we contribute because of that.

Our philosophy demands us to contribute everything back we improve ... and thats exactly what we are doing.
(In reply to comment #17)
> The formal owner of the SeaMonkey trademarks (on the word and the logo) will be
> the Mozilla Foundation, as it's the formal body that backs us. We as the
> SeaMonkey Council will have our own measurements and basically sovereignty as
> to how to protect these trademarks though.
> 

(Note: the following is not the approach I would take if I were alone, but the approach we have to go in order to act in the best interest of debian and downstream distributions)

Sometimes its unfortunate to be associated with some entity that has a bad track-record for some particular topic (in this case trademark enforcement discontinuity). In my case I suffer for being a debian member from time to time ... in your case its your affiliation with mozilla foundation now.

Though, I feel sad that I cannot honour my personal trust in you and the seamonkey council, because we (as the debian mozilla maintainers) cannot vote to expose debian to this threat again. I vouched for mozilla once, as I voted once to accept an agreement for firefox et al.

Anyway, we cannot use seamonkey marks if they will be owned by mozilla foundation or corporation. If mozilla foundation will hand over their (not-yet-)registered trademark "seamonkey" to an unaffiliated/independent 3rd party at some point, I am sure that we can again assume good faith in that entity until proven wrong again.

However, I think that this is not going to happen (at least not within the timeframe we need to get this into our next stable release before the freeze). So we came up with the following course:

  1. release etch with debranded seamonkey.
  2. look at how trademark situation evolves for seamonkey during the time etch is stable
  3. rebrand to seamonkey if trademark situation has evolved and there is a line we feel comfortable with, e.g. that you will not force anything upon us because we distribute your marks.

I am really sorry about this and I hope you understand our situation here. We still will distribute your software and people will be able to find that package if they search for seamonkey in our archive, which should be the main thing that matters for you and us imo. Your software will be distributed to a great amount of users and feedback (like bug reports) will be forwarded to you if its not debian related. Its not perfect, but its still better than nothing and I hope cooperation between our projects will not suffer from this. You can still feel free to comment and suggest improvements on our patches as we still feel obliged to get improvements we develop into your tree.

Under the tri-license our code is distributed under, it's within your rights to rebrand anything. We probably won't accept bug reports about anything not branded "SeaMonkey" (i.e. resolve them as invalid) though, so be sure to test anything you submit to us in SeaMonkey-branded nightlies before reporting it.

Anyways, a distributor (not) shipping our code is no blocking issue for any release - them shipping our released code can only happen after we released it.
Flags: blocking-seamonkey1.1b?
Flags: blocking-seamonkey1.1b-
Flags: blocking-seamonkey1.0.6?
Flags: blocking-seamonkey1.0.6-
(In reply to comment #20)
> 
> Anyways, a distributor (not) shipping our code is no blocking issue for any
> release - them shipping our released code can only happen after we released it.
> 

I agree on that.

Anyway, if you want to get those patches in a better readable format (e.g. distinct patches to the code-base in a zip). Let me know.

Today, we had some discussion with Alexander and "iunkown", a Mozilla community member who wants to stay anonymous in this matter.

He made some good requests, and Alexander asked him to make those in the bug report so he can look them up later. I'm posting those here for him:

- patches should be delivered to mozilla.org patch at a time with an explanation of the problem involved, along with an explanation of the fix
- please name patch files in the debian/ directory after the bug and attachment number, if that's a violation of the debian/rules, then include an index in debian/rules which explains the relation
- and i can assure you that the next patch i noticed, deltaing /dev/null to a /usr/share for a venkman js file is not something we'd approve of.
- instead a patched makefile or debian rule to copy/unzip the file to such a place might be ok, but it's highly unlikely that there's a valid reason to install a venkman file into /usr/share on its own.
- if a makefile uses ifdef or similar to decide to do something and you don't want to do it, then don't hack the makefile's logic to smithereens, just set/clear the define.
Severity: blocker → normal
> - and i can assure you that the next patch i noticed, deltaing /dev/null to a
> /usr/share for a venkman js file is not something we'd approve of.
That file appears to be identical to the version we ship anyway.
Comment on attachment 241492 [details] [diff] [review]
SeaMonkey 1.0.5 codebase changes

Isn't the killAll change ready to check in?
You can forget this bug report. Most of the patches are already lying here in the bugzilla, anyways... I'll report the remaining ones some day.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: