ZeroMQ and Crossroads I/O: Forking over trademarks

By Jake Edge
March 28, 2012

Trademarks and free software projects have something of a troubled history. On one hand, a trademark can protect the project from others using the name but offering sub-standard—or malicious—versions of the software. On the other, whoever holds the trademark also holds much of the power over the project as a whole. That can lead to conflicts, which is what we are seeing in a recent fork of the ZeroMQ (aka 0MQ or ØMQ) project.

ZeroMQ is a high-performance asynchronous messaging system that is based on BSD sockets. Two of the developers working on the project, Martin Sustrik and Martin Lucina, wrote about ZeroMQ for LWN in January 2010. Sustrik is the chief architect of ZeroMQ and, up until recently, served as the de facto "benevolent dictator" for the project, while Lucina has been working on the project since late 2009. On March 15, the two of them announced a fork of the LGPLv3-licensed ZeroMQ code as Crossroads I/O version 1.0.0.

The ZeroMQ trademarks

There were two main reasons cited for the fork in that announcement, but based on an email exchange with Sustrik and Lucina, the trademark issue is clearly paramount, at least for Sustrik. The trademark is held by iMatix Corporation which funded the early development of ZeroMQ. That trademark is governed by policy that essentially gives iMatix full control over how the names (ZeroMQ, 0MQ, ØMQ, and zmq) can be used.

That worries Sustrik for a couple of reasons. He believes that the underlying protocols for ZeroMQ should be standardized via the Internet Engineering Task Force (IETF), but that is not something that is easily done using volunteers:

Consider just the trivial case of standardisation of underlying protocols in IETF. The protocol developers should meet at IETF meetings, with average costs being some $4000 per developer and year. It's definitely not a volunteer activity. Same need for funding applies to large-scale testing, hardware implementation etc.

His solution to the funding problem is to allow companies to make money by releasing modified versions, plugins, and extensions that can use the ZeroMQ name, which is something he says the current policy does not allow:

Here the trademark policy comes into the picture. People can technically do this stuff but cannot link its name back to 0MQ. You cannot create "Foobar Enterprise 0MQ" in the way that Red Hat have created "RH Enterprise *Linux*". You cannot write an extension and release it as "0MQ toaster control unit". Etc.

Given that trademarks are at the center of the disagreement, it is ironic that the trademark policy was created at Sustrik's request in May 2011. In a message on the zeromq-dev mailing list, iMatix CEO Pieter Hintjens noted that he created a policy and asked for feedback. There were no major complaints about the policy in that thread, but a suggestion from Sustrik that the trademarks be handed to a foundation (like Software in the Public Interest, which holds the Debian trademark) was not something that Hintjens was interested in:

To be honest, the trademarks represent non-trivial value to iMatix and it would be hard to literally give them away. This is not really an option, though it's one I've considered. There would have to be compelling reasons (e.g. real dysfunction that puts the community at risk), and it'd have to include the domain names.

But Sustrik is concerned that some day the trademarks could fall into "hostile" hands, which could essentially take control of various ZeroMQ-related projects (like the language bindings for roughly 30 languages) by asserting a different trademark policy. That also may make it difficult for ZeroMQ to attract companies to work on the project: "If I was a commercial entity I would be hesitant about investing in such a project". One of the early goals for Crossroads I/O is to find a "neutral entity" to control the trademark by the end of 2012. Until then, the policy states: "'Crossroads I/O' is trademark of Martin Sustrik. Martin Sustrik grants everyone the right to use the trademark with products related to Crossroads I/O (packages, plugins, extensions, tools and similar)."

Development process changes

Since a trademark owner can decide what gets to be called "ZeroMQ", it can also make fairly sweeping decisions about how the project is governed and released. According to Sustrik, after the 3.1.0 beta release, he was "explicitly prohibited to use [the] ZeroMQ trademark, which gives me no other chance than to fork". That prohibition came in a private message from Hintjens, he said. Around the same time, Hintjens posted a proposal for maintenance of libzmq (the heart of ZeroMQ) that makes no mention of a single maintainer, which is the role that Sustrik thought he had been filling.

In a Google+ posting (which Lucina called an "objective writeup"), Ian Barber pointed to a problem that may have been part of what led to the new development process: "Martin Sustrik was effectively a bottleneck for getting improvements into core, and was clearly being pulled multiple directions on features and functionality in the project".

As might be guessed, Hintjens has a somewhat different view from that of Sustrik and Lucina. In an email exchange, he noted that Sustrik was "in danger of burning out", which is part of what led to the changes. In addition, he doesn't see the trademark policy as a problem:

Read that "hostile trademark policy". What it really says is, "iMatix will use its trademarks to ensure that only work done by the 0MQ community can call itself 0MQ". Martin Sustrik asked me to draft it, I did, he liked it, and we used it.

