Re: [oiic-formation-discuss] Caution and Disclaimer on Interoperability

[marbux <marbux@gmail.com>]

On Wed, Jun 11, 2008 at 5:20 PM,  <robert_weir@us.ibm.com> wrote:
>
> You can find many different formal definitions of interoperability.  The one
> I like most is IDABC's from their "European Interoperability Framework":
>
> "Interoperability means the ability of information and communication
> technology (ICT) systems and of the business processes they support to
> exchange data and
> to enable the sharing of information and knowledge."


It has a superficial ring to it because it includes the phrase
"business processes." However, I respectfully suggest that you run the
decision on what definition to adopt and this email past IBM counsel.
This smells like a situation where the corporate right hand is not
aware of what the corporate left hand is doing.

The definition of "interoperability" is not a matter of personal
preferences in the context of work on international standards work.
The applicable definition is set by ISO/IEC/JTC 1 Directives,  Annex
I, <http://isotc.iso.org/livelink/livelink.exe/fetch/2000/2489/186491/186605/AnnexI.html>:

"For the purpose of this policy statement, interoperability is
understood to be the ability of two or more IT systems to exchange
information at one or more standardised interfaces and to make mutual
use of the information that has been exchanged.  An IT system is a set
of IT resources providing services at one or more interfaces."

Moreover, your own company through ECIS litigated a near identical
definition to a successful conclusion in Commission v. Microsoft. See
Court of First Instance Judgment,
<http://curia.europa.eu/jurisp/cgi-bin/gettext.pl?where=&lang=en&num=79929082T19040201&doc=T&ouvert=T&seance=ARRET>,
paragraphs 225 and 226:

"Next, the Court finds that the concept of interoperability employed
in the contested decision – according to which interoperability
between two software products means the capacity for them to exchange
information and to use that information mutually in order to allow
each of those software products to function in all the ways envisaged
– is consistent with that envisaged in Directive 91/250.

"Thus, as the Commission explains at recitals 752 to 754 and 759 and
760 to the contested decision, the 10th recital to Directive 91/250 –
whether in the English or the French version – does not lend itself to
the 'one-way' interpretation advocated by Microsoft. On the contrary,
as the Commission quite correctly emphasises at recital 758 to the
contested decision, the 10th recital to Directive 91/250 clearly shows
that, by nature, interoperability implies a 'two-way' relationship in
that it states that 'the function of a computer program is to
communicate and work together with other components of a computer
system'. *Likewise, the 12th recital to Directive 91/250 defines
interoperability as 'the ability to exchange information and mutually
to use the information which has been exchanged'."*

See Directive 91/250 at
<http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:EN:HTML>.

The Court of First Instance held that the specificity of the
interoperability information Microsoft must disclose is that necessary
to put Microsoft competitors on an "equal footing" with Microsoft's
own software in terms of quality of interoperability. See Judgment,
supra, paragraph 374:

"The Court has already defined, at paragraphs 207 to 245 above, the
degree of interoperability which the Commission required in the
contested decision. The Court observed, in particular, that the
Commission had concluded that, in order to be able to compete viably
with Windows work group server operating systems, competitors'
operating systems must be able to interoperate with the Windows domain
architecture *on an equal footing* with those Windows systems (see
paragraph 230 above)."

The Court also upheld the portion of the Commission's order setting
forth the remedy, including (paragraph 47):

"Furthermore, the first paragraph of Article 4 of the contested
decision requires that Microsoft bring an end to the infringement
referred to in Article 2, in accordance with Articles 5 and 6 of that
decision. *Microsoft must also refrain from repeating any act or
conduct that might have the same or equivalent object or effect to
those abuses (second paragraph of Article 4 of the contested
decision)."*

Microsoft is now legally bound to the definition and explanation of
interoperability asserted against it in the Commission v. Microsoft
litigation to the extent that "any act or conduct ... might have the
same or equivalent object or effect to those abuses."

Even before the Court of First Instance ruling, IBM through ECIS filed
a complaint with DG Competition that Microsoft had violated the
previous order by engaging in conduct with same or equivalent effect
to the prior abuses in regard to, inter alia, withholding  the
specifications for the MS Office binary formats, by seeking to
undermine the ODF international standard by seeking international
standard status for its own XML formats, and by refusing to provide
native file support for the existing international standard ODF.

