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

[marbux]

On Fri, Apr 11, 2008 at 3:45 PM, Ian Lynch <ian.lynch at zmsl.com> wrote:
>
>  > E.g., Microsoft has always played the embrace and extend game with
>  > their own formats.
>
>  That's not really surprising since format evolution would normally add
>  to an existing specification.

Yes. I forgot to mention another part of the same game, which is not
providing forward compatibility in their software. Until recently,
Microsoft enabled only backward compatibility in its new versions of
Office.  This is where the upgrade treadmill kicks in. But the
technology for providing both forward and backward compatibility has
been well understood for many years. E.g., WordPerfect 13 can
round-trip documents with WordPerfect 6 without any loss of data.

Microsoft did put out an Office 2007 Compatibility Pack that retrofits
Office 2000, XP, and 2003 with OOXML support. That's a break with past
behavior. But I have heard no evaluation of the quality of the OOXML
support in the older versions.

[more]

>  > ISO/IEC:29500-2008 grants Microsoft permission to continue the same
>  > game in the XML context with the legal status of an international
>  > standard. They remain eligible for government procurement contracts.
>
>  This I can't see. If the EU specifies that member status must use an ISO
>  document standard, using Office 2007 won't comply unless it has
>  comprehensive support for the document standard. Just because MS has
>  some theoretical standard it doesn't mean it can be practically
>  implemented and if it isn't why would any government choose it over a
>  standard that can be practically implemented? Furthermore if there is no
>  general support for multi-vendor interoperability it's likely that the
>  EU would veto it anyway even fine MS for further anti-trust violation.
>  If a tender goes out for software that complies with ISO xxxx the first
>  thing I would do if I was managing the tender would be to check that
>  companies were putting forward products that supported ISO xxxx, not a
>  piece of paper saying they had a standard and promised to put it into
>  something some time in the future.


I didn't say that it was a sound strategy. -) But on the other hand ---

The Agreement on Technical Barriers to Trade Article 2  section 2.4 requires:

"Where technical regulations are required and relevant international
standards exist or their completion is imminent, Members shall use
them, or the relevant parts of them, as a basis for their technical
regulations except when such international standards or relevant parts
would be an ineffective or inappropriate means for the fulfilment of
the legitimate objectives pursued, for instance because of fundamental
climatic or geographical factors or fundamental technological
problems."

Similarly, the Agreement on Government Procurement requires in Article
VI section 2:

" Technical specifications prescribed by procuring entities shall,
where appropriate:

"...

"(b)       be based on international standards, where such exist;
otherwise, on national technical regulations(3), recognized national
standards(4), or building codes."

Those two provisions are the reasons Microsoft sought international
standard status for OOXML, along with the fact that many governments
were selecting ODF as their national technical regulation and as their
procurement specification in no small part because it was an
international standard or, earlier, on the road to become one. See the
"or their completion is imminent" phrase quoted above in context.

To remain legally eligible for government procurement of software,
Microsoft  had to either support ODF or to get its own private
international standard. Its managers chose the latter. Hence the
"competing standards are a Very Good Thing" Redmond battle cry .

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.

As to government procurement specifications, Microsoft gains an
argument that governments cannot legally specify only ODF as a
procurement specification. 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.

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.

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.
This is not simply an issue of app-specific extensions. It also
involves the sea of optional features in both ODF including all the
"may" and "should" options in the respective specs that mask
hard-coded "shall" programming choices actually made in the market
leading implementations. See e.g., the ODF conformance section:

"There are no rules regarding the elements and attributes that
actually have to be supported by conforming applications, except that
applications should not use foreign elements and attributes
[extensions] for features defined in the OpenDocument schema."
.
Neither OOXML nor ODF complies with the JTC 1 Directives requirement
that international standards "clearly and unambiguously specify the
interoperability conformance requirements essential to achieve the
interoperability." Neither standard specifies a uniform product and
for that reason are standards in name only.

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.

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."

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. Both are vendor lock-in
"standards." Neither should have been adopted as a standard. Both
violate well-established antitrust law.

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.

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.

Best regards,

Paul