Promises, promises

A few further random thoughts on Microsoft’s Open Specification Promise…

First, a small observation: Despite Andy Updegrove’s deliberate use of “standards” in his analysis post (and throughout ConsortiumInfo.org) to refer to all specifications that have gained some currency, Microsoft is quite careful in making the distinction between “standards” and “specifications” in its promise text. In fact, some of the questions raised by Andy have to do with the distinction — for example, what happens if one of the specs has been submitted on a standards track at a formal org and subsequently finishes that track? These orgs all have IPR polices of their own. Microsoft’s FAQ isn’t crystal-clear on this point so we’ll need to see what they say going forward.

Onward: I missed seeing Mike Jones’s response to Gerry yesterday, which answers one question: whether developers of actual CardSpace implementations are covered. The bad news is that the documentation that would fill in a large part (if not, perhaps, all) of what’s needed for building compliant CardSpace implementations is clearly not covered. The good news is that they’re working on it. Mike says:

As of today, the InfoCard/CardSpace specs are not on the list. The good news is that (a) all the web services specs underlying CardSpace are covered (which is great news!) and (b) it means we’ve done the work internally to enable us to license specifications in this way. Licensing additional specifications under these same terms should be much easier to do at this point, but I obviously can’t make public commitments yet beyond those we already have buy-off on. Watch this space for further developments…

(By the way, I really should have listed Mike properly yesterday in offering congratulations — it’s obvious he did a fair amount of heavy lifting!)

The unanswered (or unsatisfactorily answered) question has to do with what “required portions of the Covered Specification” means: Does it refer to only those portions of a spec that have RFC 2119-defined MUST (NOT)s and SHALL (NOT)s in them? The covered specs have an awful lot of MAYs in them because they’re meant to be composable and turned to many purposes; that’s why we see the need for profiles (such as those done at WS-I, the Liberty Alliance, and various vertical industry groups) for actual interoperability in deployment. It would be good to get some clarification on this point, and it sounds like Mike is working on that too:

My interpretation of the language “patents that are necessary to implement only the required portions of the Covered Specification” was that “required” refers to “portions of the specification required by the application” — not “required versus optional portions of the application”. But I’m not a lawyer and you shouldn’t take my word for it. I’ll pass this question on to those who are lawyers. ;-)

Finally: I just noticed that the list of covered specs doesn’t include the SAML Token Profile of WS-Security. I realize that this wasn’t one of those specs that Microsoft privately published first; its genesis was some work that the SAML technical committee did before tossing it over the wall to the WS-Security TC by mutual agreement. But nonetheless, it’s an important spec (nay, standard!) that Microsoft clearly has some investment in, and their name is on it to boot. So why exclude it? Hopefully this is just an oversight that can be remedied soon along with the other outstanding issues. Go, Mike!