In response, DG Competiton commenced an informal antitrust
investigation of Microsoft's conduct, which has now proceeded to the
point of a formal investigation, with your company's continued
participation through ECIS.

Microsoft has now committed to providing native ODF v. 1.1 support in
Office 2007 and has joined the ODF TC to participate in development of
ODF v. 1.2.  In that regard, DG Competition Commissioner Neelie Kroes
on Tuesday provided guidance and cautioned that DG Competition will be
watching how vendors behave in the standardization effort now under
way on the ODF TC:

"First, we should only standardise when there are demonstrable
benefits, and we should not rush to standardise on a particular
technology too early.

"Second, I fail to see the interest of customers in including
proprietary technology in standards when there are no clear and
demonstrable benefits over non-proprietary alternatives.

"Third, standardisation agreements should be based on the merits of
the technologies involved. Allowing companies to sit around a table
and agree [on] technical developments for their industry is not
something that the competition rules would usually allow. *So when it
is allowed we have to look carefully at how it is done.*

"If voting in the standard-setting context is influenced less by the
technical merits of the technology but rather by side agreements,
inducements, package deals, reciprocal agreements, or commercial
pressure ... "then these risk falling foul of the competition rules.""

Under the circumstances, and speaking as a retired lawyer with
substantial experience in major litigation, IBM -- the corporate
entity -- would have to have rocks in its corporate head if it
deviated in its ODF interoperability work from the definition of
interoperability  IBM fought for and won in the Court of First
Instance, particularly with Microsoft now seated at the ODF TC
bargaining table. IBM and other participants in the Commission v.
Microsoft proceedings accomplished a landmark decision on
interoperability in the IT sector, a victory so compelling that
MIcrosoft took no appeal from the Court's decision.

If IBM now retreats from that victory to a more permissive definition
of "interoperability" -- which is in effect what you suggest, as
discussed below --     IBM cripples DG Competition from coming to
IBM's assistance should Microsoft commit relevant abuses in the ODF
interoperability work. Legal defenses become available to Microsoft
such as estoppel and involuntary waiver of rights through conduct
inconsistent with later assertion of the right.

Moreover, if this TC departs from the JTC 1 definition of
interoperability --  which is in complete harmony with the Court of
First Instance's ruling, IBM simply creates legal grounds for
challenging this TC's profile work at JTC 1.

Should IBM push the IDABC definition on this proposed TC, all that is
accomplished is to introduce ambiguity where none exists in the JTC 1
definition. For example, your preferred definition introduces
ambiguity by using different terms for what is the same term used
twice in the JTC 1 definition, "information." The IDABC definition in
contrast uses "data" in the first grammatically equivalent position
but in the next uses "sharing of information and knowledge"

This may not seem like a big issue to a non-lawyer. But fortunes have
been won and lost on such issues. While law is far more ambiguous than
software code, it is not without meaning. The placement of a comma, a
careless substitution of a synonym for a term used elsewhere, and the
like are all common grounds of decision in an adjudicative setting.
Contract and administrative law cases, for example, are very commonly
decided based on a court's selection between warring interpretations
of ambiguous language. If one checks the first volume of West's Words
& Phrases, one quickly learns that "and" is rarely a a hard-coded
Boolean value in the law. There are page after page of citations to
cases where "and" was held to be either conjunctive or disjunctive in
particular contexts. I.e., in law, "and" sometimes means "or" and vice
versa.

I will be frank. IDABC's definition of "interoperability" is sloppy
draftsmanship in terms of interpretation or enforcement. It is
ambiguous. One might suspect that it was not drafted by a lawyer or
was drafted by a lawyer in another language before being translated
poorly to English. The relevant canon of grammatical interpretation
commonly enforced by the courts is that when different terms are used
in language being interpreted, the differing terms are to be given
separate meaning and effect unless it is absurd to do so. Not
uncommonly, a court will decide close cases by applying a rebuttal
presumption to that effect, which shifts the burdens of of proof and
persuasion to the proponent of the position that the non-identical
terms have identical meanings, then finding that the presumption has
not been adequately rebutted.

