MS-Office schema not as open source friendly as Microsoft says it is

Summary:When Alan Yates, Microsoft Information Worker Product Management Group business strategy general manager, first came to me to say that his company had been railroaded when Massachusetts voted the OpenDocument office file format (ODF) in, and Microsoft's Office XML Reference Schema (OXRS) out, one of his original arguments was that OXRS was getting a bad rap for not being implementable in open source software.

When Alan Yates, Microsoft Information Worker Product Management Group business strategy general manager, first came to me to say that his company had been railroaded when Massachusetts voted the OpenDocument office file format (ODF) in, and Microsoft's Office XML Reference Schema (OXRS) out, one of his original arguments was that OXRS was getting a bad rap for not being implementable in open source software. As Yates originally explained it to me, "Our license may not be compatible with the GPL, but it is compatible with many other open source licenses, and certainly can be used with the OpenDocument license."  However, as it turns out, "many" is in the eyes of the beholder.  When I went back to Yates and explained how I found that claim to be untrue, he clarified his original claim by saying "While it is beyond my capacity to analyze [all of the open source licenses listed on the Open Source Initiative's Web site], we think that there is no problem with the two most used, key alternatives to the GPL; the LGPL and the BSD licenses."  

I never fully investigated that claim and it's been nagging at me ever since so I finally decided to circle back to it for some better vetting than what I originally did.   How is it that Microsoft's patent license could actually be compatible with open source?  Particularly when open source advocates are saying it is not.

The reason Microsoft's claim regarding the compatibility of OSRX's patent license with open source software development is so critical is because the company believes that Massachusetts' test for openness -- a test that document formats must pass before the state's Information Technology Department (ITD) will standardize on them -- is  too strict.  In coming up with its test, Massachusetts' ITD officials wanted to be assured that could get software that complied with its selected standards from any solution provider (proprietary, open source, etc.) and that all developers would have the maximum latitude to develop that software without any patent-enforced restrictions.  In applying its test to OSRX, the ITD ultimately determined Microsoft's patent license to be too restrictive in that it prevented open source developers from developing OSRX-compliant software.  Meanwhile, Microsoft was arguing the opposite -- that its patent license was compatible with open source.

So which is it?

One of the key tenants of open source software is that I can write some code, publish it under an open source license, and then you can take that code, modify it, and republish your new derivative using either the same open source license that I used when I published the original code or a different one that's compatible with the one I used.  In order for the source code to be open in this way (as in "open source"), I must be able to publish the code in a way that my copyrights as well as any of my patents that I may have implemented in the software are transferable to you.  For example, the following text in the Open Source Initiative-approved GNU General Public License makes its position on patents quite clear:

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that re-distributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. 

The quid pro quo, if you take that code and modify it, is that your copyrights and patents are also transferable back to me or to anyone else that wants to modify the code.  If the code is an implementation of someone else's patents and we're openly passing that implementation around without the patent holder's approval, the copyrights are irrelevant.  It could be grounds for patent infringement.  But, for now, let's assume that's not the case.  This mutually required transferability basically enforces the spirit of communal software development and that is what open source is all about. 

But, as it turns out, there are certain open source licenses -- the LGPL and the BSD cited by Yates for example -- that are silent on the matter of sublicensability of copyrights and patents.  At least one interpretation of that silence, according to open source attorney Larry Rosen, paves the way for Microsoft to claim the compatibility its claiming.  Said Rosen via a phone interview:

 

One suggestion is that a license which does not expressly permit sub-licensing is not sublicensable. The question is, "If you have a license that's not expressly sublicensable, is it sublicensable?" Some people say yes. Others say no.  To solve that problem, most open source licences that have been issued since those earlier license that are silent on sublicensability  have added provisions to make themselves expressly sublicensable. 


 

Rosen told me that he doesn't necessarily agree that a license's silence on sublicensabilty means that it's not sublincensable.  He prefers the interpretation that swings in the direction of allowing it but readily admits it's not known what a court's intepretation might be since there have been no test cases. 

But just supposing the that silence means that it's not sublicensable; then that means that an open source license like the BSD would not conflict with Microsoft's patent license, which expressly forbids sublicensing, thereby technically making the two compatible under one interpretation.  Another interpretation -- this time my slight variation on Rosen's -- is that by not expressly requiring sub-licensing, an open source license may not necessarily forbid it or require it, but instead leaves the door open for the licensee to forbid it through a patent license .  Recall that patents supersede copyrights.  It doesn't matter whether my implementation of someone else's patent is in my own source code, or if I used three pieces of fruit and and a vegetable to implement the patent.  Either way, it is patent infringement.

So, is Microsoft's patent license -- which prevents sub-licensing of its patents -- compatible with open source, or not? It's apparently a matter of interpretation.  While you decide, it's clear that Massachusetts' test for openness wasn't simply a pass/fail test on compatibility with just any open source license.  What Massachusetts was concerned about -- and rightfully so -- is that just like with Adobe's license for the Portable Document Format, any open source developer could develop OXRS-compliant software without being restricted to using a specific open source license -- particularly one of the ones with ambiguous language that the open source community has since addressed with newer, more unambiguous licenses.  Compared to OXRS, ODF gives open source developers the latitude to pick whatever open source license they want, which is one reason why it passed Massachusetts/ test for openness and why ODF was ultimately selected as a standard format for storing the state's documents.


 

Topics: Open Source

About

David Berlind was fomerly the executive editor of ZDNet. David holds a BBA in Computer Information Systems. Prior to becoming a tech journalist in 1991, David was an IT manager.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.