New approach to licensing with the Office XML formats

Well, as expected there is a lot of speculation out there about what the new approach we’ve decided to take with the license may mean. Yesterday I posted about our move to standardize the Office XML formats and to change the license based on feedback we’ve received over the summer and fall. Maybe folks were wandering what the implications are of an ‘Irrevocable Covenant Not to Sue’ or CNS approach, which was reported in some places. We are just posting the license today, so that should help clear up a lot of the questions. The posting of the new license approach is here:

While you should use that link for the official statement, I’ve also copied the contents and pasted them here so you can all take a quick look. Notice that it currently says that it applies to the Office 2003 schemas. That’s because we haven’t submitted the Office 12 schemas yet. We’ll of course update this to cover the 12 schemas as soon as we get those posted. Here’s the text:

Microsoft Covenant Regarding Office 2003 XML Reference Schemas

Microsoft irrevocably covenants that it will not seek to enforce any of its patent claims necessary to conform to the technical specifications for the Microsoft Office 2003 XML Reference Schemas posted at (the “Specifications”) against those conforming parts of software products. This covenant shall not apply with respect to any person or entity that asserts, threatens or seeks at any time to enforce a patent right or rights against Microsoft or any of its affiliates relating to any conforming implementation of the Specifications.

This statement is not an assurance either (i) that any of Microsoft’s issued patent claims cover a conforming implementation of the Specifications or are enforceable, or (ii) that such an implementation would not infringe patents or other intellectual property rights of any third party.

No other rights except those expressly stated in this covenant shall be deemed granted, waived or received by implication, or estoppel, or otherwise. In particular, no rights in the Microsoft Office product, including its features and capabilities, are hereby granted except as expressly set forth in the Specifications.

We tried again to take a thoughtful approach to this, to go beyond any Standards norms that we know of for this special case of document formats. I’m sure it’s obvious that the discussion and debate of the licensing issues following the State of MA policy were useful helping us understand the many different views and how to give the most confidence to people about a licensing approach. Now you can look for yourself at what we came up with. We are really hopeful that this will be the sort of breakthrough that people have been looking for. Here are some of the big points that you should take away from this new approach:

  • There is no longer really a license that people need to sign up for in any way – You don’t need to sign anything or even reference anything. You are free to use our formats as much as you want and you don’t need to make any mention or reference to Microsoft. You can implement these formats so that you can both read and write the formats with your technology, code, solution, etc.  In other words we will not sue people for using the formats even if it is competitive software.
  • Patents – We eliminated the license to patents language and are instead providing a irrevocable commitment to not sue anyone based on the patents we have in the formats. This of course doesn’t apply to anyone that sues us saying that they have patents on our formats, but as long as you don’t do that, you are free to use our formats and you have nothing to worry about regarding our patents.
  • Why do we have patents at all? – We do it primarily to be able to innovate and protect ourselves at the same time. Having patents gives us the ability to fend off patent lawsuits that are the inevitable result of being a big company and delivering new technology. We make the decisions to patent technology very early in the development phase of our work, which is necessary because you can lose your IP rights if you don’t file patent applications before you make your invention public. Then later we determine our licensing of the technology in conjunction with product decisions. In this case we are deciding to not enforce them as long as you don’t enforce patents you may have on the formats against us.
  • Transferability of your solutions and “GPL Compatibility”– If you want to build a solution that works with our formats you’re free to do so without worrying about patents or licenses associated with our formats. Additionally, the covenant not to sue would obviously apply just as well to anyone that uses your solution or modifies it. This is why I said yesterday that it ‘could’ work with projects built under the GPL license. The prior problems with attribution and sub-licensing are now non-issues. But honestly, I am told that the GPL is not universally interpreted the same way by everyone, so we really can’t make definitive statements about how our language relates to it. That is for lawyers and courts to pass judgment on. So basically we wanted to be really simple, clear, and straightforward and provide security to the developer that we won’t sue them for the IP in the formats. Sun took a similar approach recently for the OpenDocument format, perhaps for the same reasons, so hopefully we’re both on a track here that folks can be comfortable with.

Let me be clear that at the issues at the top of our minds were to: a) give real, practical security (confidence) to developers, b) think about how to insure things would be OK a hundred years from now when laws are different and technologies are different, and c) protect ourselves, as our shareholders expect.

We are absolutely open to discussions around this new approach. If you have concerns about this approach for something you are trying to do, you can send email to this alias and we’ll try to respond broadly at least to the topics that several of you raise, although we can’t really give out legal opinions.


