I wish I could wholeheartedly applaud the Microsoft announcement about native support for ODF, but I can't. Of course, it's better to have native support for ODF, no matter what motives may have influenced Microsoft's announcement, and I'm glad about that for the sake of end users. But it hasn't happened yet. Was the word 'vaporware' not coined for Microsoft? In any case, I'm in the "I will believe it when I see it" category when it comes to Microsoft. They've earned my caution.
And I see danger signs for FOSS I'd like to share with you, so you can consider them. Once again, the problem is software patents. Internet News indicates that commercial Linux/FOSS vendors, and the GPL license that Linux comes with, will be excluded:
Microsoft, however, frames its latest moves as part of fulfilling a company-wide interoperability initiative that it announced in February.
Uh oh. Remember this from February, when Microsoft announced the availability of APIs?
Going forward, Smith said that Microsoft will enter into a covenant not to sue open source developers who use the open APIs for noncommercial applications. Commercial developers will still need to obtain patent licenses to use the code.
GPL developers can't obtain patent licenses. That would violate the terms of the GPL. Period.
Like Microsoft doesn't know that.
But, you say, Linux is GPL'd and that's Microsoft's primary competition. Can it be that
commercial vendors and the GPL will be exiled again from the "even" playing field everyone else gets to be on? Why yes. It appears so. Commercial Linux vendors need not apply. Or they can sell out.
In short, I think Microsoft has no intention of interoperability with its actual competition, namely commercial Linux, like Red Hat and Ubuntu, et al, all the vendors who refuse to sell out to their patent demands. I'd say it has to be deliberate on Microsoft's part, because when Microsoft offered its Open Specification Promise (OSP), the promise not to sue over OOXML, sorta, kinda, it was clearly informed by the Software Freedom Law Center that the OSP's terms are inconsistent with the GPL and that the promise provides no assurance for FOSS developers. And Microsoft is certainly knowledgeable about the problems with RAND terms for FOSS. But they persist in offering what they know commercial GPL developers can't accept.
BetaNews explains Microsoft's announcement:
Commercial uses of some of these "open products" will require patent licenses. But Microsoft will license the patents on "reasonable and non-discriminatory" terms, at "low rates." At the same time, Microsoft will continue to retain trade secret licenses around some of its intellectual property, admitted CEO Steve Ballmer.
RAND terms again, it sounds like. Would you call that anticompetitive? I would. In short, I come to the sad conclusion this is just another move forward in Microsoft's new patents-plus-standards strategy to destroy Linux as we know it and force it into a Microsoft-driven proprietary mold, if it won't die off.
Will Office 2007's support for ODF actually work, do you think, if they ever really do it? Scott Fulton has an interview with Jason Matusow and Doug Mahugh on BetaNews and what they reveal should give one pause: :
DOUG MAHUGH, program manager for ISO 29500-based products, Microsoft: One thing to be very clear about here is this: When we say, "support for ODF in [Office] SP2," we intend to write very compliant ODF documents when you save a document. However, it's not a given that everything you can do in the Office UI is savable under ODF. As you're alluding to, there are things -- SmartArt, conditional formatting, things like that -- that we have in Office and that are popular features, where there is no way to save those in ODF, currently.
The way we're approaching that, I can share a little bit with you: We're not throttling the UI, as you describe, where certain things are disabled. Rather, at the time you save, we're telling you, "Hey, you're saving in this other format; some information in this document may be lost." That sort of thing. And let me tell you why we made the decision to do it in that particular way: There are situations where some of that functionality may be very useful to the user, even though it can't be serialized out to the format that they're saving in.
For example, I could e-mail you an ODF spreadsheet, and you might have Excel 2007 and want to open that spreadsheet and do some quick thumbnail analysis of a few things, use conditional formatting to help you identify some trends quickly, and so on. We want to let you do that, even though you can't then save that conditional formatting back out to ODF. So for that reason, we've tried to look at it as, these issues we're talking about, functionality that may or may not be included, those are issues when you save the document, but we're not letting those factors affect the overall user experience, or the sorts of analytical tools that you might have at your disposal....
The thing that we can't do on our own is change the inherent limitations of each format, and the ways that certain formats allow for certain things that other formats may not. For that, we feel we can get involved in the standards organizations, and bring our experience to the table and talk with others about it, but we don't directly control that.
How does that sound to you? Reassuring? It sounds to me like when difficulties arise, they'll say it's ODF's fault. Before Microsoft came up with the patents plus standards strategy, it used other, but similar, tactics, according to Novell's complaint in its ongoing antitrust litigation against Microsoft:
90. Third, Microsoft unilaterally made the proprietary Rich Text Format
("RTF") of Microsoft Word the standard file format for text-based documents in
applications developed for Windows. Upon capturing the standard, Microsoft
strategically withheld the specification to injure competitors, including Novell.
91. As Microsoft knew, a truly standard file format that was open to all ISVs
would have enhanced competition in the market for word processing applications,
because such a standard allows the exchange of text files between different word
processing applications used by different customers. A user wishing to exchange a text
file with a second user running a different word processing application could simply
convert his file to the standard format, and the second user then could convert the file
from the standard format into his own word processor's format. Thus, a law firm, for
instance, could continue to use WordPerfect (which was the favorite word processor of
the legal profession), so long as it could convert and edit client documents created in
Microsoft Word, if that is what clients happened to use. Microsoft knew that if it
controlled the convertibility of documents through its control of the RTF standard, then
Microsoft would be able to exclude competing word processing applications from the
market and force customers to adopt Microsoft Word, as it soon did.
92. The specifications for RTF were readily available to Microsoft's
applications developers, because RTF was the format they themselves developed for
Microsoft's office productivity applications. Microsoft withheld the RTF specifications
from Novell, however, forcing Novell to engage in a perpetual, costly effort to comply
with a critical "industry standard that was, in reality, nothing more than the
preference of its chief competitor, Word. Indeed, whenever Word changed its own file
format, Microsoft unilaterally and identically changed the RTF standard for Windows,
forcing Novell and other ISVs constantly to redevelop their applications. In this
manner, Microsoft gave Word a permanent, insurmountable lead in time-to-market,
and made document conversions difficult for users otherwise interested in running
non-Microsoft applications. Many WordPerfect users were thus forced to switch to
Microsoft Word, which predictably monopolized the word processing market.
93. Fourth, Microsoft unilaterally announced that other features of Word
were to be considered Windows standards. One important example is the "tool bar,"
which typically runs across the top of the PC's screen in applications operating on
Windows. Microsoft's tool bar originated in the Microsoft Office applications, such as
Word and Excel, while ISVs such as Novell developed competing features, such as
WordPerfect's more widely admired "button bar." Unable to design a better feature
than WordPerfect's, Microsoft simply declared its toolbar to be the Windows standard,
supplanting WordPerfect's button bar and other competitors' offerings. As in the case
of RTF, Microsoft forced Novell to delay its time-to-market while redeveloping its
applications to an inferior standard. Because these standards were lifted directly from
Microsoft's own applications, those applications, by definition, were always
"compatible" with the standards.
So, let's just imagine for a minute that we are Microsoft. We feel it's too dangerous to do what we used to do, but let's say we have the same appetite for anticompetitive strategies so we can choke off the competition's air supply. Why couldn't we just insist on patent licenses, knowing the GPL forbids it, and then throw in some supposedly open standards to throw regulators off the track? We can then announce that Novell has signed up and things are swimming along, and as long as you use *their* version of everything, not a problem. Add in some proprietary extensions to "standards" so everyone else is always a dollar short and a day late, and there you are. The good olde dayes.
Over time, the tilt against true FOSS and the GPL gets steeper, because sellouts that sign a patent peace with Microsoft get "special" information their competitors can't, and then we, Microsoft, can point out that they are missing business opportunities, and hopefully get them to sign on too, thus killing off the GPL once and for all. Even if they don't sign up, they won't be allowed to work as well as the sellouts, so that should work just as well as the old system.
No? Impossible to imagine?
And then comes the best part. After we have isolated the GPL, we can start to sue all the commercial vendors who refused to pay us for our patents. Yum. World domination. By hook or by crook. Of course we'd have to stack standards bodies. But hey, we're Microsoft. We know how to do that. Then we can vote ODF into obscurity in the name of interoperability. After all, we own the desktop, and so when conflicts arise, why shouldn't we win?
That brings me to the last worry. Microsoft says it will join OASIS and worse, it hopes ODF's maintenance will go to the same folks who did the OOXML deal for them. What might that tell us? It tells me to put on a tin hat and watch out. Here's Jason Matusow, again from BetaNews:
It's like this: If I'm speaking German to you and you're speaking English, and you say to me, "Well, there's more than one way to skin a cat," there is no direct relationship between what you were intending to say in that idiom, and what I in German would hear in the translation of that.
To the extent that there's business competition that OpenOffice and Office and Corel's products and Adobe's products and IBM's products around Symphony or Google Docs or whatever, to the extent that product competition exists, there will always be that challenge of [how applications render formats versus how specifications interpret formats]. I think that will be an ongoing part of the discussion.
The reason that it's so important that we go and join the OASIS ODF Working Group and the PDF Working Group in AIIM and the ongoing work in JTC 1 and the work that's happening in ECMA, etc., is that these issues start to bubble up and become consistent discussions. We really hope to see ODF move to JTC 1 / SC 34 maintenance; and the ongoing work that started in DIN, the German national body, around translation and interoperability, also is progressing. It's currently under letter ballot, we're moving to SC 34 as well. All of these things are critical in having the engineers who are building these products be able to get together in a constructive environment and start to hammer out these issues, because there are inconsistencies.
Those aren't bad things; those are actually representative of the fact that you have innovation in play, and competition in the marketplace. All of those factors contribute to it, but there are definitely engineering tradeoffs that have to be discussed.
After watching the JTC 1 / SC 34 performance in the OOXML saga, would you describe it as a "constructive environment"? Or did it seem like a bendable Microsoft tool? Say, where's that final draft it promised us, incidentally? Doesn't JTC 1 / SC 34 follow the rules?
"Engineering tradeoffs" -- after watching the way OOXML was passed, how the deck was stacked, who do you think Microsoft intends to have to make those engineering tradeoffs? Incidentally, I don't agree with Fulton's analysis that anyone will be able to "make Office's next big format":
Developers will be able to write their own formats, plug them into Office, and then give users the option to make those formats the default for their setups.
So very conceivably, someone independently of Microsoft could build, say, a "better ODF than Microsoft ODF."
Unless they are a commercial GPL developer. Unless Microsoft clarifies to let everyone in without patent fears and without having to take a patent license, this isn't a party just anyone can join, as I see it from the information we have so far.
In short, it seems the proposed "openness" is tilted toward Microsoft's proprietary interests. Surprised? Why should we be? Remember the EU Commission's reaction last February when Microsoft first announced its interoperability changes? Fulton quotes them:
"The European Commission takes note of today's announcement by Microsoft of its intention to commit to a number of principles in order to promote interoperability with some of its high market share software products," reads an EC statement at mid-afternoon, Brussels time, following Microsoft's published statement but just prior to the press conference. "This announcement does not relate to the question of whether or not Microsoft has been complying with EU antitrust rules in this area in the past. The Commission would welcome any move towards genuine interoperability. Nonetheless, the Commission notes that today's announcement follows at least four similar statements by Microsoft in the past on the importance of interoperability."
It looks like they were right. Do you remember when Alex Brown announced the resolutions passed at the SC34 meeting in Oslo in April, the "Resolutions of SC 34 Plenary Meeting, 2008-04-05/09, Oslo, Norway"? Of course, one of them was that the final draft of OOXML would be available by May 1st. It still isn't. Brown now reports that ITTF got it, but it won't publish it. What are they waiting for? For the deadline for appeals to come and go, so no one can officially file a fact-based appeal? You think? Here's what Brown says:
The description of the Fast Track process in the JTC 1 Directives is generally pretty sketchy, but the closing stages of it are particularly poorly thought-through. Is it really sensible if Ecma’s efforts become, unchecked, the final IS text? Personally, I'd say not, and that an all-important QA stage has been omitted. ITTF are perfectly entitled to make special rulings (as they evidently have done, and not for the first time in this project) on the authority of the Secretaries General of ISO and IEC. It would be more sane, I believe, for them to have invented an FDIS stage for this project and have NBs submit editorial corrections. However I can see that the politics and practicalities of the situation make this difficult – it’s not hard to imagine every fault in the text being screamed about by the anti camp as a reason for halting the entire project.
Ultimately the situation raises questions which go to the heart of the relationship between JTC 1 as an entity, and its member bodies. Just who is in charge, the nations or the officials? The unfortunate state of the Directives have meant there have been too many occasions when officials have had to step in and save the nations from the folly of the Directives that they themselves approved. Like ODF and OOXML the Directives is (literally) a standard, a standard that has faults. Unlike ODF and OOXML, however, I am beginning to believe the Directives have got to a state where they cannot be redeemed by evolution and amendment. It may be time to start again from scratch.
So, a broken process, or one not even followed, results in a broken standard no one can actually use, and a decision that we can't read the format draft, because we'd notice problems with it. Instead, I gather they hope to run out the clock and publish it after it's too late to fix it or protest its acceptance. And as for ITTF's "right" to "make special rulings", I think the entire OOXML Fast Track process was one long bending of every rule in Microsoft's favor, with the result the final draft can't stand the light of day.
But I digress. The resolution I wanted to highlight is this one:
The passage of ISO/IEC 29500 has instituted a new era of standards activity in SC 34 related to document formats. ISO/IEC 29500 does not represent an isolated phenomenon, since SC 34 is also responsible for ISO/IEC 26300 and for interoperability between these and other projects.
SC 34 envisages the creation of three distinct working groups that meet the needs of:
1. ISO/IEC 29500
2. ISO/IEC 26300
3. Work on interoperability/harmonization between document format standards
Please note that they too expressed dreams of maintaining ODF, not just OOXML, and making the two "interoperable". So, now Microsoft says it will join OASIS and "help" ODF and it hopes ODF will go to the same folks who mangled OOXML.
Does that sound helpful?
I wish they were sincere. I'd love to be proven wrong. But I'm afraid, having watched Microsoft shove OOXML through the Fast Track process, despite it not even being usable, that ODF will be harmonized out of meaningful existence. I suspect that is the plan. And so to me, the announcement of "support" for ODF sounds like it could just be the next chess move in Microsoft's strategy to maintain its heavy footprint.
You think that's far-fetched? Then please read what Stephen Walli wrote in 2005, in a piece on how Microsoft ought to react to ODF so as to beat it. Compare it with what Microsoft has just announced and the media reports about it. I think we have a match.
ECIS's Legal Counsel, Thomas Vinje, has just issued a statement, that reads in part:
"These steps are in the right direction, but are not nearly enough to
achieve genuine interoperability. Moreover, they are clearly the result of
determined anti-trust enforcement by the European competition authorities
over the past decade and more. A closer look at their substance suggests
that Microsoft is still playing for time to further consolidate its
super-dominant position, and that continued anti-trust vigilance will be
"It is particularly striking that all of Microsoft's latest policy
statements on interoperability are still in the future tense, as though
these were difficult technical objectives. They are not. For several years
now other major vendors have implemented ODF 1.1, and most are about to
adopt ODF 1.2 once ISO approves the standard. Viewed in this light,
Microsoft's new promise to implement ODF 1.1 "in the first half of 2009" is
pretty underwhelming. If Microsoft really wants to promote interoperability,
it would join other vendors implementing ODF as its default format.
"And that's not the only problem. Current indications are that Microsoft's
disclosures for Office document interoperability so far are inadequate in
spite of the interoperability principles announced in February. In short,
what we seem to have from Microsoft today are incomplete disclosures coupled
with statements of future intention to implement earlier versions of open
standards. In other words, more delay.
The ODF Alliance is skeptical as well:
The ODF Alliance today greeted with
scepticism Microsoft's announcement of its intention to include
support for the OpenDocument Format in the first half of 2009. "The
proof will be whether and when Microsoft's promised support for ODF is
on par with its support for its own format. Governments will be
looking for actual results, not promises in press releases," said
Marino Marcich, managing director of the ODF Alliance.
The EU Commission has also just released a statement:
The European Commission has taken note of Microsoft's announcement on 21st May concerning supporting ODF in Office. The Commission would welcome any step that Microsoft took towards genuine interoperability, more consumer choice and less vendor lock-in. In its ongoing antitrust investigation concerning interoperability with Microsoft Office (see MEMO/08/19), the Commission will investigate whether the announced support of ODF (OpenDocument format) in Office leads to better interoperability and allows consumers to process and exchange their documents with the software product of their choice.
In other words, the proof will be in the pudding. And I hope the Commission will also zero in on who is allowed in the kitchen.