OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [opendocument-users] New question (2): Reference implementation?

On Sun, May 17, 2009 at 4:58 PM, Cody, John (OFT)
<John.Cody@oft.state.ny.us> wrote:
> Paul:
> I am a lawyer, too.  So now you are getting to the meat of a part of my question.
> Can you kindly:  (a) point me to the definition of "reference implementation" you are using; and (b) lay out briefly how that definition controls the question and excludes any other possible interpretation (e.g. OO.org being a reference implementation for all practical purposes)?
> You keep submitting lawyerly conclusions on this listserve, but I'd like to see the irrefutable legal reasoning behind those conclusions.  It is quite possible I might have a different interpretation, if I were to see what you are relying on.

What, lawyers sometimes disagree on interpretation? :-)

I don't know of a relevant definition of "reference implementation"
that is defined by law. But governing law does forbid reference
implementations if they are controlled by one or more vendors as
opposed to being controlled by the relevant standards organization

Let's begin by determining what law applies. We have a treaty
comprehensively regulating all technical standardization and related
conformity assessment procedures throughout the territories of its
member nations. The U.S. has adopted the Agreement on Technical
Barriers to Trade ("ATBT"). Uruguay Round Trade Agreements Act, 19
U.S.C. 2503(a) and (c)(4),

"[A] treaty ratified by the United States is ... the law of this
land[.]." Zicherman v. Korean Air Lines Co., 516 U.S. 217, 226 (1996),
<http://supreme.justia.com/us/516/217/case.html>. But see 19 U.S.C.
2504(a), <http://www.law.cornell.edu/uscode/html/uscode19/usc_sec_19_00002504----000-.html>
(federal statutes other than the Uruguay Round Agreements are to
prevail where a conflict is found). On the other hand, see the
Charming Betsy rule, Restatement of the Law, Third, Foreign Relations
Law of the United States, § 114 (1987). (Where fairly possible, a
United States statute is to be construed so as not to conflict with
international law or an international agreement of the United States.)

Under the ATBT, the same specification must simultaneously serve as a
"technical regulation" and an "international standard." E.g., ATBT
article 2 section 2.4,

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

(Irrelevant exceptions omitted). See also section 2.6 (Members'
participation in developing international standards is one method of
developing technical regulations). /Footnote 1/

The ATBT whilst laying down requirements as to "international
standards," provides no definition the term. Therefore, to determine
the minimal requirements for an "international standard," we must look
to the equivalent definition of a "technical regulation."

The meaning of the "technical regulation" term has been squarely
addressed. A technical regulation must specify [i]  "any objectively
definable 'features', 'qualities', 'attributes', or other
'distinguishing mark'" [ii] of an identifiable product or group of
products [iii] only in mandatory "must" or "must not" terms. WTDS 135
EC - Asbestos, (World Trade Organization Appellate Body; 12 March
2001; HTML version), para. 66-70,
reaffirmed, WTDS 231 EC - Sardines, (World Trade Organization
Appellate Body; 26 September 2002),  DOC version, pp. 41-51,
<http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds231_e.htm>. The
counter-part in JTC 1 Directives appears at pg. 145, where the term
"interoperability" is defined in the context of requiring that
international standards specify "clearly and unambiguously the
conformity requirements that are essential to achieve the
interoperability." ISO/IEC JTC 1 Directives, (5th Ed., v. 3.0, 5 April
2007) <http://www.jtc1sc34.org/repository/0856rev.pdf>; ibid., pg. 11
(requirement is mandatory for all JTC 1 standards absent the express
dispensation of the ISO/IEC Secretaries-General, which was neither
sought nor obtained as to ODF and OOXML).

Importantly, the "products" of interest are electronic documents, not
the applications that process them.

So to arrive at the conclusion that ODF has a reference
implementation, one would need perforce to identify a mandatory
conformity requirement that so states and requires that equivalent
behavior is a condition of claiming conformity. There is no such
requirement in ODF.

