[odf-discuss] Sun's OpenDocument filter for MS office released

[marbux]

On 7/7/07, Lars Noodén <lars at umich.edu> wrote:
>
> marbux wrote:
> > They are a poor target for interoperability in any event because there
> are
> > so many versions,
>
> Yes.  However, much of the hot air from the MS boosters has been about
> the mounds of legacy documents in those many versions of formats.
>
> The conversations and debates quickly get steered away from the point
> that being able to read the mounds of legacy documents does not require
> MOOX, MS Office, left-handed spoke shifters, and ST-1 module or any
> other expensive and shoddy tools.  It needs the details of the formats.


On the details of the native file support APIs, preferably both.

> ... might be more productive to push for full specification of those
> > APIs and their manipulation. (Microsoft is already required to do so
> > by the U.S. v. MIcrosoft consent decree.)  Those APIs are a far simpler
> > and more stable target for interoperability development.
>
> The consent decree may be the most strategically valuable bit of
> information to turn up in this thread or even whole set of threads.
>
> However, I have to ask if you meant specification or API?  Does the
> consent decree refer to publishing the *specification* for the data
> format or only to the *APIs* which are tied into MS Office and/or MS
> Windows?  The former is very useful, the latter is worse than useless.


There is a more than reasonable argument that that it includes both. I'll
try to explain, with a caveat that the consent decree is convulated and not
a model of clarity. There is a copy of the official version here, <
http://www.usdoj.gov/atr/cases/f200400/200457.htm>. There is on the district
court web site another document identified as the consent decree, but court
staff goofed and posted the last draft that the court rejected instead of
the final consent decree. I've written to them about it, but they've never
fixed it, or at least hadn't the last time I checked. Also note below that
Gmail is insisting on mis-numbering some parts of the outline structure. So
please refer to the original for citations to specific paragraph numbers.

It basically turns on whether the file format specifications are
documentation "related" to the Office native file support APIs and/or any
API provided as part of Windows client or server. Perhaps the easiest way to
keep your eye on the bouncing ball is to keep in mind that Office 2007 uses
a host of undocumented APIs located in Windows and on the middleware server
side, e.g., Sharepoint Server. The documentation for that fact is the
supplemental expert report of Andrew Shulman, which can be downloaded from
the Groklaw Comes v. Microsoft page.

The operative sections are III(D) and (E):

D. Starting at the earlier of the release of Service Pack 1 for Windows XP
or 12 months after the submission of this Final Judgment to the Court,
Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole
purpose of interoperating with a Windows Operating System Product, via the
Microsoft Developer Network ("MSDN") or similar mechanisms, the APIs and
related Documentation that are used by Microsoft Middleware to interoperate
with a Windows Operating System Product. For purposes of this Section
III.D,the term APIs means the interfaces, including any associated
callback
interfaces, that Microsoft Middleware running on a Windows Operating System
Product uses to call upon that Windows Operating System Product in order to
obtain any services from that Windows Operating System Product. In the case
of a new major version of Microsoft Middleware, the disclosures required by
this Section III.D shall occur no later than the last major beta test
release of that Microsoft Middleware. In the case of a new version of a
Windows Operating System Product, the obligations imposed by this Section
III.D shall occur in a Timely Manner.

E. Starting nine months after the submission of this proposed Final Judgment
to the Court, Microsoft shall make available for use by third parties, for
the sole purpose of interoperating or communicating with a Windows Operating
System Product, on reasonable and non-discriminatory terms (consistent with
Section III.I), any Communications Protocol that is, on or after the date
this Final Judgment is submitted to the Court, (i) implemented in a Windows
Operating System Product installed on a client computer, and (ii) used to
interoperate, or communicate, natively (*i.e.*, without the addition of
software code to the client operating system product) with a Microsoft
server operating system product.

Under section VI, you'll find, inter alia, these supplemental definitions:

A. "API" means application programming interface, including any interface
that Microsoft is obligated to disclose pursuant to III.D [quoted above].

E. "Documentation" means all information regarding the identification and
means of using APIs that a person of ordinary skill in the art requires to
make effective use of those APIs. Such information shall be of the sort and
to the level of specificity, precision and detail that Microsoft customarily
provides for APIs it documents in the Microsoft Developer Network ("MSDN").

J. Microsoft Middleware" means software code that

   1. Microsoft distributes separately from a Windows Operating System
      Product to update that Windows Operating System Product;
      2. is Trademarked or is marketed by Microsoft as a major version
      of any Microsoft Middleware Product defined in section VI.K.1;
      and
      3. provides the same or substantially similar functionality as*
      *a Microsoft Middleware Product.

 Microsoft Middleware shall include at least the software code that controls
most or all of the user interface elements of that Microsoft Middleware.

Software code described as part of, and distributed separately to update, a
Microsoft Middleware Product shall not be deemed Microsoft Middleware unless
identified as a new major version of that Microsoft Middleware Product. A
major version shall be identified by a whole number or by a number with just
a single digit to the right of the decimal point.
K. "Microsoft Middleware Product" means

   1. the functionality provided by Internet Explorer, Microsoft's Java
      Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express
      and their successors in a Windows Operating System Product, and
      2. for any functionality that is first licensed, distributed or
      sold by Microsoft after the entry of this Final Judgment and
