Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
Open is Different than Stolen: The Importance of Social Trust in Honoring IP
 
What Was Y2K All About?
 
Wells Fargo Click-Through Thuggery
 
Stupid Is as Stupid Does: Me and NewsGator
 
brrreeeport
 
.Naked Monoculture Bites MSDN
 
What Computers Know
 
Launching Naked Conversations
 
Confirmable Experience: Outstanding Microsoft Customer Service
 
Ariane 501: A "History's Worst Software Bug" Provides the Wrong Lesson

The Heavy Lifting toward Open Formats in Microsoft Office

Channel 9 – Jean Paoli and Brian Jones: More on Office Open File Formats.  There’s another Channel 9 video on the Microsoft Office Open XML formats.  This time Robert Scoble interviews Jean Paoli and Brian Jones together about the 2-year effort to expand the Office 2003 use of XML to a level of open, full-fidelity XML formats that will be the default formats. 

My attention was drawn to two things:  First, the Microsoft team has a vision of the power that open formats for electronic documents provide as a social good.  Secondly, there is a desire to see the format usable in an unlimited variety of applications, including ones delivered as open-source software.

The open-source case has not been spelled out. I have investigated ways to use the formats and the royalty-free license with open-source software, and I add my preliminary observations here as part of my continuing analysis of the opportunity that I see.

You can view the 24–minute video on the channel 9 page, download it (76.4 MB .wmv file), or stream it to a media player (MMS protocol).

The Vision

+02:55 Scoble asks Jean Paoli what has him be so passionate about XML and what using XML means for the world.  You’ll have to listen to the video to capture Paoli’s accent and enthusiasm (+03:20):

“Since a long time we always dreamed—in the XML community a long time ago, 20 years ago, and when I came to Microsoft [9 years ago] we start to XML and all this was—to basically open up those formats and you know it’s very important because the implications, I believe, are not only technical, they are really at the society level, because then you can access books, you can access writings, you can access poems, all of these things in an open manner, and you can reuse it … It’s a very fundamental change.

“What’s making me very happy is that when we started with Office 2003, it was really the very first kind of XML for the masses.  But now what we are doing is—you know we have 400 million users … and I believe they have billions of documents, we don’t know the numbers—and we are organizing, basically, a massive transfer of these documents to be open in XML format.”

How Can Open-Source Developers Participate?

The Microsoft Office XML Reference Schemas license (the one proposed for the new formats too) does not permit derivative works.  Also, the royalty-free patent license applies only for the portions of programs that read and write files that conform precisely to those schemas.  The reliance on the license must be acknowledged in the software.

That's not the end of the world, but it is perhaps why the wording of the FAQ/Q&A response is a little, uh, indirect when it says 

Q. Can the license from the Office 2003 XML Reference Schemas be used by open source developers?

A. Yes.  Open source developers who wish to participate in a community development project can enter into the agreements and then work in a collaborative fashion on development of a program or programs.

Q. Can I distribute a program that can read and/or write files that support the Office 2003 XML Reference Schemas in source code form?

A. Yes.  You can distribute your program in source code form.  But, note that the patent and copyright provisions in the license for the Office 2003 XML Reference Schemas require you to include a notice of attribution in your program. [Actually, unless you include the schemas themselves, it is only the royalty-free patent license required notice that must be included in code, although the license and their notices effectively refer to each other.  See below. -dh:]

Q. Can I distribute a licensed program under an open source software license?

A. Yes.  There are many open source licenses available in the developer community.  One useful place to review the various licenses that have been approved by the open source community is at Open Source Initiative [OSI].

The terms and conditions of these licenses differ in material respects.  We believe you can distribute your program under many open source software licenses so long as you include the notices described in the licenses for the Office 2003 XML Reference Schemas.  … [followed with good advice about making sure that you wouldn’t be violating conditions of the open-source license and obtaining legal counsel.]

The Schemas are not Open-Source Compatible

Basically, you can not envelop the schemas themselves in an Open-Source Definition compatible license because that would violate the Microsoft license.  You can (and must, I say) segregate the Microsoft material in a way where there is no license confusion, sort of like treating them as redistributables that can only be redistributed under their own licenses but are employed in works that have broader (that is, OSD-compliant) licenses for the added-value parts.

