A belated look at the Red Hat/Firestar patent settlement

The suit involves patent #6,101,502, which claims the concept of creating an impedance-matching layer to connect relational databases to object-oriented applications. The first claim reads like this:

One might well wonder how object-oriented programmers managed before 1998, when this patent was filed. Firestar claimed that a piece of JBoss violated the patent and duly filed suit; Red Hat has been fighting back ever since. The June 11 announcement appears to bring an end to this particular dispute.

While Red Hat has not agreed that it was in violation of this patent, the company did not reach a settlement which clears it of infringement. Instead, Red Hat agreed to license the patent for itself and for its customers. The thing that makes this settlement a little more interesting is that Red Hat did not stop there; it also obtained a license for the project's upstream developers. From the settlement FAQ posted by the company:

The press release adds:

So, in other words, this license and covenant covers the "predecessor versions" of any package shipped by Red Hat. Once a particular project finds its way into RHEL, it's part of the deal.

This very carefully-worded text leaves one very interesting question open: what about users of the software who are not Red Hat customers? It would appear that developers are covered, presumably even as they develop the program beyond the "predecessor version" shipped by Red Hat. It has been made abundantly clear that Red Hat's customers are covered. There is a lot of text in the press release and FAQ suggesting that non-customer users should be protected too, but that is never said explicitly. An omission like that in a carefully-written, lawyer-vetted document can speak loudly; one must wonder what is going on.

Another interesting question is this: what about all of the other projects out there which are using object-relational glue layers? One can only assume that this set includes just about every object-oriented application which is using a relational database. The language makes it pretty clear that this patent has not been licensed for free software in general; it only applies to the specific piece of JBoss which was under dispute. The press release claims that the settlement covers derivative works, leading one to imagine that it would be possible incorporate some small function from JBoss into an entirely unrelated project and get the patent license with it. But there is no way to know whether this interpretation matches the real settlement or not.

And therein lies the real problem at this time: the actual terms of the settlement, and of the licenses and covenants, have not been published. One presumes that will change at some point; your editor queried Red Hat on when that might be, but did not receive an answer by the time this article was written. Without knowing what the actual agreement is, nobody can really assume that they have received any protection at all.

One other claim from the FAQ merits attention:

All of this is somewhat debatable, and needs to be questioned. As noted above, the actual breadth of the protection obtained is yet to be disclosed. The more relevant question, though, is: did Red Hat really "stand up for the community" in this case, and will it discourage these cases in the future? Your editor is not convinced of either.

The way to stand up against this patent aggressor would have been to invalidate the patent and put an end to it forevermore. A quick trip to your editor's bookshelf turned up David Taylor's Business Engineering With Object Technology, dated 1995, which discusses difficulty with relational databases and impedance-matching layers. Grady Booch's Object Solutions (1996) says: "Thus, it is reasonable to approach the design of a data-centric system by devising a thin object-oriented layer on top of a more traditional relational database technology." Or look at Object-Oriented Modeling and Design by Rumbaugh et. al. (1991), which has an entire chapter on mapping objects into relational databases.

In other words, there can be no shortage of prior art in this case; this is not an idea which was first conceived in 1998. But, rather than take this approach, Red Hat chose to settle. It is not said anywhere, but chances are good that some money changed hands here, and, by accepting a license for this patent, Red Hat has given it some legitimacy. Other free software projects - those which Red Hat does not ship - have apparently been left open to the same attack. Is this really the way to "discourage future similar cases"?

Of course, such criticism is easy to make from the sidelines; it's easy for those of us not directly involved in the suit to claim that Red Hat should have taken the higher-risk, higher-expense road and fought this case to the end. There is no doubt that such an approach would be better for the community - assuming Red Hat prevailed - but Red Hat's management must make its own choices about which battles it is to fight. Given that it chose to settle, Red Hat clearly tried to do the right thing by obtaining some sort of protection for the community beyond its customer base. Time will tell how well that will work out and whether it will serve as a model for future settlements or not.