AMQP: Community, Patents, Openness

(Background: My initial rant on the Red Hat patent situation; my rant on the Red Hat press release).

There's been a lot of public discussion recently regarding AMQP and patents, specifically USPTO 20090063418. For the record, I will be formally objecting to the USPTO about this particular patent; regardless of who filed it or when or on what, it appears to fail the Obviousness test and I have been provided with quite relevant Prior Art that indicates that the patent should not be granted. This has nothing to do with the authors of the patent, but with the fact that I don't believe the patent is worthy of grant by the USPTO.

And for the record, I personally do not believe that software should be allowed to be patented, or that building up "defensive" patents are a good corporate response to the current insanity. However, I also understand that this is a decision that is made at board level, and no single employee below board level is responsible for their firm's patent policy, whether it be Microsoft, Red Hat, IBM, Cisco, or Some Random Startup.

Do I think that Red Hat behaved in a manner that I would deem admirable given their action in patenting an extension to an open standard? No. Do I think it's the fault of employees of Red Hat who are quite clearly feeling attacked by me? No. Just as these employees had no control over Red Hat's position on patents, they also had no control over whether they were allowed to speak to any particular person at any given time. Their lawyers were in control, and part of being an employee means following board-level rules. I don't know why their lawyers said that they couldn't disclose anything about the patent or issue particular statements at any given time, and neither do you (unless you're one of them).

Yesterday's AMQP PMC meeting was the first time that the PMC members had a chance to talk since the patent was unveiled and all the bad blood was unleashed. Here's my current take on the situation, and constructive suggestions to move forward.[1]

What Is The Specification?
First of all, a lot of the confusion and requirements of clarification come down to the precise nature of the patent grants that are part of joining the AMQP Working Group. Here's the problem: they're not public. More importantly, the definition of the term "the Specification," which appears to cause the biggest problems, isn't public. I searched on the AMQP web site, and they're not there. If I'm wrong, please let me know, but I sure as heck don't see them anywhere.

That makes it very difficult for anyone on the outside to verify any of the claims that people are making. I can't imagine that this is that commercially sensitive, heck, the W3C license grants are all public. Putting this into the public would solve a lot of problems here.

You Can't Steal People's Patents
Someone commented to me "well, why not just expand the spec every time a patent comes out?" This is prone to the precise "proprietary vendor fear" that the existing patent would be prone to. Let's look at the hardware vendors.

People like Tervela and Cisco, who are members of the AMQP Working Group, and Solace, who I've urged to become a member, have patents. And unlike the AMQP+XQuery patent, some of theirs actually are things that I think would be worthy of patenting. Having a policy that says "If you join the AMQP Working Group, we can render any of your patents moot by simply saying 'what your patent covers is now an Optional Extension to the AMQP Specification'" is just as much a kiss of death as saying "here's a patent that we filed that means if you add AMQP to your proprietary software product we'll sue you."

This matters because, as I've said repeatedly, if AMQP does not end up encompassing the existing proprietary MOM vendors, it's not going to win.

Disclose What You Can't Disclose
The Red Hat press release, in particular, was taken by many people (some who had nothing to do with AMQP and were neutral third-parties) as unnecessarily hostile, mostly because of what wasn't said. And I know that Red Hat employees have been completely absent from all public communications (excluding anonymous ones). These will be carefully orchestrated by the lawyers. That's a matter of board-level policy.

Here's what the board of any FOSS vendor who's dealing with patents needs to do: lay out the ground rules for what their employees can say and do, and tell the rest of us. Unless you do that, when you don't make a comment about a particular area, the rest of the world doesn't know why. Is it because there is malicious intent? Is it because your lawyers won't let you? Is it because you didn't deem it necessary? We don't know. We want to know, and I can't see a single rational basis for saying "we cannot tell you what we can and cannot talk about, even in the most generic terms." Meet us half-way.

Open Standards Are Exactly That
People participating in this process should expect that this is an Open Standard, and Open Standards are messy. They're delightfully, angrily, bloggingly, twitteringly messy. You think this little incident was unacceptably messy? You been following the closure debates in Java? What about HTML 5 or XHTML 1? ODF/OOXML?

My point here is that open standards are, by their very nature, subject to a large group of people piping up from the sidelines. They won't always say what you want, and they won't always behave the way you want. And that's still valuable, because they add content. This probably just happens to be the first time that I know of that AMQP has been prone to a big public fight. Get used to it.

This is actually a Good Thing. How many people do you think actually know what AMQP is now versus a week ago? How many people do you think are following what's happening in the community now versus a week ago? Public fights are signs that a community is healthy. Otherwise you end up with an ANSI Committee of the Good And Worthy And Irrelevant, and nobody listens to them anymore (I have my "pet committees" there, and not all of them are like this, but we all know some like these). They're closed, they deliberate in private for years, and only then do they hand something down from on high that the industry ignores because it's moved on in its absence. Debate, unruly as it is, means you're doing something right.

A Way Forward
I'd like to be so bold as to propose a constructive suggestion on a way to move forward. These are entirely my ideas and I've not discussed them with anybody yet.[2]

1. Publish key licensing definitions. I know that some components of membership may be legally or commercially sensitive. However, if we (as users and developers) are going to trust that everything is 100% on the level, we have to know the key terms under which patents are handled. In particular, we need to know core definitions for things like "the Specification."
   While many of these terms may seem self evident from someone in the PMC, they aren't for those of us who aren't. And that information disparity can lead to a lot of argumentation as people argue from different levels of knowledge. Level the playing field, even if only a little bit.
2. Determine an optional but interoperable feature policy. This should be for things that are not part of the required specification (and for the record, I strongly favor a minimal specification), where you still want interoperable implementations of common scenarios. This is where the Red Hat AMQP+XQuery patent would lie, because if I want to do XML-based CBR, I most certainly don't want to have 8 versions that are all just a tiny bit different to avoid each other's patents. Same with geospatial routing, dynamic multi-hop routing, whatever.
3. Assemble a clearing house for prior art. There's a lot of prior art in messaging that can hopefully develop into a massive database that can be used for the community to collectively fight against patents from non-members. Let's get this going. I don't know how to do this, but I'm sure there's a way.
4. Communicate more openly. Usually in a situation like this from another spec or working group, people from the spec committee would be talking constantly with the community in a constructive fashion. That didn't happen here. There was nothing public from the PMC for days while the process deteriorated until members of the PMC started making very inflammatory statements in public.
   As I mentioned earlier, you have to expect stuff like this is going to happen, and at least one or two people have to be empowered to talk openly and early, and need to do so. AMQP is turning the corner from something that was in a vendor niche to something that people are starting to Really Care About, and that means that you have to start dealing with people who aren't on the PMC on a regular basis, whether you like it or not.
   And some of those will be differences of opinions between PMC members which will spill out into the public domain. This is normal and healthy, and as long as people can remain civil and constructive, there's no reason why all communications should be limited to PMC-only. That's not constructive, because you will never effectively present a public face, so you have to allow for some public discussions when the PMC doesn't have a standard, quickly available response.

I want AMQP to work. I want the spec to be adopted. I want asynchronous MOM-based communications to flourish. I think we can move past this and AMQP will be stronger as a result.

Footnotes:
[1]: This is all from purely publicly available information.
[2]: For the first and last time, I am not a motherfarking sock puppet. If you think there's ever been anyone who can control what I say, you're sorely mistaken. Employers (e.g. Big Bank B) can tell me to not talk at all, but I'm not the type of person who will just repeat a party line with a straight face if I don't agree.

Red Hat's AMQP+XML Patent Press Release

Red Hat has finally come out with a statement on the AMQP Patent (USPTO 20090063418) application. I have written about this already, prior to the press release coming out.

First of all, the people who are the most rabidly angry about this are other AMQP leaders (leaders of other projects, members of the AMQP Working Group). This isn't a case where (to the best of my knowledge) Tibco is coming out and saying "don't trust those crazy AMQP people, look, they've got patent issues too!" Rather, this is a bunch of people who feel quite betrayed by someone they wanted to view as a positive member of the community who shared similar desires and goals to the rest of the community. FUD doesn't apply here, as those of us with legitimate concerns are hardly going to be spreading FUD about the thing (AMQP) that we are really pushing for.

Next, the Patent Promise and Estoppel issues notwithstanding, the AMQP working group is a mixture of commercial and open source vendors. Red Hat's Patent Promise only applies to Open Source vendors. Given that AMQP, in order to be a success at all, must attract support from commercial vendors who have no safe harbour under the Red Hat Patent Policy, this patent has the ability to poison the entire community. This is a key part of my original argument, and there's been no response from Red Hat on this.

Finally, let's take one paragraph which is, quite frankly, fictitious:

Although there have been some recent questions about one of our patent applications relating to the AMQP specification, they appear to originate in an attempt to spread FUD. There’s no reasonable, objective basis for controversy. In fact, the AMQP Agreement, which we helped to draft, expressly requires that members of the working group, including Red Hat, provide an irrevocable patent license to those that use or implement AMQP. In other words, even if we were to abandon our deeply held principles (which we will not), the AMQP Agreement prevents us from suing anyone for infringing a patent based on an implementation of AMQP specification. Moreover, our Patent Promise applies to every patent we obtain. Red Hat’s patent portfolio will never be used against AMQP, and Red Hat will support any modifications to the specification needed in future to verify that fact.

The factual inaccuracy here comes from the fact that the AMQP Agreement covers an irrevocable patent license for any patents necessary to implement the specification. AMQP XQuery Exchanges aren't part of the single document AMQP Specification. Therefore, the AMQP Agreement doesn't factor in. Therefore, this patent is not subject to an automatic grant. Remember, this patent doesn't cover AMQP itself (and nobody's ever claimed that it does). Rather, it patents a quite obvious extension to AMQP. That's the problem: it's extension rather than core.