I further question whether ODF might lawfully specify a reference
implementation whose name, trademark, design, and features are
directly controlled by one or more vendors rather than by the ODF TC
or JTC 1's SC 34. As discussed in the footnote below, an international
standard must also concurrently serve as a government procurement
technical specification under the Agreement on Government Procurement
("AGP"). The additional requirements for such technical specifications
should therefore be read in pari materia with the ATBT in regard to
international standards.

AGP article VI, section 3 provides:

"There shall be no requirement or reference to a particular trademark
or trade name, patent, design or type, specific origin, producer or
supplier, unless there is no sufficiently precise or intelligible way
of describing the procurement requirements and provided that words
such as “or equivalent” are included in the tender documentation.:

So specifying OpenOffice.org (a trademarked name and implementation of
a particular design or type) as a reference implementation raises the
question of whether there is "no sufficiently precise or intelligible"
other way of describing the characteristics of the electronic document

That poses a question of fact, but in my view, it's a no-brainer when
it comes to plain-text XML formats. Once you have specified a schema
and a method of validating markup against it, all that's left to
specify is the semantic meaning of the markup, define the container,
and the application behavior necessary for interoperable processing of
the documents. (That's somewhat over-simplistic.)  Moreover, the TC
could create its own reference implementation that is not controlled
by one or more vendors.

Furthermore, such a reference to a vendor's implementation whose
relevant file format features are a moving interoperability target
collides directly with the prohibition in both the AGP and ATBT
against technical regulations, standards, and procurement technical
specifications being prepared adopted, or applied if they create
"unnecessary obstacles to international trade." ATBT article 2
sections 2.2 (technical regulations), Annex 3 section (Code of Good
Practice), Article 4 section 4.1 (requiring members to ensure
compliance with the Code of Good Practice by "local government and
non-governmental standardizing bodies within their territories, as
well as regional standardizing bodies of which they or one or more
bodies within their territories are members"); AGP Article VI section
1 (procurement specifications).

In such a situation, the implementation tail wags the standard dog,
rather than the other way around as contemplated by law. Standards are
supposed to define markets of substitutable products, not to provide
cover for an ongoing  feature war. One might imagine the
interoperability mess we'd be in if implementers were left discretion
to redefine measurements for standardized bolts, nuts, and wrenches.
Substitutability of other vendors' implementations is fundamental to
what a standard is all about.

Failure to specify in an IT standard the conformity requirements
essential to achieve interoperability is at odds with the fundamental
uniformity and substitutability precepts of what the term "standard"
means. There is nothing novel about those precepts. See e.g., G. R. C.
Davis, Magna Carta, Revised Edition, British Library (1989), reprinted
as The Text of Magna Carta, Fordham University (Undated),
<http://www.fordham.edu/halsall/source/magnacarta.html>, para. 35
(translated from the original Latin) ("There shall be standard
measures of wine, ale, and corn (the London quarter), throughout the
kingdom. ...")


How one might arrive at the rational conclusion that ODF is a lawful
"standard" seems more than merely problematic when the conformance
section in all adopted versions states in relevant part:

"Documents that conform to the OpenDocument specification may contain
elements and attributes not specified within the OpenDocument schema.


"There are no rules regarding the elements and attributes that
actually have to be supported by conforming applications[.]"

The problem from both practical and legal standpoints is that ODF,
like OOXML, is in reality a de facto standard disguised in a de jure
standard's clothing. As with OOXML, what constitutes ODF is in reality
defined by the implementation with the largest market share rather
than by the standard itself. So we have "standards" that are standards
in name only.

The prescience of the ATBT and AGP's drafters is obvious in the
sections that permit international standards to be ignored if they are
prepared, adopted, or applied with a view to *or with the effect of*
creating unnecessary obstacles to international trade. They foresaw
that the international standardization process might be gamed for
anti-competitive ends, as it has been in the cases of ODF and OOXML.
This gives New York State a legal foothold under both the ATBT and AGP
to ignore ODF and OOXML until such time as they become lawful
international standards.

The approach of tackling interoperability issues by vendor
collaborative efforts at the application level rather than through
fully specifying a standard, as Rob frequently espouses, is also more
than somewhat problematic under U.S. antitrust law if the
collaboration is not aimed directly at developing specifications for
the relevant standard. See e.g., U.S. Federal Trade Commission and
Department of Justice, Antitrust Guidelines for Collaborations among
Competitors (April, 2000), pg. 2 n. 5,

"These Guidelines take into account neither the possible effects of
competitor collaborations in foreclosing or limiting competition *by
rivals not participating in a collaboration* nor the possible
anticompetitive effects of standard setting in the context of
competitor collaborations. Nevertheless, these effects may be of
concern to the Agencies and may prompt enforcement actions."

Vendors may desire a particular vendor's implementation of a standard
to define the standard's requirements. but I haven't been able to read
the governing law as allowing that.


But to summarize, specifying the conformity requirements essential to
achieve interoperability/substitutability is a threshold legal
requirement for an international standard in the IT sector. Without
such requirements, we have unnecessary obstacles to international
trade, what is referred to commonly as an "unreasonable restraint on
trade" under Sherman Act section 1 jurisprudence. It is not something
that may lawfully be left to later versions of the standard as has
been done with ODF and OOXML. Underspecified standards are
anti-competitive rather than pro-competitive because they create
barriers to market entry.

There are many other supporting authorities I could cite, but the aim
here was to honor your request for a short explanation. So I'll omit
the appellate opening brief-length version. :-) Other documents you
may find helpful in interpreting the ATBT and AGP include:

[i] their annotated interpretive texts at
and  <http://www.wto.org/english/res_e/booksp_e/analytic_index_e/gpa_e.htm>;

[ii] the interpretive text of GATT 1994 that is incorporated by
reference in the latter two treaties and provides provisions relevant
to dispute resolution and enforcement,

[iii] the 1986 Vienna Convention on the Law of Treaties between
States and International Organizations or between International
Organizations, the primary reference for interpretation of
international treaties used by both U.S. courts and the World Trade
Organization's Dispute Resolution panels,
In particular, this treaty speaks to the responsibilities of
intergovernmental organizations that implement treaties like ISO and
IEC and also sets a fair number of limits on interpretation of
treaties; and

[iv] my fledgling restatement of the law governing interoperability in
standards work at
<http://www.universal-interop-council.org/specification>. It is a
first public review draft and is particularly weak in regard to
accessibility issues (human < > machine interoperability). In the next
revision, I'm aimed at working in the requirements of the  U.N.
Convention on the Rights of Persons with Disabilities that took effect
a year ago. <http://www.un.org/disabilities/index.asp> But the other
portions are fairly mature and the supporting citations appear in the

I'll caution that the WTO interpretive texts linked above have not
been updated since 2004 and are replete with dead links.

Disclosure: I have no pecuniary interest in these matters beyond that
of all other software users. I approach these issues from a public
interest viewpoint. It's my major retirement hobby.

Best regards,

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


/Footnote 1/ Of likely interest to you, the requirement of using
international standards is extended to government procurement
"technical specifications" by Article VI section 2(b) of another
Uruguay Round trade agreement, the Agreement on Government Procurement
("AGP"), <http://www.wto.org/english/docs_e/legal_e/gpr-94_01_e.htm#articleVI>.
However, Congress has limited the judicial right of action to enforce
the AGP (and the ATBT) against U.S. state governments to the federal
government. See Crosby v. National Foreign Trade Council, 530 U.S. 363
n. 24 (2000), <http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=search&court=US&case=/us/000/99-474.html#FN1.24>,
citing 19 U.S.C. §§ 3512(b)(2)(A) and 3512(c)(1). That limitation is
of questionable legal validity, but I'll save that topic for another

Universal Interoperability Council

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]