Trademark “Equality”

Simon Phipps has written several pages of almost-entirely-good stuff about how you benchmark a project’s governance. I particularly like his description of the best governance structure as an “open, meritocratic oligarchy”. I proud of the fact that we pretty much have one of those at Mozilla.

The one issue I would disagree with him on is his comments on trademark policy. He writes:

There will be a community-equal trademark policy, granting every participant the same rights to use of the trademarks…

But who is a participant? Free software projects have fuzzy edges. If I contribute one patch, am I a participant? Does that then allow me to label the heavily modified builds of the code I am distributing with the standard project name? This seems like it could quickly mean that the trademark doesn’t offer any guarantees of what you are getting (which is the point of a trademark).

He also says:

A trademark that is under the exclusive control of one community member will be a problem if the community tries to take a direction that member objects to.

What sort of ‘problem’ will this cause? It will cause the fork to have to rename itself. But that’s OK – in fact, it’s a good thing, because if the source is different, the mark should be different. To put it in code terms, a trademark is not about identifying a codebase, it’s about identifying a distribution. Firefox is a distribution of the Mozilla codebase by the Mozilla Organization; Songbird is another one from Pioneers of the Inevitable; and TomTom Home is yet another, from TomTom. If someone else distributes some different software built from the Mozilla codebase (and all forks are different – that’s the point) and there is no agreement with the trademark holder, then it’s right that there should be a new mark so people know what they are getting and who they are getting it from.

Having said that, I entirely agree that there are good and bad practices surrounding trademarks. I think that there are things you should look for in a free software project’s trademark arrangements – such as whether the trademark is easily removable without affecting the function, whether there are a documented and approved set of steps for removing it and being in the clear legally, and whether the day-to-day usage policies are things you can live with. (I’ve been meaning to write a more detailed paper on this for at least 5 years, but still haven’t got around to it…)

But I can’t agree that a “fully egalitarian” trademark policy is necessary for good governance, or is even in the best interests of the project. What would happen to the meaning of the word “Firefox” if Mozilla had such a policy? One group who would definitely benefit would be these people