The only way around this at the moment given the licensing of the AMQP specification would be to add XQuery-based Exchanges to the AMQP specification (make it core rather than extension). However, since most work on the AMQP specification is to make it smaller and focus on standardized/interoperable extensions, this isn't a great solution.

In short, not impressed with the response. I didn't expect more, but this isn't a great state of play for those of us who care about efficient, vendor neutral message oriented middleware.

I am aware that the AMQP Working Group is working within themselves to try to resolve this situation, and I wish them all the best luck in that!

Red Hat's AMQP+XML Patent Application: Stupid, Shifty, Short-Sighted

UPDATE at bottom of post
I've finally gotten word back from my moles that Red Hat has essentially stated that Patent Application 20090063418 is a defensive patent on an extension to AMQP to work around the broken US patent system.

This patent was filed for in 2007 [1]. The current state of it is that it's been opened up to public review, which is part of the new patent system process for allowing public feedback on "controversial" patents. Essentially, as of now, infringement rights have started (so if the patent actually is granted, if you infringe as of now, they can go after you), but the patent has not been granted. This process is set up so that you can object to the patent, usually via prior art (so if, for example, you were running AMQP with XML before 2007, or you have documentation in the public space that this was a known concept for extension, please let me or the patent office know ASAP).

The way the IP rights in the AMQP working group operate is that each member must agree to disclose and grant rights on any IP that they might hold that would be necessary to implement the AMQP specification, so that the specification isn't prone to stealth patents after ratification. So if Red Hat had gone for a patent on Direct Exchange Routing, they would have had to disclose that and license anybody else in the working group, rendering the patent effectively useless. However, because XML-based exchanges, while the most common example for a custom Exchange type in the AMQP literature, are not necessary for implementation of the spec, Red Hat were quite freely able to stealth file this patent.

