다음을 통해 공유


More answers to questions around standardization and licensing

I think this is the longest I've gone between posts since I started blogging back in June. I've been out here in Europe for the past two weeks, for a combination of work and a little time off. I was in Nice last week for the Ecma general assembly meeting where they agreed to create TC45 which will standardize the Office Open XML formats. My wife came out here with me so after the meeting we took some time off, and I've been offline for about 5 days now. We just got into Brussels last night, and now I'm paying for the time off with all the e-mail, news, etc. that I need to catch up on. Sorry for not posting anything last week or early this week, but I hope you all understand. :-)

After we made the announcement about submitting our file formats to Ecma international and shifting our licensing strategy, there were a lot of people that sent me a collection of great questions. The licensing shift was especially confusing for some folks since the copy of the covenant wasn't actually posted online for about a half day or so after the announcement. Additionally, the covenant references the Office 2003 schemas and people were wondering why they didn't mention the upcoming Office 12 schemas. There were also a number of other people speculating and looking to find a negative side to things, but overall I'm sure most of you saw it as a huge positive win for the industry. I've been really happy with the number of e-mails and comments I've received. Many of the comments have been from folks who are already developing on top of the XML support in Office 2003, but I was also excited to see a large number of people who are new to the Office XML arena. I'm really looking forward to talking with you guys about all the features and functionality and hearing from you about what you've done or are planning to do. Together we can continue to grow this ecosystem that already has over 300,000 developers. :-)

A few days ago, we posted an FAQ that helps to sort our some of the questions people had around our reasons for going to Ecma International as well as our new licensing approach. The Q&A answers the following questions:

  1. Why has Microsoft taken existing document formats and moved to standardize them with industry partners, rather than develop something new in a more collaborative process?
  2. Why is Microsoft standardizing the formats for the next version of Microsoft Office?
  3. Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?
  4. How open or closed will the Ecma International process be for the OpenXML formats?
  5. Why did Microsoft take this new approach to licensing?
  6. Does the CNS only apply to the Office 2003 specifications as it is shown on the Web site, or will it also apply to the upcoming release of the specifications for Ecma and for Office "12?"
  7. Where is the new license posted?

You can view the latest version here: https://www.microsoft.com/office/preview/developers/ecmafaq.mspx but I also wanted to include the content here on my blog:

Understanding the OpenXML Formats and Ecma International Process

Q. Why has Microsoft taken existing document formats and moved to standardize them with industry partners, rather than develop something new in a more collaborative process?

Organizations all over the world have asked Microsoft to insure that their valuable investments in billions of documents are protected and are made even more valuable by enabling conversion to modern open XML-based formats.

By taking this approach to standardization with industry participation and support in Ecma International, organizations around the world will have the immediate benefit of both backward compatibility for existing documents and the long term benefit of a forward-looking open industry consensus process.

Q. Why is Microsoft standardizing the formats for the next version of Microsoft Office?

Microsoft chose to provide the most current version of the formats for standardization in order to provide the most value to the industry.

Microsoft chose to make available the document formats for Office "12" to insure that the foundation for the OpenXML document formats is considered to be complete. The standardization process requires months of input and documentation, so Microsoft chose to look forward to align our document formats standardization with the latest shipping product functionality.

Q. Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?

The OpenDocument format would not meet requirements for backward compatibility, for forward compatibility, or for performance, that millions of Microsoft customers tell us that they require.

Sun submitted the OpenOffice formats to a small committee in the OASIS organization. The record shows that there were almost no material changes to the OpenOffice specification from the time it was submitted to the time it was approved by the working group at OASIS. Sun timed the release of the OpenDocument standard in conjunction with the OpenOffice 2.0 release. The OASIS committee did not focus on the requirements, constraints, and experiences of Microsoft customers.

The Microsoft OpenXML formats have had a number of unique design requirements, including the following:

  • Backward compatibility with billions of documents produced over decades.
  • Intrinsic support for integrating customer-defined XML data. This enables new levels of innovation as documents generate and transport information in unique XML styles not defined by Microsoft or the document standard, but defined by the business processes of an organization.
  • High performance. The Microsoft OpenXML formats put a high priority on the speed of opening, closing, and working with documents, to roughly reflect or improve upon the performance of the past binary formats, rather than degrade the performance due to parsing XML.
  • Robust Testing. The OpenXML formats for Microsoft Word and Excel have been part of Office 2003 and have undergone extensive real-world testing and usage, by customers and developers.