That's not a unique situation. I go into this more elaborately in my analysis of the Copyright part of these licenses in an earlier blog entry.

This is not the only time that commingling is to be avoided.  This should be done even when same-license materials having different authors (that is, copyright holders) are packaged together in some way.  You need to know who the several copyright holders are in case there is a question or desire to negotiate a special license, and if there is a dispute about the authenticity of the material.  As a general practice, I think attribution and clear demarcation of the material should be practiced at all times.

Licensed Software Should Not Be Commingled with Other Open-Source Code

There is an additional requirement because the royalty-free patent license applies not to the Microsoft schemas and specifications, but to software that you or others write.  Pieces of open-sourced code that accomplish reading and writing of the formats in conformance with the schema (isolated in an object of some kind, let us hope), must provide attribution and notice of reliance on the royalty-free license. 

I believe it is important to segregate that code too, because anyone who modifies it must either preserve the license-required conditions or remove the license statement and not use the code to access the Microsoft format. 

I prefer these arrangements because I would not want anyone who used an open-source offering of mine to find themselves in infringement because the license conditions were not preserved in their derivative work.  Also, segregation helps be clear how much of the software is thought to be under cover of the license.

I have a summary of the conditions in a follow-up on my blog.  Notice that exactly the same thing must be done in using the OASIS OpenDocument formats and schemas.  Although Sun Microsystems does not require an acknowledgment of the license, I would make sure to put something in about that to protect downstream developers in the same way, and I would segregate in the same way.

Preserving Licenses Must Be A Clear Condition on Derivative Works

Finally, in providing the notice that Microsoft requires, I would include additional information from the royalty-free patent license to communicate to anyone who inspects the source code exactly what conditions they must accept and honor in order for them to have licensed software.  I would also be careful not to stealth the licensed code at them.

With luck, we're talking about software units that someone would either use intact (apart from fixes and interface adjustments) or would replace completely in making a derivative work of the open-source portions.

I would not risk a dangerous misunderstanding by supposing that code covered by these royalty-free conditional licenses can be enveloped—embraced and extended—under any Open Source Definition compatible licenses, including the GPL, that permit derivative works.  Somehow, preservation of Microsoft’s (or Sun’s or IBM’s) license is a constraint, and that constraint must be preserved in some appropriate way with whatever open-source packaging and licensing that is used. 

Having said that, I am not that clear how I would do it and also explain it to a lawyer that I was asking for review of what I wanted to accomplish. My personal inclination is to adopt a BSD-like license template that allows for enumeration of any patent-license constraints, interoperability conditions, attribution requirements, and non-confusion clauses that may be important to establish.  I wonder how the OSI will find a way to simplify the variety of OSI-recognized licenses while honoring the importance of optional constraints such as these.

Microsoft OX vs. OASIS OD: Is It Really Open Format vs. Open Standard?

Orcmid's Lair: Office XML's IP-Infringement Specter, I: Copyright (long).  Updated Information: The table, below, has been updated in Analysis 0.75, Toward Open-Format Adoption.  The 2005-12-06 blog post, Lining Up Formats for Office Documents, summarizes the later analysis.

While I mull over the problems that software patents pose for software developers and the specter that is aroused for some of us literal-minded geeks, I notice that there are some odd statements around the ease with which Microsoft is supposed to adopt the OASIS OfficeDocument specification as an obvious pathway from its current binary formats to an open-standard XML solution.  So I’ve prepared a little addendum to my previous missive on the subject.

3.5 Open Formats vs. Open Standards?

There is some chatter about Microsoft's Open Format not being truly open, and that true openness means no encumbering patents.  Rather than argue the point, I think a reality check is called for.  Here's what I have found by applying a modest level of diligence:

	OASIS OpenDocument	Microsoft Office XML Open Format