While legally they are thus in their rights to file the patent, this is a really bad maneuver on the part of Red Hat.

Let's assume that it is in fact a defensive patent, as Red Hat are claiming. If it is, why not disclose it? And who are they attempting to defend, the wider AMQP community or themselves in a patent war with IBM or someone else? If they're worried that someone else was going to come in and patent this precise thing, why not just put prior art into the wild so that the community could oppose anybody attempting to patent just this thing?

Let's take worst-case scenario here:

• Solace Systems decides to implement AMQP in hardware
• They already have a hardware XML-based routing system (equivalent to the patent when not applied to AMQP)
• They release the product into the wild
• Red Hat realizes that they're not selling much MRG, because people prefer the Solace solution
• Red Hat sues Solace for damages

Do I think Red Hat is likely to do this? No. Do I think if I'm a commercial vendor I have to assume that Red Hat might do this at some point over the 17-year lifespan of the patent (assuming it actually is granted)? Yes, I have to. For all I know, Red Hat will sell the patent to a litigation firm and lose control over it in 13 years time, and then sue me for infringement 13 years in the past.

Yes, the US patent system is horribly, horribly broken. But looking for opportunities to build a defensive patent portfolio around an open standard is exactly what's wrong with the US patent system. More importantly, it's really bad for AMQP itself, and thus bad for Red Hat.

As we discovered at the qCon AMQP talk last week, one standard concern that potential adopters have is "when are we gonna get a 'real' company implementing this?" Not many companies are currently eager to run something that doesn't have companies with deep pockets behind it (some are because it's open source, some aren't). Why would I be an early adopter of any AMQP implementation when the spectre of stealth patents filed by AMQP implementers on any obvious extension to the spec may be lurking around? Why adopt anything if doing so opens me up to the threat of a lawsuit, when there isn't anybody around with deep pockets able to offer me indemnification as of yet?

The main factor here is that AMQP is not going to get beyond the early-adopter ghetto until and unless it is embraced by commercial vendors of MOM technology. To get past the initial early adopter hurdle, you need to eventually draw in Progress, IBM, Oracle, Tibco, Fiorano, all these guys. And virtually all of them have XML-based routing technology. What Red Hat has effectively done is said "the moment you support AMQP in your product, without neutering the XML-based routing you already have, we can sue you." What incentive do those firms have to adopt AMQP and thus build the community?

The blowback is already starting even in the Open Source world. Martin Sustrik has stated to me:

We are suspending any work on AMQP support in 0MQ till the issue is resolved.

In effect, this completely poisons the well of the AMQP community, and I fail to see how, short of Red Hat granting control over the patent to some other entity, they can recover from this. It would not surprise me if this effectively kills AMQP, and with it the entire basis for the messaging component of MRG.

In sum, this was a really, really, really short-sighted move on the part of Red Hat, and I highly encourage the community to fight this patent on grounds of Obviousness and Prior Art, both of which I think it fails in. And then to never trust Red Hat again in any standardization process.

Footnotes:
[1] : This effectively means that pretty much the first thing they did on getting involved with AMQP was to file patents on it. What a lovely approach!

UPDATE 2009-03-17
Red Hat has come out with a press release on this issue. Link to the press release and my response in my follow-up post on the subject.