According to Hintjens, Sustrik and Lucina "happily ignored about a year of consensus on process, and unilaterally decided to take back control over stable releases" when they made the 3.1 release. That didn't sit well with some of the other contributors to ZeroMQ, which is what led to codifying the process and, ultimately, the fork.

The new process (scroll down to "Contributing to libzmq") is more wide open than that of most free software development projects. Anyone can fork the Github repository, make changes, and request a pull into the mainline. The maintainers are only meant to enforce process, ensure that the test cases pass, and are not allowed to impose their opinions on the quality of the code or feature. If others in the community are not happy with a particular patch, they are supposed to make another patch that fixes or reverts it—the maintainers are just there to apply it. The underlying assumption is that the community members will find and fix problems quickly by getting those changes in front of them sooner.

Barber calls the process "incredibly open", in fact, more open than he is comfortable with, but it has worked well so far:

That said, there hasn't been a stable release rolled under the current process yet and whether it'll be a usable long-term model remains to be seen - but the plus side is that if it does work, it'll definitely scale. It is, in a large way, an experiment, to draw in more code, and more ideas and I respect the thinking behind that.

Crossroads I/O is going to use the more common "benevolent dictator" model, with Sustrik in that role. Barber says that makes sense, because it is a proven model for open source development, but he is concerned that Crossroads will hit the same problems that ZeroMQ ran into. He also notes that while Sustrik and Lucina have both contributed a great deal to ZeroMQ, they are far from the only contributors to the project. It's not clear, at least yet, if others from ZeroMQ will start working on Crossroads I/O, nor whether the language binding authors will support both projects. That leaves users in a bit of a quandary, he said.

In any case, the new process installed by Hintjens is something of an experiment: "We will try it for a while and if it proves broken, we will fix the breakage and continue to improve it." But that experiment, coupled with what Sustrik sees as a restrictive trademark policy, is enough to cause the fork. What remains to be seen is if Sustrik and Lucina can build enough of a community to continue with their plans.

It is, at least in some sense, a friendly fork. Hintjens greeted the Crossroads I/O announcement with: "Congratulations on this, guys. It's nice to see the LGPL in action." Based on the emails from Hintjens, Sustrik, and Lucina, there was certainly some initial hostility and hurt feelings because of the fork, but, in the end, both sides seem to wish the other well. The two code bases share the same license, so there is no reason that patches cannot flow between them.

Hintjens noted that some may criticize the fork because it will split the community, but he strongly defended Crossroads I/O for a number of reasons. For one, he sees it as a place to do more experimental work, while ZeroMQ focuses on stability. He is also interested in seeing which of the two development models works out better over the long run. It will also provide a choice of free solutions for users, he said.

This fork, like most, comes out of a difference in philosophies between two sub-groups of the project. Unlike other forks, though, it doesn't come about because of license disagreements. It is interesting for another reason, however, as it serves as a reminder that a trademark holder can exercise a great deal of control over a project. Since the owner of the trademark can effectively decide what gets to be called by that name, they can override the wishes of longtime developers.

From all appearances, much of the ZeroMQ community is not upset with the changes or the fork. But most also seem to be keeping an eye on what Crossroads I/O is up to. If Sustrik and Lucina can make the benevolent dictator model produce a better messaging library than the more open ZeroMQ model does, there may be a shift toward Crossroads. By taking the trademark question off the table with a more liberal policy, Crossroads may attract some of the companies that Sustrik worries are put off by the ZeroMQ policy. That remains to be seen, of course, but what we do see is yet another example of the problems inherent in the coexistence of trademarks and free software.