that is part of
      any Windows Operating System Product
      1. Internet browsers, email client software, networked
         audio/video client software, instant messaging software or
      1. functionality provided by Microsoft software that --
            1. is, or in the year preceding the commercial
            release of any new Windows Operating System Product was,
distributed
            separately by Microsoft (or by an entity acquired by
Microsoft) from a
            Windows Operating System Product;
            2. is similar to the functionality provided by a
            Non-Microsoft Middleware Product; and
            3. is Trademarked.

Functionality that Microsoft describes or markets as being part of a
Microsoft Middleware Product (such as a service pack, upgrade, or bug fix
for Internet Explorer), or that is a version of a Microsoft Middleware
Product (such as Internet Explorer 5.5), shall be considered to be part of
that Microsoft Middleware Product.
If you've really kept your eye on the bouncing ball, while reading
definitions J and K, you've probably realized why Microsoft said it was
offering Sharepoint Server as a separate download "for antitrust reasons."
But in my analysis, that wasn't enough given that Sharepoint Server, the web
apps running atop it, MSIE, and Microsoft Office all call on APIs located in
the Windows client and server operating systems, see section (III)(D) and
interoperate via MOOXML (see "communications protocol" disclosure
requirement in section (III)(E).  And that is in my opinion a plausible
explanation of why Microsoft kept those APIs secret, in direct defiance of
the consent decree.

And I suspect that these days Microsoft's lawyers are still kicking
themselves over the presence of "or" in definition (III)(J)(2) and wishing
they could go back and change it into an "and."

But to put an end to this misery, I think it boils down to whether
specification of the formats falls within the definition of "APIs and
related Documentation" as used in paragraph III(D), keeping the APIs for
adding native file support in mind. And in definition (VI)(e) we find
further definition of what "related Documentation" means: "all information
regarding the identification and means of using APIs that a person of
ordinary skill in the art requires to make effective use of those APIs."

Could a person of ordinary skill in the art effectively make use of those
native file support APIs without specification of the file formats used
internally by Microsoft Office, or those converted using the APIs such as
MOOXML? I would argue not.

This isn't to say that reasonable arguments couldn't be made for the
contrary position and given judge Kollar-Kotelly's attitude exhibited in
that case as well as the court of appeals, I couldn't say with any
confidence that the argument sketched above would be a winner.
Massachusetts challenged  the lack of definition for "interoperability" in
regard to the disclosure requirements, and she parroted back the
Microsoft-DoJ argument that no definition was needed because there were
degrees of interoperability. Even though that argument seemed to merely
confirm the Massachusetts complaint, the judge bought into it and the court
of appeals upheld it. And I'm still highly disturbed by her allowing
Microsoft to impose RAND terms on any of its disclosures  despite having not
offered a whit of evidence that it held any relevant IP rights. I could only
speculate as to her motives, but in my opinion she fell way far short of her
duty to protect the public interest in approving that consent decree.

> I also think it likely that Microsoft will eliminate the ability for
> Office
> > users to write to the binary formats in the next version or two, making
> > them import-only ...
>
> Agreed, though I would posit that the goal there is not
> interoperability, but simple to advance lock-in via MOOX / Sharepoint /
> Infopath. It's the old roach-motel method.  Data goes in but can't get
> out.


Definitely. Microsoft isn't going to change its spots so long as they are
profitable, unless some court decides to actually create an effective
remedy.


All the debate about whether OpenDocument or MOOX or Ecma 376 support or
> don't support MS' zoo of legacy formats can be dropped if the
> specifications become available.



Don't hold your breath. It there's one message Microsoft has delivered
effectively in both the U.S.and European antitrust cases is that they will
not be made to obey  in letter or spirit disclosure orders by mere
governments. What's needed is either breaking up the company, ordering them
to divest products, or slapping executives in prison, any of which can be
done under the criminal provisions of the Sherman Act's sections 1 and 2. <
http://caselaw.lp.findlaw.com/casecode/uscodes/15/chapters/1/toc.html> (up
to 3-year prison terms per violation). The judge also has the power to order
executives jailed in contempt of court proceedings. But I don't foresee the
current Administration seeking that remedy. I don't know if Europe has
similar criminal statutes, but do know DG Competition has authority to force
divestiture or to break up companies.

I have seen some very powerful people suddenly acquire interest in more than
fully obeying court orders when a federal judge issues an order to show
cause why they should not be held in contempt and jailed. E.g., I recall one
incident when one of our Oregon federal judges ordered the U.S. Secretaries
of Agriculture and the Interior to appear personally and show cause why they
should not be held in contempt and jailed because they were ignoring an
environmental injunction. Attitudes changed immediately.

Of course it hadn't helped any that the Washington, D.C. Dept. of Justice
lawyer assigned to the case had just been quoted in the press as saying
something like, "Oh, he's just a judge out in the hinterlands; we don't have
to worry about what he says." I personally attended the next hearing in that
case to watch what the judge said to her. He asked her some hard questions
about whether she thought he had less power than any other federal district
judge and why, then announced his show-cause order against the cabinet
secretaries. And that was the last time that lawyer was seen in Oregon. :-)
I wasn't troubled in the least because she had played rather fast and loose
with the rules in one of my cases previously. In fact the gallery was mostly
filled with other lawyers who had had to put up with her misbehaviors and we
held a minor celebration afterward, whilst contacting every media person we
could dredge up.

Such moments do occur. Maybe I will live long enough to see it happen to
some Microsoft management types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070707/9faf2fa8/attachment-0001.html