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?


Paul:

You write and you write and you write, but I don't see the legal support you claim.

No offense intended at all, but I am trying to get simple, clear answers here.  Remember in law school, when they taught us we should be able to explain our answers to our grandmothers?  My grandmother would have stopped you at "I don't know of a relevant definition of "reference implementation" that is defined by law" and said, "So, that's the answer then, ey?"

Let's try this:

1.  You said you are not aware of a legal definition of "reference implementation."  Then how can "governing law" forbid them, as you say, if it doesn't even define them?

2.  You base your international trade legal argument on portions of the ATBT discussing "technical regulations."  But "technical regulation" is a defined term, and it is defined as something that is *mandatory.*  So it would seem to have no applicability to for example an appreciation of OO.org as a de facto reference implementation for all practical purposes.

3.  Finally, using a missing definition to a term which is applicable, and an existent definition to a term which isn't, you draw conclusions as to the illegality of ODF as an international standard.

- Are there any analyses which review these issues and come to the same conclusion you do, Paul, that you can point me to?
- Are there any analyses which review these issues and come to a different conclusion you do, Paul, that you can point me to?
- Are there any legal decisions squarely on all fours, e.g. determining use of a "reference implementation" to have rendered a standard illegal, that you can point me to?

I'm not saying you're wrong (I don't have enough experience with international trade law or standards law to say definitively).  All I am saying is the legal conclusion you thus far have provided while presented by you as rock-solid reads to me, with my skeptical lawyer's eye, to be based on an incredibly attenuated string of support much of which at first blush doesn't even seem relevant to the question I asked.

I'm curious what the IBM standards lawyers, Sun standards lawyers, Adobe standards lawyers etc. (surely they have them) Gesmer standards law firm, etc. think of this?

Thanks again for your thoughts, John

===============================================

John C. Cody, Associate Counsel
Office of the NYS Chief Information Officer/NYS Office for Technology
http://www.oft.state.ny.us
[The statements expressed herein are my own and do not necessarily reflect the policies, practices or opinions of my employer or anyone else.  Nothing herein constitutes legal advice - if you need legal advice, please consult your own attorney.]


-----Original Message-----
From: marbux [mailto:marbux@gmail.com]
Sent: Monday, May 18, 2009 12:47 AM
To: Cody, John (OFT)
Cc: opendocument-users@lists.oasis-open.org
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 itself.

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), <http://www.law.cornell.edu/uscode/html/uscode19/usc_sec_19_00002503----000-.html>.

"[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,
<http://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm#articleII>:

"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, <http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm>;
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 product.

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

<aside>

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,
<http://www.ftc.gov/os/2000/04/ftcdojguidelines.pdf>:

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

</aside>

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 <http://www.wto.org/english/res_e/booksp_e/analytic_index_e/tbt_e.htm>
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, <http://www.wto.org/english/res_e/booksp_e/analytic_index_e/gatt1994_e.htm>;

[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, <http://untreaty.un.org/ilc/texts/instruments/english/conventions/1_2_1986.pdf>.
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 footnotes.

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

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


This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments.  Please notify the sender immediately by reply e-mail and delete the e-mail from your system.


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