Comments (38)

  1. S. Colcord says:

    This is far better than any prior license I’ve seen Microsoft use. However, I have two remaining concerns:

    1) Does this covenant also cover derivatives of the Specifications? If the MS schemas become an ISO standard, and the ISO committee makes changes or updates to that standard, can Microsoft pursue patent claims against implementers of the derivative standard?

    2) What happens if an application does not perfectly conform to the spec? Very few specs have fully conforming implementations; C++ compilers and web browsers, for example, still have minor compliance issues with their guiding specifications, even though those specifications have been public for many years. Would implementers be exposed to potential patent claims, during the considerable period within which their implementations are imperfect?

  2. BradC says:


    Looks good! I hope this will lay to rest the remaining objections. (Although expecting confetti from the slashdot crowd is probably not realistic…)

    My tries at Colcord’s questions:

    1) I would guess that from a legal standpoint, a document like a "covenant to sue" needs to be pretty specific about what people are allowed to use. Right now it points to the Word ML2003 spec, and after it is published, should also point to the new Office 12 spec. I would imagine that if it goes through ISO, this same covenant document would be updated to cover that as well.

    2) Even if you thought this was a valid legal concern, I highly doubt that any judge in the country would accept this legal loophole. I wouldn’t be terribly worried about it.

  3. S. Colcord says:

    Reply to Brad:

    1) I think that this possibility would be troubling to many. If the covenant does not cover derivative specifications, then Microsoft retains an effective veto over any changes that might be made by the standards committee.

    2) IANAL, but a lot of the controversy over these formats revolves around legal loopholes. Independent developers in particular aren’t going to want to gamble about how a judge might interpret this clause, as they’d have to argue the point against Microsoft’s legal team.

    If Microsoft were to change the end of the first sentence from "…against those conforming parts of software products." to "…and any derivative specifications.", it would resolve both of these concerns, and to my non-legal eye, meet any reasonable test for openness that might be proposed. I think that Microsoft has a lot more to gain here by being totally unambiguous than they do by using any language that might permit doubting their intentions, since they can be certain that their opponents are going to try to cast it in the worst possible light. Why give them more ammunition?

  4. jason says:

    Truly great news. About the format, but also about new attitudes from Microsoft. If you keep on this track, you will eventually get the confetti!

  5. Todd Knarr says:

    I notice that, although the convenant’s been documented, the license itself hasn’t changed (I just checked the official license text at The problem with this is that the fact that someone promises not to sue you for doing something in violation of the license doesn’t make it any less a violation of the license. The new covenant doesn’t do anything to address the problem that an implementation still can’t grant users it’s distributed to a license to use any patents (the no-sublicense term is still there), and the problem with "enabling technologies" being excluded from the license’s coverage (disturbing when the license explicitly says enabling techologies "such as general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like."). If Microsoft were truly committed, why not simply make the things they want to allow allowable under the license, instead of this convoluted ambiguous approach?

    I had a lawyer give me some excellent advice: people don’t generally put things in contracts for your benefit, unless it’s part of an explicit deal to get you to accept something else you normally wouldn’t. If you see a term in a contract that doesn’t seem to have any reason for being there, or that’s convoluted and open to interpretation, ask for it to be removed or stated in a clear and unambiguous way. If the other party doesn’t want to clear it up, assume they plan to use that term to their own advantage later on.

  6. BradC says:

    Reply to S. Colcord:

    I looked back at the agreement again, and I think you are reading that sentence wrong.

    I read the last sentence of the first paragraph as "Our promise not to sue doesn’t apply if you threaten to sue us based on a patent that you claims applies when people use this specification".

    Let me trim down some of the legal redundancy in the sentence and see if it makes more sense:

    "This covenant shall not apply with respect to any person that seeks to enforce a patent right against Microsoft relating to any conforming implementation of the Specifications."

    So if you threaten to sue Microsoft based on some Patent that you think would apply to everyoneone who implements the spec, then MS has the right to defend itself, and counter-sue.

    If you think about it, this last sentence is the EXCEPTION–it tells when MS *CAN* sue someone. If you change the language to "any derivative specification", you are allowing MS a BROADER EXCEPTION to their covenant not to sue.

  7. S. Colcord says:

    Reply to BradC:

    My prior post referred to the end of the first sentence of that paragraph, not the last.

  8. Eduardo says:

    I am not quite sure what to think about the new license. However, I am quite sure that I am very confused as to Microsoft’s attitude toward openess.

    For months, up to just a few days ago, Microsofts official, oft-repeated position was that the old XML license was as open as Microsoft could reasonably be expected to make it, and that any additional openess would not provide any significant benefits to users.

    Now suddenly Microsoft announces that it is making its XML significantly more open, and that this would provide great benefits to users.

    These two positions are obviously in great contradiction. Perhaps next year it will change its mind again and decide that less openess is better.

    As to the idea that Microsoft has changed its position on openess as a result of discussion and feedback, isn’t this just what Microsoft has been critizing Massachusetts for?

  9. BrianJones says:

    Hey Eduardo, I haven’t heard from you in awhile. Welcome back. I have to admit that I’m not really sure I follow you on this. I figured you would have been happy with these changes. Are you just assuming that there must be a catch?

    We had felt that the original licenses we were using were great. I’d said it a number of times, but as you know many people disagreed (you were one of those if I remember). So, we’ve spent a long time looking into the licenses and tried to figure out if we just weren’t explaining them properly (since there were a number of different interpretations), or if we actually needed to take a different position. As I’ve always said, our goals with these formats are for developers to have security and confidence in their abilities to build software on top of them. That is absolutely a top priority, and without that confidence, the formats wouldn’t be a success.

    I also don’t believe we ever criticized Massachusetts for getting feedback. I believe the criticism was that we disagreed with their new viewpoint based on some of that feedback. We felt that with the old licenses and our plans for documentation, we should have been viewed as an open format. We had a number of government agencies who agreed with us. The Danish government even had a website set up where they hosted our schemas. But, as I said, it was clear that we needed to go a bit further given the FUD that was being spread, so we decided to make this move so that there could be no doubt. I think it’s great, and I thought you would too.


  10. Wesley Parish says:

    "No other rights except those expressly stated in this covenant shall be deemed granted, waived or received by implication, or estoppel, or otherwise."

    What rights have been expressly stated? Only the right not to be sued for use of Microsoft’s software patents.

    Marbux had a very interesting article on Groklaw on this very subject:

    In particular, note these words:

    "The license is structured to be read restrictively, in Microsoft’s favor. At the end of the license, it states that:

    "All rights not expressly granted in this license are reserved by Microsoft. No additional rights are granted by implication or estoppel or otherwise."

    (Emphasis added.) This is not the customary "all rights reserved" phrase more commonly encountered. A short translation of the language quoted is in order: Those two sentences mean exactly what their plain words say. If you can not find words in the license explicitly stating that you have the right to do something, you don’t get that right. Microsoft keeps that right; it is not yours. Forget everything but what the words of the license actually say."

    Wise advice. I think Microsoft is trying to sell a pig in a poke here. It has absolutely nothing to do with licensing the MS Office 12 XML schemas in such a way as to make them usable by anyone else, let alone to allow someone the right to sublicense under a reciprocal license such as the Microsoft Community License or a permissive license such as the Microsoft Permissive license.

  11. orcmid says:


    "No other rights except those expressly stated in this Patent Statement shall be deemed granted, waived, or received by implication, or estoppel, or otherwise."

    Our friends at Sun Microsystems in their latest IPR statement for OpenDocument:

  12. Angus Chan says:

    A simple question, what do you mean by "works with our formats"? Can i write a GPLed Word viewer?

  13. Patrick says:

    An article mentions the following (,1895,1892155,00.asp):

    "A big part of the missing bits are: semantics between tags, OLE [object linking and embedding], DRM [digital rights management]. All of that needs to be known in order to operate across platforms whether on the client-side, or through Web services"

    I am interested in the DRM role in this story and the way DRM interacts with MS XML esp since Microsoft is an active DRM proponent.

  14. Wesley Parish says:

    True, orcmid, I realized that after I’d read the commentary by Updegrove:

    I think the difference between the Sun and Microsoft is that Sun already had a reference implementation that was licensed under the LGPL in the form of the SX? and the evolving ODF file formats, so whatever it said in its Covenant had to be taken in that context;

    Microsoft hasn’t done anything of the sort – I mean, they could release a reference implementation of OfficeXML or whatever the nom-du-jour is, on SourceForge as the source code for a file reader/writer/converter under the Microsoft Permissive or Community License, and that would provide the same sort of public context.

    They haven’t as yet; I wonder if they ever will.

  15. Andrew Davis says:

    I find it interesting how questions are selectively answered on this forum. And when questions are answered, they are vague and inconclusive. Mr. Jones responded to Eduardo, but never bothered to truly answer Eduardo’s question.

    Let me be more direct than Eduardo:

    Was Microsoft lying to the public when it stated that it couldn’t open it’s standards any more than it already had? You are aware that this announcement flies in the face of Microsoft’s earlier claims.

    So Mr. Jones, what’s the truth? Was MS lying? No mincing words, mind you. Give us, your customers, the straight poop. A large pepperoni pizza says you won’t even respond to this message.

  16. BrianJones says:

    Wesley, did you know that OpenOffice 2.0 can read and write the Office 2003 XML format (WordprocessingML)? There are tons of implementations out there that work with those formats. The new formats for ’12’ aren’t done yet, so it’s not really a suprise that there aren’t many implementations out there yet.

    Andrew, this isn’t a forum. This is my blog. I use this to post information about a technology that I care deeply about.

    I have no idea why you think we were every lying. Show me the two quotes that make it look like we’re lying and I’ll happily answer.

    What version of Office do you use Andrew? Have you used the XML functionality yet? Has it given you any trouble and do you have any questions on that?

    Happy Thanksgiving everyone (for those of you who celebrate Thanksgiving that is).


  17. Brian,

    Whether or not you’ve opened up the standards enough is irrelevant from one point of view – Microsoft has lost a lot of trust in the Tech Industry, and it will take years of dedicated effort to gain that trust back.

    I haven’t read the full documentation yet, so I don’t have an opinion as to whether you’ve done a proper job or not. Gut instinct (I’m one of the people that you managed to alienate) is that you didn’t. But maybe you did – if so I’ll congratulate you. If you didn’t I’ll tell you.

  18. Wily Yuen says:

    > Wesley, did you know that OpenOffice 2.0 can read and write

    > the Office 2003 XML format (WordprocessingML)?

    Hey, Brian, the support of Office 2003 XML is covered here not because the license of Office XML Schema is liberal, but because Sun and MS have reached an anti-trust settlement over a year ago:

    On Patents and Intellectual Property:

    The parties have agreed to a broad covenant not to sue with respect to all past patent infringement claims they may have against each other. The agreement also provides for potential future extensions of this type of covenant. The two companies have also agreed to embark on negotiations for a patent cross-license agreement between them.

    Just let me say it straight, one of the unofficial project I know, where developers from Taiwan are working to enhance the Chinese support in 2.0 was afraid to release the Windows version (they only released Linux version so far) because of the restrictive license of Visual Studio 2003 on the msvcrt71.dll library, which you can see here from the Python developer mailing list:

    Open source developers take IP issue seriously. And it is obvious that other than parties who have agreement with MS (such as Sun), I think in general the license of Office XML Schema is not clear and assuring enough when Microsoft is the only party that can decide the fate of it, including withdrawal from standard body if it chooses to do so.

  19. krp says:

    Hi Brian,

    I see a a sizable problem with the company’s covenant not to sue. In short, it isn’t.


    "Microsoft irrevocably covenants that it will not seek to enforce […]."


    The problem is the word ‘will’. Will is permissive. Hence it means the exact same thing as the word ‘may’.

    Using the above quote and changing one word:

    "Microsoft irrevocably covenants that it may not seek to enforce. . .."

    It has the *exact* same meaning as the word will (under law).


    Ask company attorneys to replace the word ‘will’ with the word ‘shall’. Shall is mandatory.

    Again, using the original quote and changing one word:

    "Microsoft irrevocably covenants that it shall not seek to enforce. . .."

    That one word change now denies to the company the ability to sue (period) under the provisions of the first paragraph.


  20. Andrew Davis isn’t the only one who’s accusing Microsoft of lying in this matter. See eWeek’s Stephen J. Vaughan-Nichols "Liar, Liar, Pants on Fire: Microsoft and Open Standards" at,1895,1892080,00.asp. Vaughan-Nichols accuses Microsoft of lying about the openness of its forthcoming Office XML format license without his having seen it.

    For a detailed analysis of the standards body and related issues of Microsoft Office/OpenOffice XML document licensing, see


  21. Kirsty Jones says:


    Why do you think Microsoft suddenly changed the terms of their licensing of the XML formats? Surely someone somewhere considered how it would look to a large number of people. It looks like the situation in MA over document standards has scared Microsoft into back tracking on something they had already published.

    Given the history Microsoft has over things like this do you really find the level of negativity shown by seasoned journalists suprising or is it just something you’ve come to expect?

  22. Wesley Parish says:

    "Wesley, did you know that OpenOffice 2.0 can read and write the Office 2003 XML format (WordprocessingML)? There are tons of implementations out there that work with those formats. The new formats for ’12’ aren’t done yet, so it’s not really a su[r]prise that there aren’t many implementations out there yet."

    Yep, I know. It’s my standard office productivity suite, since I can use it on Microsoft Windows, Sun Solaris, FreeBSD and Linux, whereas I’d be having conniptions of varying degrees of facetiousness and hilarity if I tried to use MS Office on any of the last three OSes mentioned.

    What I am advising is very, very simple.

    You want people to take you seriously. You want people to use your work.

    Well, put out a draft version of your MS Office 12 XML file formats out there, completely documented – no "undocumented" stuff hiding somewhere to bite us, thank you very muchly – and get the benefit of massive amounts of feedback from your customers. In the shape of a file reader/writer/converter source code file tree published under the Microsoft Permissive or Community License (RAW ie Unlimited, not COOKED ie Limited to Microsoft) on Sourceforge.

    The confluence of the actual source code under a verifiable Free and Open Source license – compatible with the Open Source Definition and the Free Software definition – and the Patent Covenant we have been arguing over, will go a lot further towards quieting suspicion than any amount of tub-thumping will do, let alone apologetic noises whenever Microsoft’s previous (unsavoury) behaviour is mentioned.

    The ball is in your court. Whether you choose to flub it as badly as Microsoft flubbed public opinion in the anti-trust case, is entirely up to you.

  23. Jude Suszko says:

    I read this blog and I see you trying to look sincere, but then I read about how Microsoft got the "Vienna Conclusions" paper changed to remove a few things that didn’t sit well with it, such as references to "the success of open source".

    Perhaps Brian Jones is being sincere about opening the Office XML formats, but I don’t think that sincerity runs all the way back to Microsoft’s executive offices.

  24. Yuki says:

    Forget the license. The technical inferiority of MS XML is almost offensive. Why would ppl use that horrible format?

  25. Craig Ringer says:


    This is some good news. I haven’t looked at the changes in detail yet, but from your explanation it sounds like Microsoft has listened and changed things to move to a much friendlier and by the looks somewhat simpler licensing approach. This sounds like good news to me.

    Some people won’t like the retaliation option on patent suits, but I’m not one of them, as I tend to view that approach as perhaps the only sane use of patents on open formats. In fact, such a clause helps reassure everybody else that Microsoft will make it harder for a third party to make their life difficult with patent suits.

    Craig Ringer

  26. Simon Phipps says:

    Brian: The big issues here are "conformant" being undefined and thus allowing arbitrary withdrawal of rights, "conformant" also placing a restriction on use that is not in the GPL and thus preventing use in GPL licensed works, and the covenant being version specific meaning there is no promise of ongoing protection as the format evolves. As I have said in my blog[1], I think these will need fixing before people will be able to safely develop open source software with your format.

    Best wishes,



  27. BrianJones says:

    Simon: thanks for the comments. I’m actually working with some folks to get a good Q&A posted about the covenant. Hopefully that will help clear everything up, which is what we were trying to do with this whole move in the first place. 🙂


  28. S. Colcord says:

    Brian wrote:

    "I’m actually working with some folks to get a good Q&A posted about the covenant."

    Thanks, Brian. It seems like most of the questions I’ve heard pertain to suspicions about what types of control Microsoft might still be able to assert. To help put these suspicions to rest, I would propose the following questions for the Q&A:

    1) If DOCX 1.0 is accepted by ISO, and ISO later releases DOCX 2.0, are implementors of DOCX 2.0 still protected by the covenant?

    2) Is a program which only implements a subset of the DOCX standard still protected by the covenant?

    3) If Microsoft sells or transfers its patents to another entity, is that entity still bound by the covenant?

    I think that these sum up the main concerns pretty well.

  29. John M. says:


    I have been reading those post for a quite time now. I really believe that Office team is making office file formats open in the way that we will be available to create them even in the notepad. This is a good thing, but does not solve the problems we have currently with DOC or XLS files – that only the Microsoft Office in the latest version is able to open those files. It is about competition, but also, it is about the fact that MS on purpose claims that it is UNABLE to create a format that will be compatible with future versions. Also, if MS means the interoperability seriously, they would create (or made possible create) a free converter from to DOC to DOCX and vice versa.

    I am a long-time network manager of Windows networks and consider Microsoft software a good piece to work with, especially with terms of user friendliness. But those "embrace and extend" policies are really bad things, especially for the users which always are talked about in Microsoft speeches.

    I think this big talk will end as always. The documents created in Office 12 will be viewable and editable only in Office 12 and future versions. Microsoft does not want to make a format which will be compatible and interoperable. It would harm their business and monopoly power. It would be nice if they at least say it.


  30. BrianJones says:

    S. Colcord, we should be able to cover those points as well. I’ll post a link to the content once we get it posted.

    John, we are doing exactly what you ask for. We provide free updates to Office 2000, Office XP, and Office 2003 that allow those versions to read and write the new format.


  31. John M. says:

    Yes, you provide. But to use them, the user must first buy or already own (that means – has paid you before) Office 2000, XP, or 2003. User with Office 97 is out of business (good method for forcing upgrades, especially in companies where a lot of older computers still use Office 97 happily in coexistence with Office XP or 2003 on more powerful computers – they will not be able now). These updates are not free, they are free in the same way Internet Explorer is "free". You must own appropriate version of Windows and Office.

    As I said. I have been using Microsoft product for more than 12 years, since the Windows 3.11 era. But your business practices are really focused on only one thing. To keep your monopoly power and locking your users into your solutions. As long as they accept it and pay your price, everything is OK. But when they want interoperability, or move away from some of your products, they are forced not to do it.

    One more question. With those new formats, will any other company be able to make for example word processor, which could be used to collaborate with another user using MS Word 12, working on the same document? This is what I need very often, when working with my colleagues. And I do not want to force them to buy the same version of Word that I have. Do you have any solution for this?


  32. John M. says:

    And one more thing. I will believe in your posts and approach, when one day on the net will be available open source converter (not necessarily programmed by Microsoft), which will be able to do ODT – DOCX and DOCX – ODT conversion without losing formatting, with the outputs that can be open in both OpenOffice and Office 12. Only then I will believe, that you have opened the formats really.

    And moreover, that some company will be able to create a wordprocessor as I described in previous post – which means that it can edit DOCX format the same way as MS Word will do. Please, don’t say that this is not possible for "technical reasons". If it is so, then you have designed DOCX very, very wrong.

  33. John M. says:

    And last but not least – the business lesson. Currently, I have on half of my machines at my network OpenOffice, quarter Office XP, quarter Office 2000. The users with OpenOffice cannot communicate with those in MS Office,unless htey are using the DOC format which is contained in Openoffice, this implementation is fairly good but suffers from the closed characteristics of this format.

    If Office 12 provides DOCX format in such a way that others (for example openoffice developers) will be able using it as one of its formats without losing information (and this is NOT the case for the Office 2003 XML format, which you are constantly talking here as a first step into XML), it would be big reason for me to upgrade those machines with MS Office to Office 12. Because it would be interoperable with those using OpenOffice – if the authors of it were able to "decode" your hidden DOC in such a way it is working, they will surely be able to implement a specification of DOCX you publish.

    If this will not be possible, then the new format is of no value for my network and I will try to move to OpenOffice on all computers possible, even if I would like to give some of my users new possibilities of Ribbon, Functions, and other great things in new Office 12.

    Please, recognize competition by features and value delivery, and on the other hand by locking the users in your solutions. You are doing the second thing more than often.

  34. Simon Jones says:

    John M says that he’s looking for DOCX <-> ODT conversion without loosing any formatting. This isn’t possible unless Sun/OpenOffice and Microsoft cooperate and make both products have the same feature set. There are lots of features where the two applications/suites work differently and files can’t be converted without loss of information.

    As an example, take Hidden Text. In Word, hidden text is a character attribute. You can hide one or more characters in a paragraph by marking them as hidden text. (Useful for notes about what you have to write/edit etc in that para.) In OpenOffice, hidden text is a paragraph attribute. You can only mark whole paragraphs as hidden, not individual characters. Converting a document with hidden text from ODT to DOC or DOCX is fine but go the other way and either you have to hide a whole paragraph because one character is hidden or you have to unhide the hidden characters. Either way the document will look different.


  35. I still get folks asking me questions about the licensing of the Open XML formats from time to time,…