Type of specification	electronic-document format (700 pages, June 2005)	electronic-document format (spec. not yet available; skimpy documentation of predecessor formats)
progenitors	OpenOffice.org (OOo)XML	Microsoft Office 97-2003
derivative work of specification	allowed solely for discussion and explanation	excluded
schema methodology	Relax-NG schema definition (504k)	XSD: XML Schema Definition (assuming continuity with current Microsoft Office XML Reference Schemas)
schema variations	one relaxed [;<), one strict, plus package specification	one set per document type (Word, Excel, PowerPoint each with and without macros), with shared generic pieces in a (common?) package specification (assuming continuity with current Microsoft Office XML Reference Schemas)
licensing of schemas	none stated (Sun Microsystems and OASIS Open copyright notices)	same notice as on documentation
royalty-free patent licensing	Sun Microsystems "essential claims" royalty-free license	Microsoft "necessary claims" royalty-free license
patent-license scope limitation	only where unavoidable in order to implement the specification, and only to implement the specification	only those portions of a software product that read and write files that are fully compliant with the specification of the schemas
patent reciprocity required	yes	no (although suing Microsoft or affiliates for infringement of a related patent claim will terminate the license)
patent-license notice required	no	yes
specified compatibility	some (forks OpenOffice.org format)	round-trip fidelity with Microsoft Office binary-format documents, Office 2000-2003 and Office 12; degree of down-level convertibility is unclear.

The Microsoft Office XML Reference Schemas license establishes open formats.  That is what was promised, and that much is delivered without question.  One of the new openings that Microsoft celebrates is making it easy to repurpose documents in those formats.  Likewise, one may produce documents in those formats as a repurposing of other material.

Although I think there is a speculative case for allowing derivative works of the OX formats, I want to make it clear that Microsoft has provided what it promised: an open format.  It's a proprietary open format the way TIFF, PDF, and GIF are.  It's more open (or less proprietary, take your pick) than MP3 is.  It is determined by a single specifier, the same as FORTRAN, C Language, and Java (and a lot more) were.

It's the schemas that can't be "repurposed."  That's what I am picking at when I claim there's a derivative-use bind.  That may turn out to be unimportant.  We need to find out.

Is this the difference between (merely!) an open format and an open standard?  Or is there no material difference?  In some sense, the OX format schema is like the specification of a programming language.  The idea is to program in it (use the format), not make new programming languages.  Of course, people do make new programming languages based on the specifications of older ones, as witnessed by the survival of C Language in C++, Java and C#.  It would seem that that is frowned upon for the Microsoft Office XML Open Formats and for the OASIS OpenDocument format.

The term "standard" is being bent a little in comparing the Microsoft Office Formats and the OpenDocument format.  If there is any "standard" office document format, it is the one already implemented and preserved by the progression of Microsoft Office implementations since Office 97.  It is the format that other products, including Microsoft Office 12, must deal with in order to be widely acceptable in the office-productivity marketplace.  It doesn't get more "standard" than that.  Specifications become standard through their adoption in practice, not their publication.

That OASIS declares a 706-page unimplemented specification as being an "OASIS Standard" is fairly amazing.  It will take substantial effort to reality-check that specification, and it will be a little while before anyone confirms multiple, interoperable implementations.  The test suites that will be required will be impressive, I'm sure.  I am also a little surprised that the schema is being defined using a Relax-NG OASIS Committee specification that has been around since December 2001 and hasn't made it to even OASIS Standard.  There is, however, ISO/IEC 19757-2:2003 which was issued in November, 2003, and one must trust that to be substantially the same (or use the PDF document here).

It seems to me that OpenDocument must be demonstrated to accommodate the Microsoft Office format, not the reverse.  Can OpenDocument accurately represent documents created in Microsoft Office, preserving all of the features of those documents?  Can faithful conversion be done mechanically?   That's the legacy challenge that must be dealt with.  It doesn't strike me that the burden of proof is Microsoft's.

Office XML's IP-Infringement Specter, I: Copyright (long)

Professor von Clueless in the Blunder Dome: Microsoft Cracks Open the Word, Excel, and PowerPoint Formats in XML.  I’m excited about the June 2 announcement of the Office XML Open Format to become the default Microsoft Office document format.  It is particularly pleasing that support for the format will be retrofitted to Offices 2000, XP, and 2003. 

I’m also concerned that the Office 2003 XML Reference Schemas license may not cover use cases that are important to me and, I think, that may be even more important to Microsoft.  In this lengthy entry, I unwind as much as I can figure out about how the copyright elements of the license can be made to work and where the restrictions of the license seem to pinch too much. 

I end with the observation that it’s great that Microsoft is opening up its approach so far ahead of the next Microsoft Office release.  There is a sizable window where everyone’s concerns can be addressed before the formats and their license are locked down.

