08.05.08
Reminder: OOXML Still Seems Free Software-Hostile
Several months ago, thanks to the SFLC it was shown that OOXML is not suitable for implementation by Microsoft's #1 competitor. A solicitor specialising in Free/open source software, Brendan Scott, has taken a look at Microsoft’s reassurances and formal licence, but he is not convinced much has changed. Loose ends remain in the OOXML OSP.
One of the reasons that the GPL ignorance line was trotted out for so long might have been concern over the the SFLC’s criticism of the OSP. To put it in simple terms, the OSP does not travel with the code. So writing a (eg) GPL* implementation of an OSP covered specification in the expectation that the code may be re-used for other things (which is a cornerstone of interactions in the free software community) creates a problem. That code becomes encumbered by a patent mine which arms itself when the code is (non-conformingly) reused. At best, even with this addition to the FAQ, the OSP still fails to respect the freedom of free software implementations (whether GPL or otherwise) of covered specifications.** It is unclear, for example, what effect the “no surrender of others’ freedom” clauses of the relevant GPLs would be in the event of a successful patent action against a non-conforming implementation.
Here is another good article about bad OOXML. The headline, which poses a question, is overly optimistic, but the body is a concise and accurate summary of recent developments.
Is Microsoft’s Office Open XML a functional standard, and if not, why is it being rushed through the process?
Microsoft’s problems with OOXML just won’t go away. MS-OOXML was supposed to supplant the Open Document Format (ODF), but is becoming an embarrassment. As a format it betrays its hurried origins, and is over-complex. At best, it has technical problems. At worst, it is barely fit for purpose.
Questions are being asked in Europe about the way that Microsoft went about the standardisation process. At least four countries have succeeded in having their objections raised to the fast-tracking of OOXML through the International Standards Organisation (ISO), and as a consequence, the ISO has put the standard on hold, at least for the time being.
Microsoft has no date for implementing OOXML on its own platform, but has agreed to implement the rival ODF format on Microsoft Office. Microsoft has given its blessings to ODF by joining the OASIS committees, and to cap it all, a senior Microsoft spokesman has conceded that “ODF has clearly won”.
Clearly, there is a pressing need for an open standard for document formats. Documents that can be shared across platforms, across products, and across time. The solution to the problem is ODF, which was created by a technical committee of the OASIS industry consortium and has benefited from industry wide participation in its development. ODF gained acceptance as an ISO standard in May 2006.
Some time this month, having already coped with leaks, ISO will probably confirm that it has lost its dignity by permitting itself to be exploited by Microsoft for self benefit. █
Jose_X said,
August 5, 2008 at 10:36 pm
OOXML is such a waste of time. Anything anyone wants can be done with some other formats. [Eg, extend ODF and then submit the extensions to OASIS for standardization; use the ODF TC mailing list. This is MUCH more efficient than reimplementing a different looking set of (crooked) wheels.]
[In addition to the patent issue described in this article/post above..] We know the technical mess and reinvention of the wheel that is OOXML, but as concerns patents, real patent traps will lie with MS-OOXML, and since this will not be unextended correct OOXML (currently, “correct” is meaningless), you will have no patent protections if you actually reverse engineer MS-OOXML in order to interoperate. Of course, attempting to interoperate with MSO is an interminable rat race that starts you and keeps you permanently in the tail position of that race. [OOXML will give way to XOXOML (TM) and then to something else, etc, each of which will be based on the closed patented extensions from earlier generations.]
The way forward should be to continue to grow an ecosystem of interoperable ODF (and other good standards) products. Good interesting products in large numbers that interoperate with each other NEED NOT interoperate specifically with MSO or other Monopolyware. If these products truly are good (many will be FOSS), consumers will see the value of moving over to these products. At some point they will know not to use MSO or will revert to older versions that can be understood mostly by Openoffice filters. Meanwhile antitrust authorities should force Monopolysoft to meet the ODF spec as much as possible. Us, rather than to go run Monopolysoft’s rat race, should instead complain to authorities about their brokenness.
I think this is the smartest path forward. Recap: ignore OOXML and MSOOXML in order to save LOTS of time to be spent instead on ODF (in practice, Sun probably won’t do this, but it’s their business how they spend their bucks). Work aggressively to grow ODF apps and documents that interoperate. Sell ODF and the apps to people.
Oh, and one more thing. OASIS should have an *official* path to determine if docs meet ODF requirements without the use of extensions. This way buyers can demand this. Otherwise, there will be confusion because today almost anything will qualify as an ODF conforming document (see ODF 1.1). You can’t separate the wheat from the chaff if you don’t have a trustworthy way to identify these parts.
Good luck.
Jose_X said,
August 5, 2008 at 11:16 pm
I should have added to earlier comment that I think a lot of ODF proponents are (and have been) working with goals similar to what was described above. [Obviously, Novell is not one of these, as they insist on trying to legitimize OOXML and other technologies that put the ball in Monopolysoft's court. It's their time and Monopolysoft's dollar, so I guess that's their business.]
An important situation with ODF extensions is how do you allow the positives of extensions while defending against the abuses of extensions? Some of the larger corp backers of ODF have leaned towards being lenient. This reminds me of ISO. It’s a bit informal among friends and everything mostly works until Monopolysoft shows up and exploits everything possible to game the system. Will we wait to toughen ODF until after Monopolysoft has done its number on it? Surely, they can and will extend ODF. This will create “ODF” files in large numbers that only work with MSO and those apps that license MSO libraries. These numbers can be overwhelming and hence become the de facto ODF. All may work out, nevertheless, if the case is successfully made to antitrust authorities that the extension mechanisms are being leveraged illegally by Monopolysoft.
We’ll see, but if ODF is not carefully worded ahead of time, we’ll hear the old “good for goose .. gander” song. It might be enough, however, to point out that Monopolysoft is neither a goose nor a gander but a monopolist. We’ll see.
Roy Schestowitz said,
August 5, 2008 at 11:51 pm
It’s unfortunate that Novell signed this deal in the first place. It supports OOXML because it has to. It’s a binding contract. In essence, Microsoft bought OOXML obedience from Novell.
Stephane Rodriguez said,
August 6, 2008 at 5:41 am
What is key is to ensure that ODF interoperates at the application level with as many applications as possible, including applications from Microsoft.
Microsoft, on the other hand, is ensuring that not only it won’t work on application-level interoperability regarding ODF, but also according to reports from their “ODF workshop” they held in Redmond last week, they are botching an ODF implementation to ensure everyone touching it will have a miserable life. Two examples : 1) they remove formulas from spreadsheets. I wonder how good is a spreadsheet without its formulas. 2) they add many dialog boxes to warn or ask the user, making reading/writing ODF extremely painful for users.
This is all written on the wall already.
Roy Schestowitz said,
August 6, 2008 at 5:53 am
They only need the “supports ODF” footnote (no matter the quality and version… 1.0) on the box and brochure. They make it harder for technical people to justify defection away from MSO.