[odf-discuss] Private deal to approve OOXML? More evidence surfaces

[Ian Lynch]

> Having achieved international standardization for OOXML, Microsoft now
> has a legal argument that its software cannot be legally disqualified
> as a national technical regulation or a government procurement
> specification on legal grounds that its formats are not an
> international standard.

But how can that possibly stand up if the application doesn't support
the standard? It's like putting forward MS Works for a tender that
mandates compatibility with MS Office. MS Works does not support MS
Office formats sufficiently to be of practical use. Just because it's MS
doesn't mean anything. The only governments I can see falling for this
are governments that would have ignored the ISO issue in any case. Let's
face it, few governments have completely displaced .doc with odf yet and
it would take a long time to do so whatever happened with OOXML. Those
that really understand the issue will say ok we'll consider your OOXML
compliant products alongside odf products. Then any objective comparison
is going to eliminate OOXML if there is no practical means of producing
and editing such files.

> As to government procurement specifications, Microsoft gains an
> argument that governments cannot legally specify only ODF as a
> procurement specification.

They can if it's the only one that can practically do the job. Even if
they specify both, they can reasonably put in the tender. "At least one
application provided must fully comply with ISO 26300 or ISO (OOXML)."


>  I think it is a weak argument legally,
> particularly since both treaties are intended to eliminate duplicative
> but incompatible standards/specifications rather than to create
> interoperability barriers, but it's a colorable argument.

I see this as a great opportunity for odf. "In head to head choice
between OOXML compliant products and odf compliant products, government
chose odf 100%" Since there is no practical implementation of OOXML who
would ever be able to procure a product based on it?

Great marketing opportunity for odf.

> With that background, we are down to the issues you raise. The reason
> Microsoft's argument is colorable is because like OOOXML, ODF is not
> designed for interoperability. As with OOXML, there are no full
> featured implementing editors available that write to the
> international standard without application-specific extensions. E.g.,
> if you want to save a file to ISO/IEC:26300-2006 in OOo or Lotus
> Symphony, you will find no option to do so in the file save dialogs.
> The heavyweight ODF editors are all writing to  ODF 1.2 plus
> app-specific extensions without any user ability to write to
> unextended ISO/IEC:26300.
> 
> If you want ODF apps that interoperate without data lossiness,
> everyone has to use the same app and version. This is why the real ODF
> standard is the OOo code base, not what it says in the ODF "standard."
> The only way ODF achieves a somewhat valid claim of "multi-vendor"
> interoperability is through the various clones of the OOo code base
> such as Star Office, Novell OOo, and Lotus Symphony. Coupled with Sun
> Microsystem's iron-clad grip on commit rights to the OOo code base and
> OOo's market share, what full ODF support and interoperability means
> is really defined by a single vendor, Sun Microsystems.

Well to me that is certainly the lesser of the evils and probably
unavoidable at present. At least I can download OOo for free and use it
on my Linux box. Anyone with the resources can fork the project if they
really want to have their own versions a s Novel, and IBM have done. And
if I want to procure a fully ISO standard editor for my country I can
without having to pay a license fee.

> The fact that ODF is not a standard that enables or requires
> interoperability in order to be conformant is what gives Microsoft's
> procurement argument whatever teeth.it has. From a technical
> standpoint, ODF can claim no higher ground than OOXML when it comes to
> interoperability save for the IPR legal barriers to interoperability.

And the fact there are some actual applications that implement it and
have been tested widely to show they comply with the standard - even if
these are all based on the OOo code base, it's still an advantage in
practical terms to a standard that has not one single application that
fully implements the specification. If the latest MSO fully implemented
OOXML there would at least be an argument. In these things it's like a
three legged stool. Practical technical implementation, ISO status, IPR
barriers are all relevant. Take one leg away and the stool falls over.

> So with international standard status for OOXML, Microsoft now has a
> fairly powerful argument that interoperability of ODF implementations
> is not a factor that can validly be claimed as an ODF advantage. I.e.,
> for an ODF vendor to argue in a procurement tender process that OOXML
> does not enable interoperability gets answered by a "pot calling the
> kettle black" response.

