“First off, let me say that this is a huge step forward – thereâ€™s been a great deal of uncertainty around WS-* and friends because of the various patents various companies own. Microsoft taking this step definitely helps.

“But, there are some details that worry me – firstly I am curious why Microsoft have taken the approach of this promise rather than an explicit licence. Iâ€™ve talked to various lawyers about it, and the general feeling I get is that theyâ€™d be more comfortable with a licence, but they canâ€™t point to anything obviously wrong with the promise approach.”

So I need to make it absolutely clear that if anyone feels more comfortable with a RANDZ (Reasonable and Non-Discriminatory Zero Royalty) License rather than the Open Specification Promise, Microsoft will be happy to provide them with one. The goal was simply to provide a simple, clear alternative for those who wanted one. Ben continues:

“Secondly, thereâ€™s this definition:

â€œ’Microsoft Necessary Claims’ are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification. ‘Covered Specifications’ are listed below.

“(my italics). Now, Iâ€™ve implemented a lot of software from protocol specifications, and there are two things that are extremely common:

“The specifications include many optional parts. These parts will not be covered by Microsoftâ€™s promise.

“The specifications reference other specifications for vital parts of their implementation. These parts will not be covered by Microsoftâ€™s promise.

“Now, exactly what affect these considerations have on Microsoftâ€™s promise and implementations of WS-* et al is something I have not had the time or energy to assess – perhaps others with more intimate knowledge of the specs could help me out there? Iâ€™d love to hear that, in fact, this is a non-problem.”

It may help to recall what Standards Guru Andy Updegrove says about the phrase “â€¦that are described in detail and not merely referenced in such Specificationâ€¦.”:

“While not usually phrased in this fashion, this is a common limitation intended to clarify that, for example, other standards that may be referenced, or so-called â€œenabling technologies,â€ the use of which would be required to use an implementation (e.g., the computer upon which the software is running) are not included.”

But I do understand Ben's question about the required versus optional parts of a specification and will ask our legal people to clarify.

Ben's next point:

“Another factor to consider is that (as I understand it) Microsoft are not the only people with IP around these standards. Will everyone else be so generous with their IP? Microsoft donâ€™t care, of course, because they have the usual patent mutually assured destruction – but those of us with smaller patent portfolios are not so fortunate.”

So, as always, I guess Iâ€™m an optimistic cynic.

Incidentally, another thing Kim has talked about several times is Microsoft allowing exact copies of their user interface. Iâ€™m in two minds whether its a good idea to copy it, but this promise doesnâ€™t cover the UI, as far as I can see. I wonder when that piece will be forthcoming?

I really want to make it clear that I have never suggested I would ask Microsoft to allow people to make “exact copies” of our user interface. And in fact, no one has ever asked to be able to do this.

What we want to be able to do is create a “ceremony” that is recognizable across platforms. I'm talking about the equivalent of using a steering wheel and brakes in a car. All cars have them, so even if we like a particular type of car, we can get in another one and drive it. This doesn't mean the cars are “exact copies” of each other, or even that the steering wheel and brakes look or feel identical.

As Novell's Dale Olds put it at DIDW, we are talking about sharing a predictable sequence of experiences, not cloned screens. So in this sense, I think everyone shares Ben's “two-minds” thinking.