In that regard, the IDABC definition of "interoperability" states that
"data" must be exchanged, and "information and knowledge" must be
shared.The careful reader is immediately alerted that that "data" and
"information and knowledge" likely have different meanings. So in this
situation, there is danger a court would determine that because
different terms were used, a different meaning was intended in the two
positions in the IDABC sentence.

It is precisely because of these kinds of issues that lawyers spend
countless hours researching for precedents from which they can extract
language that has already been given further defintion. For example, a
legislative report accompanying a bill later enacted into law may
remove a court's doubts about the intended meaning of a clause or
phrase in a statue. A prior court decision may have already
interpreted particular language in a contract. The recitals in a
Directive may shed meaning on its normative portions.

A lot of legal writing, e.g., a contract, is typically hard to read
for laymen precisely because the work has been carefully researched.
Typically,. competent contracts are largely a cut and paste job
cobbled together from different precedents that give the chosen
terminology further definition. If the contract winds up in a later
dispute, the lawyer need only reach the research file for the
precedents that may resolve the dispute.

Indeed, I've matched wits with many lawyers who thought it was fair
play to try to slip language into an agreement that is misleading
because there is a precedent lurking that seemingly turns a clause on
its head.  It is for such reasons that specialization in areas of the
law has become so important; lawyers must be familiar with a
particular area of the law to be able to efficiently spot the wookies
that are routinely thrown their way by the other side.  I had trust
issues with attorneys who behave that way, but there is no shortage of
them.

If one applies the canon of gramatical interpretation mentioned above,
the presumption that a court would likely apply is that the IDABC's
"data" and "information and knowledge" are not synonyms, that they are
not co-extensive, because the drafter's different words must be given
different meaning and effect unless doing so would create an absurd
result. Now let's take another look at the entire IDABC definition
that you quoted:

"Interoperability means the ability of information and communication
technology (ICT) systems and of the business processes they support to
exchange data and to enable the sharing of information and knowledge."

From a technical standpoint, try to make sense of that sentence if
"data" and "information and knowledge" are not co-extensive. Have you
found any loophole yet?

Only one of several I see is that: the sentence can be interpreted to
mean that my implementation can send your implementation markup that
yours cannot recognize so long as the interop is good enough that
*some" undefined level of "information and knowledge" can be gleaned
by by my app.

E.g., I send you a MarbuxWiter ODT with nothing but OOXML markup in
the marbux-writer namespace, no ODF-defined markup in the whole
document. Under the ODF conformance section, this is still a
conforming ODT document. You open the document in OOWriter, it strips
all the foreign elements and attributes except paragraphs and text
spans and renders the document as plain text. You edit the document
and send it back to me, I open it in MarbuxWriter, which likewise
strips all of the OOWriter-unique foreign elements and attributes
other than paragraphs and text spans and renders the content of the
unrecognized markup as plain text.

Where's your grounds for disagreement in the IDABC definition? I can't
see anything in it that unambiguously sets the quality of the interop
that must be achieved.

A definition that invites disagreement over its meaning invites
litigation. A definition that leaves no room for disagreement over its
meaning at least forces someone to find a different topic to disagree
on.

You might ask yourself how many years the Microsoft lawyers were able
to delay disclosure of the Windows and Windows Server protocol
specifications with the argument that the quality of
"interoperability" enabled by its disclosed specifications could not
be defined with specificity because interoperability there were
degrees of interoperability, another argument that the Court of First
Instance shot down. More years than you might think. Microsoft's
lawyers used that argument successfully in U.S. v. Microsoft in
defense of the consent decree that finally resolved that litigation.
The District Court sided with Microsoft on that issue and the
Massachusetts appeal of that ruling was rejected by the Court of
Appeals.

But DG Competition learned from the U.S. experience and its "equal
footing" interop ruling upheld by the Court of First Instance provided
a testable legal standard for the quality of the interoperability that
must be enabled by Microsoft disclosures of its communications
protocol specifications. Because the "equal footing" ruling in Europe
is firmly grounded in competition law and is far more consistent with
U.S. antitrust law than the U.S. v. Microsoft ruling, I think it very
likely that the same standard would be adopted by U.S. courts faced
with the same legal issue again.