• 1. Introduction: The Specter Thing
• 2. The Proposed Benefits of OX and the License
• 3. The Copyright-Leftness of the License
• 3.1 The Copyright Portion of the License
• 3.2 My Practices: A Specific Comparison
• 3.3 The Copyright-Mixing Bind
• 3.4 The Derivative-Use Bind
• [the Patent-License Cases will be explored separately]
• A. Source Materials
• A.1 Available Material and License
• A.2 Proprietary Notices
• A.3 Other Resources

1. Introduction: The Specter Thing

I’m fascinated by the opportunity for other applications and services to interwork with the “OX” formats (my term for the new DOCX, XLSX, and PPTX).  The same license also covers the current but non-OX XML formats usable with Excel, InfoPath, OneNote, Project, Research Services (from Office applications to research resources, including Encarta), Visio, and Word (i.e., WordML).  The OX formats are judged by their developers to be good enough and rich enough to become the default formats in place of the current DocFiles of key Microsoft Office applications Word, Excel, and PowerPoint.  Some of the other XML formats in Office are for specialized usage (e.g., imports into OneNote).

What’s this specter thing?  I find myself having a weird emotional reaction (“feeling dirtied” off-and-on) over the license, and it appears to be because its language raises the specter of infringement.  By that I mean that I am now wary of the prospect of committing an infringing act.  That’s despite the license’s excusing of actions that could be infringing acts in the absence of the license.  That’s what I mean about the IP-Infringement Specter. 

The prospect of unintended (or IP-ignorant) infringement is the same as it always has been.  Yet the fact that Microsoft provides a royalty-free, conditional and limited license that points out the prospect in its terms actually raises my anxiety level.  My gut reaction is to keep my distance and not embark on something that would have me be tainted by the license strictures.  (This aversion led me finally to destroy the CD that comes with the Shared Source CLI Essentials book, once I realized I could be tainted by examining its contents.)  I have no idea how I end up in that mood, but I will bet small sums that I am not the only one who reacts in this way, and some will accompany that with speculations of dastardly Microsoft conduct and perpetuation of property-centered evils.

Because I think OX is a big deal, and I would love to find out that it is safe to play with the formats and the opportunities they represent for novel application, extensions, and variants, I want to slay this demon of mine.

I propose to take the license apart, piece by piece and satisfy myself that I can work with it.  This post deals with the copyright license.  The patent license is thornier for me, and I'll address that in a later post.

2. The Proposed Benefits of OX and the License

Microsoft Senior Vice President Stefen Sinofsky identifies the intended benefits in his Microsoft PressPass Q&A:

“We have used [XML] as the foundation for the new Office XML Open Format, which is an open, published document format.  In addition, we are publishing with it a royalty-free license, so any customer or technology provider can use the file format in its own systems without financial consideration to Microsoft.  This will ensure that the new file format can be used by everyone to create, access, and modify documents in this format.”

I have no idea what there is about a document format that requires a license, and that’s all right.  There’s not much harm in Microsoft being over-generous and providing a royalty-free license to something that maybe can’t be owned.  I as licensee then don’t have to worry about whether or not there is a property right and which bits of the whole happen to be that property.  I am very fond of licenses that allow me to remain unworried and have very simple compliance conditions.

Microsoft presents the offer as an important one, so it is useful to find out what it provides for.  I’m aligned with the stated outcome: ensuring the ability to use the format(s) to create, access, and modify documents.  I am learning, however, that “in this format” is actually limiting in unexpected ways.

My natural inclination is to discover the actual terms of the license, its limitations, and any conditions that must be satisfied.  So I have gone looking.  Here’s what I make of it.  You can check the original sources, review my rationale, and apply your own yardstick.

3. The Copyright-Leftness of the License

When I think about licenses having to do with software, my first thought is about copyright and the range of licenses that interest the developer community.  I include the range of Creative Commons licenses as well as those that satisfy the Open Source Definition (1.9).

3.1 The Copyright Portion of the License

Microsoft reserves all copyright in the specifications of the Office XML formats and of the XML Schema Definitions for those formats.

Along with Microsoft’s copyright notice, there is the grant of a perpetual, non-exclusive, limited copyright license that begins:

Permission to copy, display and distribute the contents of this document (the “Specification”), in any medium for any purpose without fee or royalty is hereby granted, provided that you include the following notice on ALL copies of the Specification, or portions thereof, that you make.

The specified notice is exactly the same as the one that Microsoft uses in its own copies, linking to the same license document.  The required-notice exhibit is followed by this additional stipulation, making it clear what is not being granted:too:

No right to create modifications or derivatives of this Specification is granted herein.

The simplest well-known license with comparable limitations (based on copyright alone) is the Creative Commons Attribution-No Derivatives license.

I have no problem with honoring these conditions exactly.  Well, the specter comes up and I have to keep reminding myself that it is an illusion.  As I work through some of these cases, I notice that  the specter is fading.

There are some difficulties when I want to use the material in ways that I think Microsoft wants to encourage and where literal preservation doesn’t work.  For those cases, a statement akin to the Creative Commons Attribution-Share Alike license would have me be more confident that I don’t need to negotiate a specific license for each such occasion.  In a situation where someone isn’t willing to share derivatives, they are no worse off with a share-alike license than with the Microsoft no-derivatives version.  Also, as the owner of the copyright, a share-alike provision does not constrain Microsoft’s use of its own material in any way whatsoever.  And if Microsoft isn’t willing to accept the share-alike offerings of others, they are no worse off than anyone else in that situation.  (For that matter, Microsoft is in a far better position to negotiate alternative licenses than are many smaller operations.  If there's a non-specter downside to this for Microsoft, I'm not the one who can say what it is.)

3.2 My Practices: A Specific Comparison

I want to illustrate the practices that are required where these Microsoft-licensed materials are distributed as part of collective/composite works covered by different over-all licenses.  I'm drawing on my own practices:

• For the literary aspect of digital materials, I prefer to offer the Creative Commons Attribution license.  An example of how I do that is at the bottom of each page here, and the specific practices and their motivation is described in an InfoNote here. 
    
• For software, I prefer to apply the open-source BSD License.  An example of such application is here.  One motivation for this license has to do with honoring community contributions that preserve the ability of that generous community to make proprietary use of their own work and its upgrades (as in the case of ODMA). I also want to make it easy for people to act in ways that do not raise the specter of copyright infringement.  There is more about that in an incomplete license drafting here.

I want people to be able to make use of my works and, by applying very simple practices, to be unconcerned whether or not their use constitutes creation of a derivative work.

I am not lobbying for the adoption of this approach by others.  These choices are merely single instance of the wide range of exclusive rights that copyright holders can exercise as they see fit.  I bring up my approach here because it provides a grounded, worked set of comparative examples that I am completely familiar with.

3.3 The Copyright-Mixing Bind

When materials having different licenses are commingled in an electronic packaging, it is easy for a recipient to overlook the additional restrictions that may accompany some of the items.  There is a fair amount of carelessness about that in open-source packages (and some commercial ones) that I have encountered.  I don't want any recipient of my work to be led astray by how I package materials together.  I apply two complimentary practices for making differences in licensing of companion materials very clear:

1. Materials with different licenses and conditions that must be noticed can be isolated in a way that makes the existence and applicability of the separate conditions clear and unambiguous.  One way is to use an embedded container (such as a Zip archive) that contains a separate, well-identified license statement along with links to more-detailed information.  I would do this, for example, if I wanted to distribute a selection of the Office XML Reference Schemas that are used in some package of mine that allows derivative works.  I would also make sure that the manifest and license statements for the overall package emphasized and identified the portions that carried different licenses, especially more-restrictive ones.
     
2. Substantial restrictions can be made known and offered for review without requiring the related content to be accessed in any way without first knowing the restrictions.  I want to avoid stealth exposures of recipients to materials whose license conditions might be unacceptable to them.  I already make package manifests and usage requirements available for independent review before electing to download a package of materials.  This same device could be applied for redistribution of a full set of the Microsoft XML Reference Schema materials, for example.  I would take the same precautions in making a CD-ROM compilation of materials. I would include the manifest and license restriction information, along with instructions for how to obtain the materials.  I would not include the more-restricted material on the CD-ROM at all.