to post comments

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Mar 29, 2012 11:38 UTC (Thu) by wookey (guest, #5501) [Link]

<blockquote>You cannot create "Foobar Enterprise 0MQ" in the way that Red Hat have created "RH Enterprise *Linux*".</blockquote>

I don't follow the logic of this. 'Linux' is trademarked too, just like '0MQ'. Wide usage is allowed due to a liberal policy and light application of the power trademark law provides.

0MQ could be the same if it wanted. It's not entirely due to trademark law per se. Now perhaps the point is that iMatix/PeterH aren't prepared to chnage the policy at all, but they seem pretty reasonable to me in the linked communications.

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Mar 29, 2012 17:33 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

In general, things that become IETF standards have different standard names from the names they originally had, when a company has a trademark on the original name. For that matter, a standard has to permit competing implementations, which are obviously going to be not from the ZeroMQ community but confusingly similar to ZeroMQ, and therefore violate any sensible trademark policy on that name. Of course, "Crossroads I/O", while a fine project name, isn't any better for this purpose. If they want to have a standard, they'll need a generic name, like "facial tissue" or "copy machine" or "XMPP", and that's what other companies would claim support for without having conflicts with trademark policies on it.

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Mar 31, 2012 16:36 UTC (Sat) by giraffedata (guest, #1954) [Link]

You seem to be talking about the name for the protocol, while the trademark in question is the name of a piece of software that implements the protocol. I don't believe it would satisfy Sustrik if the protocol were given a new non-proprietary name while iMatix retained the trademark on the piece of software Sustrik works to distribute.

The freedom to use the mark that Sustrik advocates wouldn't be the freedom for a developer to call his code "Foobar Enterprise 0MQ" to indicate that it uses the same protocol as the original 0MQ; it would be the freedom to call it that to indicate that it contains all the features of the original software.

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Mar 29, 2012 23:55 UTC (Thu) by xtifr (guest, #143) [Link]

This isn't the first case where a project has been split purely over trademarks with no difference in the copyright license, and with the ability for patches to flow freely between the projects. Debian Iceweasel is the same. Of course, Iceweasel simply tracks Firefox, and imports any changes; there's no actual independent development going on on the Iceweasel side. Still, I think it's an interesting precedent.

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Apr 4, 2012 4:00 UTC (Wed) by chloe_zen (guest, #8258) [Link] (2 responses)

... because what zeromq needed most was more confusion. :-(

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Apr 5, 2012 8:06 UTC (Thu) by kragil (guest, #34373) [Link] (1 responses)

Forks are good.
It's evolution, baby.

The meanings of a fork

Posted Apr 30, 2012 21:05 UTC (Mon) by ncm (guest, #165) [Link]

Each fork is an adaptation to a failure. Opinions will differ on the nature of the failure. The ability to fork is good. The fork itself may be good, under the circumstances. The circumstances are always unfortunate.

That's not to say that every project must avoid forks at all costs. Nothing made by humans can satisfy everybody. Failure to satisfy everybody is unfortunate but expected. If enough of those dissatisfied can work together on a fork to meet their own needs, that's a much better outcome than remaining dissatisfied.

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Apr 8, 2012 17:05 UTC (Sun) by Baylink (guest, #755) [Link]

Sure, he could call it a 0mq Toaster Control Unit.

ZeroMQ and Crossroads I/O: Forking over trademarks

Posted Nov 6, 2013 15:39 UTC (Wed) by pieterh (guest, #52123) [Link]

It's ironic that at the bottom of this page it says, "Linux is a registered trademark of Linus Torvalds".

Trademarks are important here yet not in the way presented. There were no requests from anyone to use the ZeroMQ trademarks in other products. It is strange to see that presented as justification.

The fork was simply over flatness of our playing field. Martin and Martin ("M&M") wanted special rights to release code that was buggy, incompatible, and broke user space, and call it "ZeroMQ". At the same time they felt justified in deciding the road map, rejecting patches, and imposing their vision over the codebase no matter what the cost to users.

There was an old agreement we made when we launched the project. iMatix funded it, and owned the name and domain, was responsible for the community, and by 2011, for official releases. That was my job: evangelism, documentation, community building, and making stable releases (no easy job when the master code kept changing dramatically). I've been the benevolent dictator of the community since the start, though didn't interfere in the process until there were problems to fix.

In 2011 we found ourselves with no less than four incompatible versions: 2.x, 3.0, 4.0, and then a 3.1 cowboy release, which M&M made while I was flying home from Seoul, after we'd spent a full week together there. At that point I reached out to Mikko, Ian, Chuck, and with their help codified the rather harsher process we use today. I told M&M, these are the rules now, accept them or leave - it is LGPL, after all.

A level playing field means all contributors have the same rights. The trademark is a coercion that enforces this rule. And that's it. Anyone can fork the code and apply a different process, but they cannot call that result "ZeroMQ".

How well does the process work? Clearly, it's not the only way to make software. If I was a large firm pumping money into messaging, to build a nice conventional support business, I'd use a BSD license and a playing field that tilted my way.

However to build a truly open community, and to make software that is accurate and stable (and look at the latest V4 release, how few issues it has, and yet how far it's come), it works.

Personally, I find the ZeroMQ community, since M&M's departure, to be lively, happy, and really pleasant to work with. We've lost all the stress of broken code and weird philosophical design debates, and instead we see smooth organic growth of the code. Master is almost perfect, almost all the time. Working on ZeroMQ is enjoyable, and I think that's a feeling all contributors share. Don't take my word for it, go ask on the zeromq-dev list or #zeromq IRC channel.

If you are making free software, take a look at our process: http://rfc.zeromq.org/spec:22. It's surprisingly effective, and for that I have to thank M&M sincerely, since they were the main motivation to write it.