In conclusion, the formats are significantly different, with different design points and strengths.

Q. How open or closed will the Ecma International process be for the OpenXML formats?

The Ecma process is completely open under the organization's rules and procedures.

Ecma International in a well-recognized standards organization with a track record of producing high-quality standards for the industry for over 40 years. The OpenXML effort will have a startup process that is similar to many other standards efforts in that it will begin with specific baseline requirements to set a well-understood and supported foundation. Virtually all standards committees are subject to a delineated scope or set of parameters for their work. The Ecma organization will focus on fully documenting the formats to enable further standards work, to insure cross-platform and multiple tool support and to meet widespread industry requirements and utility. Then it will go still beyond this startup mode under the stewardship of Ecma member organizations working on the technical committee. We expect competitors, partners, and customers to embrace the OpenXML formats as a result.

The 'Covenant Not to Sue' (CNS) Approach for the License

Q. Why did Microsoft take this approach?

It was a simple, clear way to reassure a broad audience of developers and customers, within a rapidly changing licensing environment, that the formats could be used without constraint forever.

We looked at many different types of licensing approaches that would recognize the legitimacy of intellectual property but would make it clear that the intellectual property in the OpenXML document formats would be available freely, now and forever. Given that this is a rapidly changing area and lay people sometimes have difficulty understanding terms, we wanted to create something simple and clear. We looked at Sun's recent approach with the ODF format and the positive feedback about the approach. With minor changes to this for clarification, we felt that it was a simple, clear approach that would reassure customers, governments, and developers that there would never be a barrier to working with the formats.

At least one leading OSS legal advocate has made positive public comments regarding the acceptability of this approach. However, please look into this yourself. We hope that this approach will continue to get close scrutiny and will gain positive long term confidence across the industry as a way to insure that document formats are usable by all types of developers with different intellectual property licensing philosophies.

Here are a few more specific and detailed questions and answers about Microsoft's 'Covenant Not to Sue' approach:

  • There is no longer really a license that people need to sign up for in any way — No one needs to sign anything or even reference anything. Anyone is free to use the formats as they wish and do not need to make any mention or reference to Microsoft. Anyone can use or implement these formats to both read and write the formats with their technology, code, solution, etc.
  • Patents — We eliminated the license to patents language and are instead providing an irrevocable commitment to not sue anyone based on the patents we have in the formats. If any parties prefer, we will make available the existing open and royalty free license as an alternative.
  • Why does Microsoft have patents in this case at all?  — We pursue patents early in our development process (as required by law) to protect our innovations 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. In this case we are deciding not to enforce our patents in connection with these formats.
  • Transferability of solutions and "GPL Compatibility"  — If someone wants to build a solution that works with our formats, they are free to do so without worrying about patents or licenses associated with our formats. The concerns raised with our previous license about attribution and sub-licensing are now eliminated. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but we believe we have removed the principal objections that people found with our prior license in a very simple and clear way.
  • Subsets, supersets, and 'conformance'  — Anyone is free to work with a subset of the specifications, and anyone is free to create extensions to the specifications. A 'conformant' use is simply one that does not modify the specification. Of course subsets and supersets may create incompatibilities with other uses of the specifications and we want to provide some guidance on this topic in the future, but this will be guidance and not a mandate. The key is that this is an assurance that no one will be sued for using intellectual property in the specifications as they are written.

Q. Does the CNS only apply to the Office 2003 specifications as it is shown on the Web site, or will it also apply to the upcoming release of the specifications for Ecma and for Office "12?"

The CNS currently applies to the Office 2003 specifications because they are the only ones currently available that are complete. As the up-to-date specifications are released to Ecma, they will be posted on the same Web site and we will apply the CNS to them.

Q. Where is the new license posted?

It is posted on the Microsoft Covenant Regarding Office 2003 XML Reference Schemas Web page. We will post the license elsewhere as needed to ease awareness and distribution of the specifications, and to maintain long term neutral stewardship and applicability of the Covenant.