The JTC 1 and Court of First instance definitions could be used as
evidence to show that IDABC or this proposed TC's charter could have
said so if they wished to impose an interoperability quality
requirement. In those two far more carefully vetted definitions,
identical occurrences of the same term "information" in two successive
prepositional phrases indicates that the meaning intended is identical
in both occurrences. E.g., from the JTC 1 version:

:... to exchange *information* at one or more standardised interfaces
and to make mutual use of *the information* that has been exchanged."

Further confidence that the two occurrences of "information" in the
JTC 1 definition have a co-extensive meaning is provided by the
article "the" preceding the second use of "information," indicating
grammatically that the second occurrence of "information" refers back
to the preceding use of the same term, that the two instances of
"information" have the same meaning in both places.  Still more
confidence comes from the echoing of "exchange" in the first
prepositional phrase with "exchanged" in the second. It would be like
swimming up a waterfall to argue that the two instances of
"information" do not have identical meaning. .

The result of the grammatical construct indicating co-extensive
meanings for the two occurrences of "information"  introduces a
qualititive aspect to the interoperability required by the definition.
The careful repetition of the same terms ("information" and
"exchange") thus indicates that the quality of the information
exchanged is identical to the quality of the "mutual use" of the same
information, a requirement of interoperability on an equal footing at
both ends of the round trip.

There is no ambiguity in the JTC 1 or Court of First Instance
definitions remotely equivalent to the multiple ambiguities of the
IDABC definition. The former are clear and testable. The latter is a
grammatical rat's nest, an invitation to litigate.

The only problems I have unearthed with the JTC 1 and Court of First
Instance definitions after very considerable research is that one must
be a grammarian to parse them when read in isolation from their
context. I have attempted to synthesize a definition from them and
their context that is more understandable to more people, in the first
published draft of the Universally Interoperable and Accessible
Specification "UIAS"), using three interrelated definitions but
extending them from IT systems (the phrase used in the JTC 1
Directives) to ICT systems.  The definitions are in their defined
terms' alphabetical order.

"Application-level interoperability
    "Interoperability among information and communications technology
("ICT") systems established through means other than by adherance to a
full specification, e.g., where knowledge about another ICT system's
interface for a given exchange of information is not fully and
publicly specified and such information must be obtained through
collaboration among developers or through non-collaborative techniques
such as litigation, legislation, or reverse engineering.

"Information and communications technology ("ICT") system
   "A set of information and communications technology ("ICT")
resources providing services at one or more interfaces.

"Interoperability
    "The ability of ICT systems to exchange information at one or more
standardized interfaces and to make equal mutual use of the
information that has been exchanged, without differences in use
attributable to inadequacies in technical regulations, standards, or
technical specifications. ICT systems that achieve interoperability
are said to be interoperable. Throughout this document,
interoperability shall be interpreted to exclude application-level
interoperability except as expressly indicated."

(footnotes with citations and commentary omitted).
<http://www.universal-interop-council.org/specification>.

(The UAIS is an ongoing legal research and writing project to develop
a candidate successor to the various existing definitions of an "open
standard," primarily because of their conflicts with the law governing
interoperability in ICT standards work.)

Rob, if you intend to push the IDABC definition (and I do not know
whether that is your plan), you should do so with your eyes wide open.
I respectufully urge you to consult with corporate counsel before you
turn your back on the Court of First Instance decision by urging the
adoption of any definition of "interoperability" more lax and
ambiguous than the definition upheld by the Court of First Instance.

[more]

> I know that many on this discussion list are interested in the visual kind
> of interoperability, and there is indeed progress that can be made here.
>  However, I think that our proposed TC charter should be broad enough to
> encompass the full panoply of relevant ODF interoperability initiatives.  In
> particular, there has been a lot of hallway talk at conferences and in
> casual encounters about ODF/DITA interoperability.  In other words,
> interoperability between two standards.

To the extent that accessibility or programmatic parsing, extraction,
and transformations to other formats might be impaired by ODF visual
interop features, the foregone advantages far outweigh visual interop
on my set of scales. Flexible recycling of information is a far more
critical market requirement to be fulfilled by ODF than visual
interop, with PDF the relevant international standard for the latter.
I have no issues with improving the ODF presentation layer until it it
gets in the way of flexible content recycling.

Best regards,

Paul E. Merrell, J.D.  (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>