Finally, when I am not authorized to redistribute material (or the recipient is not similarly entitled—the redistribution right is not transfered), I will apply the same methodology that I use in public software-development efforts that rely on available but non-redistributable materials.  For example, the ActiveODMA development tree is being organized with a nodist subsection

• that identifies materials that licensees or recipients are not permitted to (re-) distribute,
• that are required in order to verify, duplicate, and rebuild the work, and
• that are freely available (e.g., the Microsoft Visual C++ Toolkit 2003 and the Microsoft Platform SDK February 2003 releases).

The nodist subsection is for instructions on how to obtain the material and install it in a way that works for the open-source ActiveODMA development projects.

In this regard, the Microsoft license presents no greater burden for me than any other license that permits redistribution and is materially different than the one the containing contribution is under.  I have the same difficulty packaging software that is created with the GNU Public License (GPL) in my distributions as I do packaging material under the Microsoft Office XML Reference Schema license.

3.4 The Derivative-Use Bind

The prohibition on creation of derivative works is a different problem.  There is nothing I can do, short of negotiating a separate license (one that would likely not be transferable to recipients of my work) if I have a compelling interest in creating a derivative work.  Unless there is some sort of share-alike provision, I can't pass it on and I would be reluctant to engage in such an arrangement.  I would have to step out of the Open Source Definition and I am unwilling to do that.

There is no bind here without a compelling interest in making derivative use (including derivative works).  In the case of OX and the Office XML Reference Schemas, I think there are three important cases:

• Appeal to elements of the Office XML Reference Schemas, and their namespaces, in derivative metadata based on Office XML elements.  Search results delivered as XML (non-OX) documents are a simple case.  Where OX-format elements are being provided in the search result, it would be great to identify them as such in the (software-derived) schema for the search result itself.  I think it would take extraordinary, counterproductive contortions to avoid creation of a derivative work.  Interoperability and coherence in reliance on OX would be undermined.
    
• Support for micro-content based on OX-format elements.  There is excitement about the ability to exploit the internal structure of OX documents in applications involving semi-structured and micro-structure content.  This comes through in Brian Jones's Channel 9 presentation and on his blog and in the announcement materials.  Again, one wants to preserve the OX nomenclature, identification, and schema elements in preserving the nature, formatting, and distribution of such micro-content material.  It is difficult to avoid having this be seen as creation of derivative works in persistent, recorded forms.
    
• Creation of Specialized, Custom Application-Specific Documents.  Users of Microsoft Office applications are accustomed to the idea of templates as a device for casting documents in particular forms that fit into work processes and specialized activities.  The introduction of OX formats creates a potential for specialized software applications to produce and ingest Microsoft Office-compatible documents that
  • have derivative XML schemas that limit and simplify the content,
  • have derivative XML schemas that force particular limited structure on documents of the application, and
  • introduce application-specific extension elements of the XML in ways that preserve the ability to employ the documents in Microsoft Office under the OX format specifications.

It strikes me that these are valuable cases that can be claimed to involve the creation of derivative works.  It might not be in Microsoft's interest to discourage some or all of these cases.  I favor allowance of derivative works with an appropriate weakening of the license's restrictions.  In particular, it provides a zone of safety for developers who are unclear when and whether an use constitutes creation of a derivative work. 

Whatever the concerns that Microsoft has in this area, I notice two important opportunities that result from the early announcement and discussion:

1. It is easier to relax a narrow license than it is to retract a too-liberal one.  There is opportunity to evaluate relaxations in the copyright license that address Microsoft concerns around preservation of the integrity of the OX formats and any other concerns that are identified.  Even experimental, limited relaxations can be undertaken simply to confirm where the ideal fit might be and to mitigate speculative risks.
     
2. There is ample time to explore and experiment with the OX formats, identifying the important use cases that are in Microsoft's self-interest to encourage by liberalized copyright licensing terms.

A. Source Materials

A.1 Available Material and License

Microsoft proposes to make the OX formats available under the same terms that existing (non-OX) Office XML documentation and schemas are provided.   Those materials and their license information can be accessed and downloaded in a couple of ways:

• Office 2003: XML Reference Schemas (version 4 of 2005-01-14 in a 5.56 MB Windows Installer file, xsdref.msi).  The package installs on Windows 2000 SP3 and later.  There is no registration requirement.  No EULA is presented.  Click-through acceptance of a license is not required.  Installation on my Windows XP configuration adds a folder at “Start | All Programs | Microsoft Office 2003 Developer Resources | Microsoft Office 2003 XML Reference Schemas” which organizes 24 XML Schema Definitions (in folders of .xsd files) along with one documentation file in Microsoft HTML Help (.chm) format.
    
• Office 2003 XML Reference Schemas License Overview (undated version accessed 2005-06-04T05:01Z).  This provides a link to the 2003-11-17 legal-notice instructions for use of the schemas and their related specifications, to the patent license agreement, and to an undated license-update memorandum from Microsoft Senior Directory of XML Architecture, Jean Paoli.  The Paoli memo provides some minor clarifications on the license without material impact on the aspects that have my attention.
    
• Office 2003 XML Reference Schemas Product Information page (undated version accessed 2005-06-04T05:23Z).  In addition to other elements, this “portal” onto the reference schemas provides links to an overview of the reference schemas, to a Frequently-Asked Question (FAQ) page on the reference schemas, and to a Jean Paoli memorandum celebrating the announcement of the Microsoft Office XML Open Formats (what I have been calling OX here).
    
• Word 2003 XML Software Development Kit (January 2005 version).  This is an on-line SDK reference on the use of the Word 2003 XML format.  There is a version available for download (version 0205 of 2005-02-04 in a 3.85 MB Windows Installer file, wdxmlsdk.msi).

A.2 Proprietary Notices

At the bottom of the Office XML Software Development Kit web pages and the HTML Help pages, there is a consistent notice:

• A Microsoft Corporation copyright notice.
• Accompanying text:
  “Permission to copy, display and distribute this document is available at: http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp”

In the XML Schema files themselves, there is also license text.  The text is the same as that in the reference HTML version in the on-line MSDN Library linked just above.  the following declaration is typical (from visio.xsd dated 2004-03-04–10:39):

<xsd:annotation>

<xsd:documentation>

Permission to copy, display and distribute the contents of this document (the “Specification”), in any medium for any purpose without fee or royalty is hereby granted, provided that you include the following notice on ALL copies of the Specification, or portions thereof, that you make:
 
Copyright (c) Microsoft Corporation.  All rights reserved.  Permission to copy, display and distribute this document is available at:  http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp?frame=true.
 
No right to create modifications or derivatives of this Specification is granted herein.
 
There is a separate patent license available to parties interested in implementing software programs that can read and write files that conform to the Specification.  This patent license is available at this location:  http://www.microsoft.com/mscorp/ip/format/xmlpatentlicense.asp.
 
THE SPECIFICATION IS PROVIDED "AS IS" AND MICROSOFT MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
 
MICROSOFT WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE SPECIFICATION.
 
The name and trademarks of Microsoft may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Specification will at all times remain with Microsoft.No other rights are granted by implication, estoppel or otherwise.

</xsd:documentation>

</xsd:annotation>

A.3 Other Resources

There are a variety of on-line resources with coverage of the Microsoft Office XML Open Format (OXOF or OX for short, and yes, I have been known to read Piers Anthony).

• Brian Jones: Office XML Formats.  Discussions about XML in Office and the Microsoft Office Open XML File Formats.  An MSDN Blog.
    

• Microsoft Makes XML the File Format for the Next Version of Microsoft Office.  Q&A: Senior Vice President Steven Sinofsky explains how making XML the default file format is likely to help customers cut costs for data storage and bandwidth, improve security and boost data recovery.  Microsoft Press Pass, June 1, 2005.  The sidebar provides useful links to available white papers and the initial press release.
    

• Brian Jones – New Office file formats announced.  MSDN Channel 9 video interview by Robert Scoble.  2005 June 1, 21:18 pdt.  This video conveys much of the excitement of the developers for what is being accomplished in this work.
    

• Office 2003 XML Reference Schemas Frequently Asked Questions.  Microsoft Office System Product Information, Office XML Reference Schemas Licensing.  2005 January 17 update.
   

• The Future of Microsoft Office: Be the First to Know.  Microsoft Office Online.  Being set up in time for the 2005 June 6 kick-off of the Microsoft Tech-Ed 2005 Conference, this site will accumulate more material over time. The available white papers and an extensive FAQ on the new format are already available.