The important part of Microsoft's covenant not to sue is only one sentence long. Here are about 100 that try to explain what it means.
Given the degree of focus that is being placed on the Microsoft covenant not to sue, especially by people that preface their comments by saying “Now, I’m not a lawyer, but…” it occurred to me that a short course on the law as it applies to intellectual property rights (IPR) policies might be in order. So here goes.
If you’re really serious about wanting to understand such matters, visit the Intellectual Property Rights Policies section of the Essential Guide to Standard Setting and Consortia that I’ve provided at this site. You’ll also find a very lengthy legal analysis by Marbux incorporated into Pamela Jone’s examination of the Microsoft covenant at Groklaw. Pamela uses a set of six observations offered by Sun’s Simon Phipps at his blog on November 28 as a point of departure.
But for those of you that aren’t that ambitious, what I’ll do here is to explain a few things that directly apply to evaluating the Microsoft covenant, also using Simon’s six observations as the framework to build upon. Here they are (indented), with my own observations interspersed at full margin:
1. Patent protection is contingent on a conformant implementation. “Conformant” is not defined, meaning there is uncertainty needing legal advice.
OK, let’s say a developer was to implement the XML Reference Schema in good faith, and wondered whether she was at risk because they didn’t know what “conformant” meant, or whether her application actually “conformed” to the degree required. The good news is that when a court tries to help a jury figure out what to do in a situation like this, it tries to find out what the understood meaning of a term would be in the industry in question, and what the prevailing practices would be in applying that understanding. You’ll see that I will be coming back to this precept frequently as we go on.
So far so good. But now for the bad news. Until relatively recently, the language used in standard setting IPR policies was surprisingly casual, because people just weren’t suing each other. That started to change when Dell Computer was investigated by the FTC in connection with a consortium it was part of, and agreed to a consent decree that required it to license its patents royalty free under the standard in question. After the Rambus case, people got even more serious. So today, words are used more carefully and precisely, but too often what people think they mean is still not uniform. For example, there is an American Bar Association Law and Technology subcommittee that has been holding bi-weekly conference calls for about a year now that is trying to create an annotated IPR policy, and they aren’t done yet.
So what does “conformant” mean, then? I believe that a jury, properly informed by expert witnesses, would conclude that “conformant” means the following:
A. “Conformant” should have the meaning that a standard setting organization would give it.
B. Standard setting organizations use several words in this general area. Most commonly, “compliant,” “conformant,” and “certified.” The last one clearly means that the product has passed a test of some sort. The first two usually mean only that the developer is asserting that it believes that its product complies with or conforms to the standard, unless the developer has specified what words can, and cannot, be used. It is also understood that the level of achieved interoperability is likely to be lower than for a certified product that has actually passed a test.
C. Since Microsoft has not defined “conformant,” then I believe that a court would apply the definition I’ve outlined above, and therefore that a good faith effort to build a product that properly implements the XML Reference Schema should be regarded as fulfilling the terms of the Microsoft covenant. This should be an adequate shield against liability.
Back to you, Simon, and I’ll try to be briefer, now that a couple of fundamental rules have been laid out.
2. There is no provision for partial implementation, meaning true community-based development is not covered until complete.
Good observation. Superficially, one might wonder why someone might care one way or the other. The reason is that if someone is going to waive their rights to assert a patent, then they expect that they will get some benefit as a result. In the context of standard setting, that benefit is interoperability which, the vendor hopes, will lead more people to buy its product. Why? Because there will be more incentive for more vendors to build products, all of which are interoperable and competing on price and features, which will lead to a bigger market demand for everyone’s product. The result is that the original vendor gets a smaller piece of a much bigger pie. But -if someone doesn’t implement the whole standard, then the original patent owner doesn’t enjoy the benefit that they hope to gain by waiving their patent rights — they’re just out their patent license fee.
Bob Sutor gives a good explanation (at a more sophisticated technical level) of why complete implementations are important here.
Some IPR policies are explicit about this, saying that the patent pledge is made to “any product that implements all required elements of the specification” and some are not, which might lead a jury to adopt the rule “if they meant it, they would have said it.” But I think on this one the right answer would be (subject to what I have to say after Simon’s next comment) that it’s understood in the trade that “conformant” means “implements the whole specification.”
Back to Simon’s list (after only three paragraphs of punditry this time!
3. It may well mean that implementation of just a word processor is impossible — it implies that you have to implement everything (spreadsheets & all) to reach the bar.
Simon’s on target with a good question again, and he points out what would make a good law school question: if you can divide a specification up into separate, independent pieces, does that make a difference?
My guess is that a court would decide that someone should be able to take advantage of the covenant to develop just that word processor for three reasons. First, because the patent owner would still benefit, because many people only need a word processor, and therefore all the documents that they would actually produce could be exchanged with owners of a full office suite. The second is that there are at least some programs in the market that are just word processors, particularly those that are embedded in other types of products, such as email packages. Most important is the third reason: if you have an electronic document that you want to be able to open in 20 years, you won’t care whether it came from a word processor or a full suite — you’ll still want to be able to access it, and that is a major goal for standardizing formats.
Simon’s turn again:
4. It is specific to the version currently existing, meaning I can be hooked into supporting it now, but when Office 12 or Office 13 comes out & I update to be compatible with the format in that I can get sued. The covenant Sun uses creates ongoing protection.
This is a serious one, and it’s one that I’ve examined at length in two prior posts here and then here. First, in fairness to Microsoft’s intention (although not it’s wordsmithing) and as I pointed out in the first of those posts, Microsoft does say at a separate page at it’s site that it will extend the same covenant to the Office 12 XML Reference Schemas. But that’s as far as they’ve gone.
Again, to be fair, the way standards organizations work, someone can always drop out and not have to make a patent pledge regarding any new parts of a revision of a specification. But its undertakings are irrevocable and perpetual as to the version of the specification that was released while it was an involved member.
What’s situationally tricky here is that if Microsoft were to drop out while it still had such an enormous percentage of the marketplace, and then abandoned complying with the Ecma standard, or even simply added new features that extended beyond the standard (the infamous “proprietary extensions”), then what?
Where that takes me is that our hypothetical jury, looking to trade practice, would say that Microsoft has no obligation to give a new covenant to anyone for a new version unless it makes that promise now, because that is the prevailing trade practice. So one hopes that Ecma will do something to close this gap as a condition to accepting Microsoft’s offer.
Simon’s turn again:
5. It does not grant patents to the ECMA standard as it only applies to Office 11 XML. This means a new covenant will be needed for the ECMA work.
As noted, at a separate pageof it’s website, Microsoft says: ” Microsoft will also be offering this same covenant with respect to the forthcoming specifications for the “Office 12″ schema specifications.” I’ve said at my blog in the two posts previously mentioned that a court would be better persuaded if that language appeared in the covenant itself.
The reason is something called the “parol evidence” rule, which basically states that if you have a contract, it’s assumed that the whole deal is in that contract. In this case, the covenant is what’s called a “unilateral contract,” or one that binds only one party (Microsoft) — but it’s still a contract, nonetheless, because Microsoft expects people to rely on it to their detriment.
Back to Simon one last time:
6. If the same form of words were used for a contribution to ECMA, then those prototyping the ongoing evolution of the standard as ECMA changed it would lose protection the instant any change was made. It applies only to Microsoft’s input, not to ECMA’s output. Or maybe they would rather ECMA didn’t change anything?
All manner of business and legal concerns are swirling around in this one. One can assume that Microsoft will want to change nothing in the XML Reference Schema that would require a change to Office, and who could blame them? In fairness, it’s also worth noting that companies contribute technology to standard setting organizations all the time to act as the basis for standards. Many accredited organizations (like IEEE, if memory serves) and consortia even require it, because they don’t want to issue a standard that isn’t instantiated in a product that people can immediately buy.
But acting as the basis for a standard, and being a completed standard, are two different things. As such things go, the Ecma XML Reference Schema working group could turn out to be a great spectator opportunity, with open source advocates answering Larry Rosen’s call to police the process, with Novell already announcing that it will be an attentive participant, and with IBM presumably taking part as well (Sun, I believe, dropped out some time back — but who knows, perhaps they will rejoin to be part of the fun as well).
But if the Ecma process bogs down, or turns into Armageddon, then who wins and who loses? After all, does Microsoft really want the XML Reference Schema to be adopted, or only to look like it’s being cooperative? Interesting question, that.
The fact of the matter is that Microsoft, so far, has only said on a Web page that it will make a covenant for the Office 12 versions of the XML Reference Schema — and not for any Ecma standard based upon those Schema that may ultimately be adopted and issued. If it wishes, it can stop right where it is, and to the extent the Ecma working group adds any extensions, Microsoft could utilize the Ecma RAND-tolerant policy for those portions of the resulting Ecma standard. And, in fact, I think that’s fair dinkum, since no other Ecma member would be required to offer more than RAND terms for any of the elements of the resulting standard, and not just for any additions to the XML Reference Schemas that formed the starting point for the working group’s efforts.
But here’s where the convergence of Simon’s first and last question bring us to an interesting conclusion: if Ecma adds to the Microsoft contribution, then a “conformant” implementation of the Ecma standard would have a subset of itself that was “conformant” to the XML Reference Schema, and the implementation would be entitled to the covenant as to the conformant part, and RAND benefits as to the balance. But if instead of adding to, the Ecma working group changes part of the XML Reference Schema, then Microsoft could say “sorry — a critical exception has occurred” — and the covenant crashes.
Would Microsoft do that?
Well, as some lawyers like to say, “I’m sorry. That’s not a legal question.”
Note: While this entry is based on general principles of law and prevailing practices in standards development organizations, the conclusions I’ve offered are purely speculative, due to the number of variables involved and the vagaries of the courts. As a result, this entry does not constitute the rendering of legal advice; please consult your own attorney before making any decisions involving Microsoft’s intellectual property rights.
subscribe to the free Consortium Standards Bulletin