Wow, there were a ton of great comments on my last post. While there were a large number of them, there were two primary themes I saw repeated. The first was that there are still a number of concerns around the true “openness” of the MS Office Open XML Formats, based around licensing issues. The second theme was that there was some skepticism on why we don’t use the OpenDocument format in Office. I’ll try to talk as best I can to both of these issues. I’ll cover the first issue in this post, and then I’ll write a separate post to address the second issue (that way the comments can be more focused). I already touched a bit on the licensing issue in this post back in June, and I talked about the OpenDocument format in this post. I’ll drill into it a bit deeper though as it looks like there are still a number of unanswered questions.
Some folks seemed to think that the licenses for our formats were crafted to block out our competitors, but that couldn’t be further from the truth. If you look out at the market place, there are a number of similar products, and the main ones (WordPerfect; Lotus; OpenOffice; etc.) should all be able to use our licenses and documentation to build in support for the Office XML formats. There have been several postings asking about whether our license for the Office XML schemas is compatible with the GPL. I’m not a lawyer and I don’t pretend to understand all the intricate details in these licenses, but people seem to be interested in my opinion, so I’ll share it. OpenOffice is covered by something called the Lesser General Public License or LGPL, not the GPL (more on OpenOffice license here). Here is some text from the LGPL that should help clarify the compatibility concern:
Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.
When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.
We call this license the “Lesser” General Public License because it does Less to protect the user’s freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances.
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.
Although the Lesser General Public License is Less protective of the users’ freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library.
To me, this language says that it would be totally possible for someone to develop a “library” that can handle transformations between Office and OpenOffice documents. It also says to me that it doesn’t matter whether that library is covered by the GPL or the LGPL. The LGPL language seems to encourage free software developers to link in these libraries to give them “an advantage over competing non-free programs.”
I assume that Sun or whoever else chose the LGPL for OpenOffice instead of the GPL was aware of this distinction relating to libraries. It definitely looks like they wanted to allow these kinds of extensions to be covered by other types of licenses to give people flexibility to go with other approaches.
Of course, any library that you would build to interface with the LGPL program, such as OO, would be covered by the Microsoft Office XML license, which is here: http://www.microsoft.com/office/xml/licenseoverview.mspx. There has been some FUD and trash talk in some blogs about this license and the whole issue of IP in schemas. I think some people are going overboard on this whole issue. This Microsoft license isn’t the GPL or the LGPL, but there are dozens of licenses listed at www.opensource.org that seem to be ok with them. From my perspective, we’re just trying to provide our IP in an open and royalty-free way so developers can do something useful with it, like build transforms. Some of the legal mumbo jumbo around the licensing can get confusing, but hey, Rome wasn’t built in a day and I find some of the stuff written in the GPL to be pretty confusing too. At least the Microsoft license is short (one page).
Again, I’m not expert, but the Microsoft license seems to say that you can use the Office XML specs to develop programs that can read and write Office XML files. That seems pretty straightforward to me. I don’t see any barriers here to using this license to develop a transform that can interface with OO. This shouldn’t come as a surprise to anyone given the OpenOffice already has built in support for the Microsoft Office XML formats that we shipped with Office 2003. I would expect they will do the same when the new default XML formats come out in Office 12. That’s to be expected because I can image for OpenOffice, a significant demand they get from their customers is to support the Microsoft Office Document formats. Support for our formats is something that they put pretty high up in their marketing so that’s why I’m making that assumption.
Hope this helps a bit. I really want to make it clear that it was a huge goal of ours to make these formats open and interoperable. That’s why the license was crafted the way it was. Opening up the formats creates a whole new world of potential scenarios and solutions that can be built on top of Office documents.