Orcmid's Lair status 


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.

Orcmid, I really appreciate your painstaking effort to untangle this web and clarify what might work. However, even if necessary, it just makes my head hurt to try to think this through. Examples of open source programs and applications that managed to satisfy the directives and constraints you describe would be extremely helpful.

And on another topic: couldn't I just use a CreativeCommons license for my software? What do the other OSS licences provide? Is it the use at your own risk and don't blame me for problems clause?
Well, I see I've raised the specter.  That shows how much Bill and I react similarly to some of these things.

This merits a separate post.  Until then, here are some bullet points.

1. Most situations involving the use of IP (and that includes anything with an open-source license) have these gotchas lurking over them and require some diligence.  If you are concerned about safeguarding the recipients of your work from mistaken actions, there is even more.  But it is really pretty straightforward in reality -- you don't hear about too many open-source-related lawsuits other than the big SCO hoo-hah.

2. It's hard to find examples of what I recommend because it is generally not done.  Most people pick up a license from a file and slap it into a directory of their stuff for distribution. It's still uncommon to see IP notices in individual files.  The copyright notice is even bogus most of the time.  (To transfer your work to the Free Software Foundation, or anyone else, takes more than borrowing their notice and license.)  On the other hand, no one has gotten in much trouble over this and for projects the public CVS tree and any distribution lists tend to provide the contribution history if you need to look for it.

3. I recommend Dan Bricklin's "A Developer's Introduction to Copyright and Open Source" as a gentle introduction to the topic.  This is a sensible guy offering practical explanations for the basics.  The DVD is very worthwhile and also affordable if you get a personal-evaluation edition.

4. Oh, I'll be providing some examples myself.  There may be others, more likely in packages offered by big companies.  Find some IBM open-source or one of the Microsoft ones.  I'll be looking around too.

5. I think you can use a Creative Commons license, although the organization recommends that you use one of the recognized open-source licenses, even for software documentation.

6. You should review the Open Source Definition for their cookie cutter.  Probably the most-generous license is the BSD license (short of declaring something into the public domain), with the community ones at one pole and the GPL at another.  Licenses that restrict commercial (as opposed to closed-source) use don't fit the OSD as I recall.

7. Warranty disclaimers don't really have much to do with the licenses, as far as I can tell.  The plaintext license file (and the typical EULA) is mainly a convenient place to stuff all those capitalized statements.  It is also a way to establish that you've probably read it.  It's not granting you anything and it is independent of your exercise of the license, so it is really something else.  I am not talking about conditions such as no-reverse-engineering and such, but the disavowal of all responsibility for the software being good for anything, having defects, etc.

8. *NONE* Read my lips *NONE* of this helps you in regard to patent infringement.  Having a defensive clause like Microsoft's doesn't prevent them from being found in infringement, and it won't help someone with less clout than Microsoft at all.  The patent specter is a genuine monster under the bed and the only thing that protects most of us is that we are small cheese and not worth writing a letter to on legal stationery.  Most of us have no idea whether we are writing software that infringes one or more patents and we don't want to know.  Unfortunately, ignorance -- which can work for copyright -- is no excuse for patents. Funny, heh.
Post a Comment
Construction Zone (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 05-07-14 13:28 $
$$Revision: 1 $