Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton
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).
+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):
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.
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.
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 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.
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.
|You are navigating Orcmid's Lair.||
created 2002-10-28-07:25 -0800 (pst)