15 thoughts on “Trademark “Equality”

  1. Yeah, I philosophically object to trademarks being community-equal (at least user-facing ones). Trademarks are all about reputation, and in a capitalist society that’s one of the most important ways people make informed decisions. A community-equal trademark destroys that.

  2. Yeah, I philosophically object to trademarks being community-equal (at least user-facing ones). Trademarks are all about reputation, and in a capitalist society that’s one of the most important ways people make informed decisions. A community-equal trademark destroys that.

  3. I agree with both of you, but I think you’re missing Simon’s point a little.

    What Simon is concerned about is more like the Ethereal->Wireshark or (to some extent) the Hudson->Jenkins renames, where a significant portion of the community is forced to become a fork simply because the trademarks are held by someone else (who represents a much smaller part of the community).

    (The two cases are slightly different: in Ethereal’s case, iirc, there was no animosity, but the main developer’s company wanted to market under the original trademark, so they ‘forked’, and everyone moved to the Wireshark side; in the Hudson->Jenkins case (again iirc), the community was blocked from switching to alternate infrastructure by the trademark holder (Oracle), and almost all of the community is now on the ‘Jenkins’ side.)

    These are different situations than is the case with Mozilla at the moment, where the trademark holder also happens to be the main (and, importantly, active) contributor.

  4. “What sort of ‘problem’ will this cause? It will cause the fork to have to rename itself. But that’s OK – in fact, it’s a good thing, because if the source is different, the mark should be different”

    The problem is that if the original is a widely used brand, the fork is going to have a pretty much impossible time getting off the ground. I don’t this is likely to be a problem for Mozilla, as the trademarks are looked after by the Foundation, which has some level of accountability to both the general public and to the Mozilla community. But what if the Firefox trademark was instead owned by AOL or by Google and Mozilla was using it – I think the potential problems there are obvious. If

    On the other hand, I’m not sure giving everyone in the community the right to use the trademark is a solution. Ideally you want “the community” as a collective to decide how the trademark should be used, but nebulous communities can’t own things. I think this is a wider governance issue rather than just a matter of looking after a trademark.

  5. Could a company use a trademark to prevent the usage for compatibility reasons, e.g. could Mozilla theoretically prevent other browsers from using having “Firefox” in their user agent string?
    If this was the case then this could hinder forks in gaining ground, which IMHO would go against the spirit of the GPL (but then GPLv2 already allows other such unpleasantnesses).

  6. Malcolm: I agree with your specific point, but I don’t really see a way (via principles) to distinguish between projects where the trademark owner goes rogue and those where it doesn’t. I’m not sure what the right solution to that is, but it certainly isn’t making the trademark community-equal.

  7. Malcolm, Sid, et (maybe) al., Gerv didn’t mention it, but I’d bet long odds that it was at the back of his mind somewhere: remember the Firefox / IceWeasel controversy (I mean, the controversy which resulted in the IceWeasel fork of, er, Ā«the Mozilla codebaseĀ»). Alas, I don’t have the URL handy for the grisly history of the full back-and-forth argumentation, but I think it is still available “somewhere” on the Web.

  8. Moritz: Well, people argue about whether it’s actually legally possible to do that at all. But if it were, that’s what one of my exceptions is – “whether the trademark is easily removable without affecting the function”. If e.g. Mozilla required people not to use Firefox in the UA string, that would fall under this clause.

    Tony: My view expressed above should not be taken to imply any particular position on what I think should have happened in that particular case.

  9. One bad practice of Mozilla is “you may not say that something’s based on Firefox” in the policy. Even if the statement is true.

  10. Thanks for the comments, Gerv. I think you’re slightly missing the point of my remarks here. A community-equal policy is one that treats all community members equally. If the trademark is effectively beyond use by all community members (as it is in the case of Apache for example) apart from fair-use references and distribution of the community binary, then that’s “community-equal”- no-one has special rights over and above everyone else.

    The nature of trademark law means that’s likely to be the best approach for most communities, with the open meritocratic oligarchy representing the community as a whole being the only entity with special rights.

  11. Every time I help someone set up a Debian system, I end up giving an explanation along the lines of “Iceweasel is Firefox, except the Mozilla project has some idiotic policies about naming that make it impossible for Debian to package something named ‘Firefox’.” (More or less detail depending on how much the recipient of the explanation cares; developers I talk to tend to care.) And yes, I start the explanation with “Iceweasel is Firefox”; sue me.

    Take from that what you will. I agree entirely with the assessment that any project commonly recognized by name which doesn’t allow downstream distributors (with or without patches) to use the name has serious problems with openness.

    That said, I don’t necessarily think the trademark policy has to match the policies required by a FOSS license, either; it just needs to not require renaming except in cases that would never come up in legitimate use. For instance, a FOSS license cannot and should not say “you may not modify this software to include adware/malware/etc”; however, saying that in a trademark policy (“You can’t call it Firefox if you include adware/malware/etc”) would not cause any problems for FOSS developers and downstream distributors.

  12. @Moritz: (Disclaimer: this explanation may not hold true in *all* jurisdictions.) If compatibility with Firefox required putting “Firefox” in the user-agent string, the trademark cannot legally prevent you from doing so. Trademarks cannot cover implementation details; their restrictions remain very narrow since they last forever (as long as the holder keeps paying for them).

  13. Anonymous: You are wrong in saying that saying “no adware/malware” would be no problem for downstream FOSS distributors. A significant chunk of people who apply software copyright freedom principles to trademarks in a very direct way think that any restriction on what you can do is not allowed (just as it is on copyright licences – it’s called a ‘field of use’ restriction).

    Also, how do you define “adware” or “malware”?

  14. @Gerv: Sorry that I missed your response.

    When I suggested that downstream FOSS distributors wouldn’t have a problem with that narrower trademark restriction, I didn’t necessarily mean that the trademark license would qualify as FOSS. However, the Open Source Definition and the Debian Free Software Guidelines both explicitly allow requirements to rename modified versions, and Debian at least has said before that they don’t mind distributing software with such a requirement under the original name, knowing that someone downstream from them might have to do the renaming if they modify it. So, I don’t think such a requirement poses any legal problem.

    I primarily suggested that narrower restriction because it would make life simpler for distributors which might want to make non-malicious modifications. For example, building against system libraries, or backporting security fixes, or integrating with the rest of the distribution, any of the other reasonable things a distributor does for which they shouldn’t have to get approval from upstream before distributing. A distribution could look at a “no malware/adware” restriction and know that they won’t have to run every change by upstream or worry about a last-complaint from upstream asking them to rename the package.

    As for a definition of malware or adware, I don’t think that would prove too hard to come up with. Adware, for instance: “any mechanism which automatically plays, displays, or downloads advertisements, other than those normally provided by user-requested websites as part of normal web browsing”. More to the point, though, I don’t really see any problem with just using the terms “adware”, “malware”, “spyware”, etc, and going with an “I’ll know it when I see it” definition. Rarely do such things fall in gray areas, and FOSS distributors don’t do anything that would come anywhere close.

  15. @Gerv: Sorry that I missed your response.

    When I suggested that downstream FOSS distributors wouldn’t have a problem with that narrower trademark restriction, I didn’t necessarily mean that the trademark license would qualify as FOSS. However, the Open Source Definition and the Debian Free Software Guidelines both explicitly allow requirements to rename modified versions, and Debian at least has said before that they don’t mind distributing software with such a requirement under the original name, knowing that someone downstream from them might have to do the renaming if they modify it. So, I don’t think such a requirement poses any legal problem.

    I primarily suggested that narrower restriction because it would make life simpler for distributors which might want to make non-malicious modifications. For example, building against system libraries, or backporting security fixes, or integrating with the rest of the distribution, any of the other reasonable things a distributor does for which they shouldn’t have to get approval from upstream before distributing. A distribution could look at a “no malware/adware” restriction and know that they won’t have to run every change by upstream or worry about a last-complaint from upstream asking them to rename the package.

    As for a definition of malware or adware, I don’t think that would prove too hard to come up with. Adware, for instance: “any mechanism which automatically plays, displays, or downloads advertisements, other than those normally provided by user-requested websites as part of normal web browsing”. More to the point, though, I don’t really see any problem with just using the terms “adware”, “malware”, “spyware”, etc, and going with an “I’ll know it when I see it” definition. Rarely do such things fall in gray areas, and FOSS distributors don’t do anything that would come anywhere close.