Flattered but not impressed

If imitation is the sincerest part of flattery, then we at Sun feel very flattered by Microsoft's decision to start using non-assert covenants as a way to give developers freedom from fear in their use of standards (even if they don't credit us). Like Andy Updegrove, I've taken some time to consider their document, and I've some comments I hope they'll take on board when they get round to making a covenant that actually applies to Office 12 or to the work they'll offer to Ecma International (neither of which has happened yet1).

In the spirit of contribution, then, here are six observations about their covenant:

  1. Patent protection is contingent on a conformant implementation. "Conformant" is not defined, meaning there is uncertainty needing legal advice.2
  2. There is no provision for partial implementation, meaning true community-based development is not covered until complete.
  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.
  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.
  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.
  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?3

Together, these six problems seem to be show-stoppers for open source, no matter how positive Brian Jones or even Larry Rosen may feel about it all - as David Berlind says, we only know they won't sue what they unilaterally consider to be "conforming" uses. As it stands, I don't think their covenant gives open source developers sufficient confidence to implement the spec it covers4, let alone the forthcoming specs that it doesn't5. Assuming Microsoft intends, as they say, to open their data formats, we expect to see some further work and clarification to address these issues6.



  1. Update: I note Brian has commented that the same words will be used for the Office 12 formats.
  2. It's been pointed out to me that the use of the word "conformant" probably also renders the specification unimplementable under the GPL by placing a restriction on usage that does not appear in the GPL.
  3. Stephen O'Grady hints that maybe that's the whole point...
  4. I am advised to point out that I am expressing my opinion and not offering legal advice which, of course, is something you can only get from a qualified and expensive professional.
  5. One other problem: right now, the only way to even see the specs is to use Microsoft Office as they are packaged only for use with that product. Consequently I would have to agree to the Office EULA to proceed, and the covenant explicitly avoids changing those terms.
  6. Not to say this isn't a huge step forwards for Microsoft. Congratulations, folks, keep stepping.
Comments:

Same here, I've looked at the covenant and left very unimpressed. It might be a huge step for Microsoft, but it's a small step for the rest of us who may end up implementing those technologies and having to deal with the wishy-washy language. cheers, dalibor topic

Posted by guest on November 29, 2005 at 04:37 AM PST #

As an update for this article 1. Micrsoft has added a conformance paragraph in the specification itself which specifically allows for a partial implementation 2. The covenant is now added to the promise for a whole serie of micrsoft formats and standards of which Ms now states not to use its patents. 3. The promise is now updated for the current final Ecma draft (which is bound to become standard) and future versions. 4. Ecma standardization has ment a tremendous change to the earlier specs. The expressed view in this article that MS would not like change has clearly not been seen by the Ecma technical committee.

Posted by hAl on November 28, 2006 at 12:16 AM PST #

Post a Comment:
Comments are closed for this entry.
About

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today