So just say yeah but there is no practical application supporting the
OOXML standard so we eliminate it on those grounds. A smart salesman
chooses arguments they will win, not old arguments that might not now be
relevant to closing the sale.

> Neither standard has valid conformity assessment procedures, largely
> because both "standards" are pretty much a blank check for
> implementing developers to do whatever they want. There is no concrete
> reference point in either standard that implementing developers could
> claim conformance to. Likewise, procuring entities have no ability to
> confirm that implementations of either "standard" conform to the
> "standard." There is no standard product specified in either
> "standard."

In that case why did MS make such a complex standard? It would have been
far easier to get the same result with a minimal spec. if all they want
is the symbolism of having an ISO number with no intention of a
practical implementation, why not just make it as simple as needed to
get it through? In fact that would have made it more likely to get
through.

> So in the final analysis, it's one non-standard standard pitted
> against another non-standard standard. Both have advantages and
> disadvantages. But neither offer the advantage of interoperability or
> leveling of the competitive playing field.

I disagree.  odf might not be perfect but it does level the playing
field. It is a hell of a lot better than a specification that will never
be implemented or one that has secret code structures only known to one
vested interest. 

> Both are vendor lock-in
> "standards." 

Hardly the same. I can't see how odf actually locks anyone into Sun in
the same way as say .doc locks people into MS. IBM and Novell already
have OOo versions that are interoperable with the core community code
and Star Office so it's not locked into a single vendor. If OOXML was
implemented in a MS product and made available to others it's arguably a
step forward from .doc. I think there are degrees of bad here and odf is
a lot less bad than .doc so lumping all vendor interests as "Lock-in" is
far too simplistic.

> Neither should have been adopted as a standard. Both
> violate well-established antitrust law.

Without getting bogged down in all the detail, from a user point of view
I'd say odf is many times more desirable than .doc and if ISO helps
proliferate odf and kill .doc and similar secret proprietary formats I
don't really care about theoretical violations that would have to be
tested in court to be sure.

> Together, the only choice offered is a choice between evils. ODF may
> win that choice with some governments, Microsoft with others. But ODF
> no longer has the wholly undeserved status of being the only
> international standard in this market sector. I think a far better
> solution would have been to remove ODF's international standard status
> until such time as it becomes truly eligible for the legal status of
> an international standard or better yet that it never have been
> approved as an international standard before it was eligible. This
> "every vendor gets its own standard" madness really needs to come to a
> halt.

Except that the way the world is requires practical progress routes to
improvement. The question is usually not about perfection but is this
step an improvement on the previous. I believe odf is a significant step
forward when compared to .doc. odf is adoptable by any company and any
company can fork the OOo code base so it's a far leveller playing field
than with MS Office. To compare the Sun situation with the MS situation
in terms of vendor lock-in stretches the imagination. 

> And the FOSS community really needs to come to grips with the fact
> that "open" and "interoperable" are not synonyms. Microsoft is not the
> only company out there that plays fast and loose with the technology
> or the law.

Companies are in business to make money. It's in their interest to
eliminate competition and they will do whatever it takes to do that even
illegally in some cases if they think they will get away with it. There
is no doubt that Sun sees it as in its interest to have office
productivity tools that are in wide use and generally acceptable to
governments that run on their machines. In order to get to that position
given MS's stranglehold on Office productivity tools they had to do
something pretty radical. OOo was that disruptive choice. Sun benefits
from community support, the community benefits from a free productivity
suite with a published file specification that is far easier for third
parties to use for writing reliable filters. Maybe not full
interoperability, but a massive improvement for end users and tax payers
all over the world. So for me I'll settle for better not perfect. Yes
Sun is a winner out of this but then so is the community. 

Who knows at some point someone might develop software that can
automatically in real time work out any format and translate it into any
other format. In the current circumstances, we are where we are. odf is
the best hope for increased freedom in the use of office productivity
tools and can also catalyse further freedoms in other domains. We can
argue the details of degrees of interoperability but in the end what
matters is increasing freedom and lowering costs and odf does that.

Ian
-- 
New QCA Accredited IT Qualifications
www.theINGOTs.org

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.