I could make a full time job of tearing down the "say anything we possibly can" approach to Open XML opposition. Seems like we're seeing a new level of arm-flailing and finger pointing, now that we are weeks away from the close of the post BRM period. I wanted to offer some comments about the SFLC's analysis of the OSP. This is an unfortunate report, these all represent issues that have been raised in a campaign that includes innuendo and supposition, leaving out inconvenient information and language and ignoring the same, similar, or less attractive, language that exists for ODF.
The big news in this is their admission/confirmation that the OSP is in fact compatible with the GPL. They say "The OSP cannot be relied upon by GPL developers for their implementations not because its provisions conflict with the GPL but because it does not provide the freedom that the GPL requires." They go on to identify that "freedom" being linked to the OSP being unsafe is because new versions of the specifications could be excluded from the OSP in the future.
It is unusual for promises like the OSP to automatically include every spec or all future versions (IBM's pledge is exactly like ours). The norm is for new versions to be added to them to be covered. In the case of Sun's statement new versions are automatically added only when they participate in the development of the new version to the extent that the OASIS IPR rules would then obligate them to provide patent rights under the OASIS IPR Policy. None of these promises include future versions of the specifications without any qualification.
Let's deal with the points one by one:
This section points out that the OSP only applies to listed versions of covered specifications. True, except that we have already committed to extending it to ISO/IEC DIS 29500 when it is approved in our filing with ISO/IEC. For ODF, IBM in their ISP takes the identical approach. Strange how things that seem appropriate for ODF are not appropriate for Open XML.
Not true. The OSP is a promise to not assert patents that are necessarily infringed by implementations of covered specifications. Like all similar patent non-asserts (including the Sun and IBM versions for ODF) the promise covers that part of a product that implements that specification (and not other parts that have nothing to do with the specification). While the Sun covenant is silent about conformance to the specification, the OSP allows implementers the freedom to implement any (or all) parts of a covered specification and to the extent they do implement those portions (also known as conform to those parts) they are covered by the promise for those parts. Contrast that to the IBM pledge that requires total conformance and so programming errors or absence of something required by the spec (but not by an implementer's product) means that the promise is totally void for that product.
Not true. As far as we are concerned we are happy to extend the OSP to implementers who distribute their code under any copyright license including the GPL. The FAQ cited just states what everyone knows and acknowledges, the GPL is a copyright license that is drafted in a way that leaves many issues (not just those related to patent rights) open to many interpretations. Any particular user or implementer should read the GPL carefully and make their own judgment about what it means and requires in accordance with their own circumstances. The FAQ states that Microsoft is not in a position to give blanket advice about the GPL to others. They missed these two FAQs for some reason...
"Q: Is the Open Specification Promise intended to apply to open source developers and users of open source developed software?
A: Yes. The OSP applies directly to all persons or entities that make, use, sell, offer for sale, imports and/or distributes an implementation of a Covered Specification. It is intended to enable open source implementations, and in fact several parties in the open source community have specifically stated that the OSP meets their needs. Moreover there are already a significant number of implementations of Covered Specifications that have been created and/or distributed under a variety of open source licenses as well as under proprietary software development models. Because open source software licenses can vary you may want to consult with your legal counsel to understand your particular legal environment.
Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?
A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can't give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s)."
I am afraid you failed to read the last quote you put, it clearly is anti-GPL FUD to me.
I don't read it that way. From my POV, the comment says that it is inappropriate for us to offer an interpretation of the GPL for other potential users.
The fallacy in your analysis is that SFLC would not like IBM or Sun's patent covenants either. They oppose software patenting in general, Moglen has been very clear about that.
The reason that GPL developers find it legally possible to work with Sun and IBM is that both companies have contributed directly to the development of GPL and LGPL code implementing the same standards that their covenants cover. Thus, they are not only bound by their covenants, but by the GPL language regarding patents, which unlike the covenants do adequately protect GPL developers.
While there are differing opinions about the GPL, it is the same for any license. If lawyers never disagreed, there would be no reason for courts. GPL3, and the two other licenses using its text, LGPL3 and the Affero GPL3, became perhaps the most legally scrutinized licenses in the world during their development. Most of the major corporations in software had their lawyers on the GPL3 committees, as did many organizations like W3C, and many other interested parties. Because of the very large and diverse legal team that participated in its development, we can put forward the GPL3 family of licenses as more legally "solid" than, for example, Microsoft's own licenses. But GPL2 has done quite well in this regard too - although we hear of many cases being settled in favor of the GPL developer by SFLC and others, no defendant has dared to go to court.
We also have Microsoft's past actions to consider when we look at its present promises. Nobody can argue that the company has behaved in a hostile manner toward Free Software developers, for example spreading patent FUD about our software and yet over a period of years refusing to disclose the particular patents and the code that Microsoft feels they cover. The ballot-box stuffing that occurred in ISO is another example of current reprehensible behavior. So, of course SFLC should interpret Microsoft's promises in the worse possible light.
Gray, based on your last comment, I guess it's now inappropriate for me to interpret what you've written as being useful in any context whatsoever... ?
Bruce, if you could please post a link on my blog to action that Microsoft has taken against people who have developed solutions using Open XML, my readers would appreciate it. Good luck finding one. Instead of broadly implicating entire companies for their policies, let's stick to a problem that we can examine closely, which is patent protection for the file formats in question. (Others at Microsoft can speak to the broader issue). We're happy to let the existing implementations of Open XML speak to the willingness of developers to implement the spec. Nothing like a dose of reality to settle the paranoia, eh?: http://www.openxmlcommunity.org
If SFLC would be opposed to IBM's approach to ODF protection, then their report on ODF would have indicated so. There is no mention of the IBM promise.
Dan, if you're one to esclate issues to the point of absurdity, please feel free to do so somewhere else. But the rejection of SFLC's inaccurate material is useful regardless of our willingness to interpret GPL for you, as are comments regarding the inconsistency of SFLC's approach to ODF and Open XML.
For both of you, again [repetition seems to be a favorite marketing strategy for anti-open xml people so I'll employ the tactic here], I am saying that our unwillingness to interpret GPL does not equate to anything other than our unwillingness to interpret GPL.
You said "Instead of broadly implicating entire companies for their policies, let's stick to a problem that we can examine closely...". Unfortunately, you can't duck the issues like that.
Microsoft's anti-competitive behaviour and recent patent sabre-rattling are huge, all-pervading issues for consumers like me. Microsoft's actions for its own profit have cost me money, and affected my ability to make IT decisions based on merit rather than lock-in. If you want me to list Microsoft's actions that I've found particularly objectionable then I can, but I'm sure you're perfectly aware what I mean.
I believe that you have to accept that a broad section of your customer base does not trust Microsoft, and as Bruce says, will "interpret Microsoft's promises in the worse possible light". Protesting that Microsoft is a changed, and trustworthy, company won't carry any weight until your changed behaviour, and time, have allowed your customers to believe in you again.
I'm anti-OOXML because I don't trust Microsoft. Then again, I'm not particularly pro-ODF: the file format is not critical to me, I just need to get my work done. I could become more pro-OOXML, if the standard was governed independently of Microsoft.
Perhaps you could block your nose and read Rob Weir's "Contra Durusau" posting, and give some serious thought to his suggestions for making OOXML really independent:
1. Ecma changes their TC45 charter to explicitly call for all maintenance activities (corrigenda as well as technical revisions) to be performed in an SC34 WG.
2. Ecma explicitly withdraws their submission on DIS 29500 maintenance from the agenda of the Oslo SC34 Plenary and instead submits a proposal asking for future OOXML work to be done in a new WG in SC34, with a non-Microsoft chair.
3. Microsoft publicly states that they will hand operational control of OOXML to SC34, not only for maintenance of OOXML 1.0, but also for technical revisions, and that they will support this being done under JTC1 IPR rules, and using the JTC1 process, and that they will implement whatever revisions SC34 develops within 1 year of approval.
Gray Knowlton wrote: "Bruce, if you could please post a link on my blog to action that Microsoft has taken against people who have developed solutions using Open XML, my readers would appreciate it."
This is a common rhetorical device. You propose your own straw-man, and ask me to knock it down.
Gray Knowlton further wrote: "If SFLC would be opposed to IBM's approach to ODF protection, then their report on ODF would have indicated so. There is no mention of the IBM promise."
I have read the SFLC opinion letter. It is very clear that their opinion relies on the Royalty-Free rules of the OASIS ODF standard committee and Sun and IBM's commitments to comply with those rules as contributing members of that committee, not just upon the covenants. Microsoft did not choose to submit OOXML to a standards organization that asserts that sort of rule.
But we should not pretend that this is just a legal question. OOXML is so large that a programmer can not be expected to learn it in his useful lifetime. Fully 10 times the size of ODF, to represent the same documents. That's just one more reason (and there are others as well) that Microsoft's sincerity is in question - the proposed standards document doesn't appear to be meant to enable competing implementations.
Odd that your comments sound A LOT (exactly) like Don Christie, to whom I spoke while in New Zealand recently and heard these very same words. I did read Rob's post, but I thought I'd let that rest because I'm bored with beating up on him. Besides, if you are so inclined, you should ask Rob to explain the ODF maintenance plan to you. That should tell you all you need to know about the strategy being employed.
I am grateful, however, for the acknowledgement that your Anti-Open XML stance is because of your general Anti-Microsoft sentiment. I think that this is short-sighted, seems to me like Anti-Microsoft individuals would be lining up at our front door (like they have for quite some time) to take control of the Word, Excel and PowerPoint file format specifications.
As far as recounting the entire history of Microsoft legal activity, again, it's not really something that is helpful. The article in question states that Open XML Developers are not offered suitable protection. We disagree with the position strongly, and have a healthy set of facts and existing implementations to back it up.
The great thing about being a large multi-national corproation is that you don't get to say "irrevocable promise" and then retract that later. It would be really, really dumb for Microsoft to support standardized file formats in its products, then start suing people for doing the same thing, no?
This isn't a game of semantics, it is real. Hundreds of companies seem to have overcome this barrier with little difficulty. If you are actually developing software, and you have actual, specific concerns about your ability to implement the specifications, you are welcome to email Officeff@microsoft.com to discuss your SPECIFIC issues. Let's knock off with the fear-mongering.
"Instead of broadly implicating entire companies for their policies, let's stick to a problem that we can examine closely"
It would be rather strange to single out OOXML/OSP living in a vacuum separated from other Microsoft actions. The directors making the all the big decisions are ultimately the very same people in the company. They are the ones who made decisions that caused EU to fine the company in an unprecedented manner, they are the ones who made decisions that caused the company being investigated by both US and EU authorities, and so on. It's the very same people still calling the shots.
So, ask yourself, should we trust those who already have been charged, found guilty, and found continuing they illegal behavior? I don't think so, really. The other hand is already way too deep in our pockets, should we just let them put in the other hand, too, because they're assuring us that it's ok?
Because by the end of the day, it is in they hands how they want to proceed with OOXML. One soft voice in blogosphere does not count even the slightest when it comes to making more money.
"interpret GPL for you"
I think you should interpret GPL to yourselves first of all to understand what you are dealing with. GPL is the most widely used FLOSS license on the planet and if you are honest in your promises to interoperate then surely you can't expect the majority to give up they principles just as a starters?
Almost everybody else is already out they doing the interoperability thing, you know, and they all have learned to deal with and even prosper from GPL. You can do the same if you want but it takes a bit more than we've seen so far. The rules have evolved during the years and no single participant with single promise can make everything change. It's actually really simple, you got to play by the rules set by others (the difficult part) or they simply won't play with out (easy but unfortunate - but it's up to you).
Thanks for reading, to be taken with extreme seriousness ;)
Nice attempt to deflect there, Gray. "Please link to action Microsoft has taken against developers of OOXML implementations"... if you define the criteria narrowly enough, then of course you can ensure that nothing matches.
If you'd like to make this issue go away, just publish a complete implementation of the OOXML specification, licensed under the GNU General Public License, version 3. Since Microsoft will then be bound by the GPL's patent language, there will be no further issue. This is exactly what IBM and Sun have done. If you want to be treated like them, then act like them.
Gray Knowlton wrote: "IBM in their ISP takes the identical approach."
Actually, that isn't the case. IBM's covenant does not have any language excluding later versions. Only the Microsoft covenant has that. Sun's covenant explicitly grants rights to later versions.