I hope this helps sort a lot of this stuff out for those of you who were still concerned about this stuff. Most of you by now are just wanting to know more of the technical details so I'll get that out there as well. For those of you who were still concerned about this topic though, I really do hope this helps. I know there is a lot of speculation going on out there and unfortunately there have been a number of folks who've misinterpreted stuff a bit and posted their opinions. Hopefully this will help clear a lot of that up. I'm sure there will be more questions though, so please let me know and I'll see if we can get answers posted to those questions as well.

-Brian

Comments

  • Anonymous
    December 14, 2005
    This seems like great PR (the Q&A) but not necessarily a great foundation for a business to rely on. I openly applaud Microsoft's move towards openness but if this was a competitive move i don't think it will really work. This standard is being fast tracked to move through an openly permissive standards body, then hopefully to the ISO.

    Step back for a second and think about if you were a CIO, why would you move your business to this standard. If you could move to another that is being maintained in a transparent way by a large group with an interest in long term storage and development, with multiple implementers and allot more support. (if you had a choice) And the guarantee that this format won't change upon one companies needs.

    It is great that office 12 will have more open formats, but the fact that it is moving through a permissive standards organization and can change the deal at any point, which also would change the covenant when ever Microsoft is ready to iterate sends a lot of bad signals to me.

  • Anonymous
    December 14, 2005
    The comment has been removed
  • Anonymous
    December 14, 2005
    Thanks for getting these answers out there, Brian.

    According to Andy Updegrove the characterization of the OASIS ODF process is almost entirely false. See the end of this post:
    http://www.consortiuminfo.org/newsblog/blog.php?ID=1825

    Also, the specific objections to ODF don't seem to make much sense. Why can't backward compatibility be achieved with extensions to ODF? I don't know what "Intrinsic support for integrating customer-defined XML data" means other than extensions to the schema and any XML schema can be extended. ODF is also well-tested and is actually used in a shipping product. If Office XML really parses faster than ODF then I guess that's nice but is it worth splintering formats over? Why not propose performance improvements to ODF through the standards process?

  • Anonymous
    December 14, 2005
    The comment has been removed
  • Anonymous
    December 14, 2005
    "If someone wants to build a solution that works with our formats, they are free to do so without worrying about patents or licenses associated with our formats."

    Well that's true if their only worry is being sued. What if they're worried about producing a legal product. You say you won't sue the developers, but that doesn't mean they didn't do something illegal.
  • Anonymous
    December 14, 2005
    "The key is that this is an assurance that no one will be sued for using intellectual property in the specifications as they are written."

    Hence no assurance for those not having adhered to the specifications as decided by a judge in a court at a time of your choosing?
  • Anonymous
    December 14, 2005
    >Well that's true if their only worry is being >sued. What if they're worried about producing a >legal product.
    i agree with that ...
    the "Office 2003 XML Reference Schema Patent License" ( http://www.microsoft.com/mscorp/ip/format/xmlpatentlicense.asp ) reads:
    "...You are not licensed to sublicense or transfer your rights."
    so, a developer who distribute his MSXML reader/writer using the GPL license is doing something ILEGAL ( i dont like that ... Covenant not to sue or not CNS )
  • Anonymous
    December 14, 2005
    Hi Brian,

    As it is not clear from the Q&A, when will the next version of the file format schema and documentation be available for public review? Will draft versions be made public as part of the ECMA process, or from Microsoft directly?

    Thanks,
    Chris
  • Anonymous
    December 15, 2005
    Hi Brian,

    Unfortunately, this FAQ does not address any of the questions I previously raised (<http://blogs.msdn.com/brian_jones/archive/2005/11/22/495876.aspx#499028>).

    In general, the FAQ seems to be attempting to explain Microsoft's motivations; most of the questions begin with "Why...". I suspect that relatively few people are interested in such explanations, since they have no legal significance.

    The questions I linked above pertained to specific legal ramifications of the covenant that would impact non-Microsoft developers. Other lawyers have ventured opinions on these issues, but an official opinion from Microsoft on the matter would be far more meaningful.
  • Anonymous
    December 16, 2005
    S. Colcord,

    The Q&A does address your subset question... it says subsets and supersets are okay to use...
  • Anonymous
    December 18, 2005
    Matt:

    On a reread, I'll agree with you; I missed it because it was under a subsection of "Why did Microsoft take this approach?", rather than a Question in its own right. There is still a bit more legal wiggle-room than some might prefer in the definition of "Conformant" (There needs to be an easy way for a developer to tell whether they have a Conformant subset or an incompatible alteration; the former appears to be covered, the latter not), but the intent seems reasonably clear.

    I'd still like to see FAQs covering what happens if ISO updates the spec (with or without Microsoft involvement), and what happens if Microsoft transfers its patents to another entity, one without such a Covenant.
  • Anonymous
    December 19, 2005
    Thanks to Bob Sutor's blog, I just found the official ECMA announcement and the submitted drafts: http://www.ecma-international.org/activities/Office%20Open%20XML%20Formats/">http://www.ecma-international.org/activities/Office%20Open%20XML%20Formats/ (This is also linked from the bottom of http://www.ecma-international.org/activities/)

    You've been very busy, with more to go. It is valuable to have materials available so early. It is a little daunting to see that you are already at 2000 pages with the expectation of triple that by the time it is suitable for use as the specification of a standard.

    Are you going to create a forum for technical comment so that those of us who read through the documents with beginners' eyes can submit anything odd that we notice?
  • Anonymous
    December 19, 2005
    I see, above, that I derailed your blog's URL-recognizer. With no preview, who knew?

    While I'm passing by, I thought I'd point out that I stumble every time I see "OpenXML" used the way it appears on the FAQ about the ECMA submission and the intention of the covenant not to sue. Although it is simple and valuable for that, I think using the term when only discussing the Office Open XML format reaches too far and will be more of a lightning rod than useful.
  • Anonymous
    December 19, 2005

    The ECMA TC45 specs blows the O12 schema preview doc out of the water. I don't understand how Microsoft even considered the fact they would post something as useless as the O12 schema preview. In fact, I think the ECMA TC45 specs IS the doc spec, period.

    Thumb up to Massachusetts, they've got MS to publish the specs.

  • Anonymous
    December 19, 2005
    Chris - I just posted about the documentation here: http://blogs.msdn.com/brian_jones/archive/2005/12/19/505675.aspx
    We'll continue to update the documentation directly through the Ecma work.

    S. Colard, the "conformant" piece is just saying that if you do something outside of the spec, then it can't be covered because it isn't something Microsoft has defined, it's something you've defined. The pieces within the spec are covered of course, but anything outside is something that we don't have control over. How could we?

    Orcmid - Thank you on the congratulations :-) We still have a lot of work ahead of us, but it's really exciting stuff.
    I know the 2000 pages a bit overwhelming, but you have to realize that the document covers all three application formats, which have been evolving over the past 20 years (so you can expect there to be a lot of information). The initial 200 pages are the glue though that brings all the reference material together and should help make it much easier to follow.

    Stephane, I'm glad you like it :-) I know that the previews were really rough, but we wanted to get some information out there early, even if it wasn't in the best state. The Ecma spec will continue to get much more clear over the coming months as we work on it in TC45. I'm really excited about the quality of document we're going to have for everyone.

    -Brian
  • Anonymous
    December 20, 2005
    Brian Jones wrote:
    "the "conformant" piece is just saying that if you do something outside of the spec, then it can't be covered because it isn't something Microsoft has defined, it's something you've defined. The pieces within the spec are covered of course [...]"

    Hi Brian,

    If that's true, this concern is moot. The following example would serve as a good illustration:

    A developer ("Bob") implements an office suite, and decides to use OpenXML for the data storage, but tweaks it to suit his particular needs, calling the resulting format BobsOpenXML. By what you stated above, Bob's changes can't be covered, because they aren't something Microsoft has defined, but the pieces of BobsOpenXML that came from the OpenXML spec are covered by the Covenant. Correct?

  • Anonymous
    February 13, 2006
    PingBack from http://blog.jensthebrain.de/archives/2006/02/13/office-12-word/
  • Anonymous
    April 17, 2006
    PingBack from http://luispo.wordpress.com/2006/04/17/3/
  • Anonymous
    June 18, 2009
    PingBack from http://thestoragebench.info/story.php?id=5658