Universal Interoperability Council

One rough measure of a public policy debate's maturation in the U.S is its entry into the realm of presidential politics. In that regard, it notable that one plank of presidential hopeful Sen. Barack Obma's election campaign has committed to expanded openness in government. (Linked campaign page last visited May 10, 2008.)

The pledge of openness includes detailed technical components. They include an overhaul of the national information and communications technology infrastructure, with the appointment of the nation's first Chief Technology Officer to oversee the work. An emphasis on integration of IT systems in the nation's infrastructure is on the Obama to-do list, with explicit commitments to interoperability and to:

[m]aking government data available online in universally accessible formats to allow citizens to make use of that data to comment, derive value, and take action in their own communities.

While proponents of ICT modernization might hope that other candidates would embrace and extend the relevant Obama pledges, thus far none have done so. But what is still missing from the Obama campaign's to-do list is specific criteria for evaluation of file formats and communications protocols to achieve the goals announced.

This document is intended to suggest such criteria and to provide a set of principles useful for other governments concerned with revamping their information infrastructure to foster greater interoperability, accessibility, and competition in the software market in a manner consistent with antitrust law in the U.S. and the European Union as well as with international law applicable to all Member nations of the Agreement on Technical Barriers to Trade and the Agreement on Government Procurement. Consistency with the laws of other nations is an ultimate goal.

The document should not be understood as an endorsement of the Obama candidacy. This web site and the people involved with it have no affiliation with the Obama election campaign and the candidate himself.

A more formal statement of criteria likely will be developed after the Council attracts other members and this undoubtedly will be an evolving document as bugs in the principles are exposed and resolved. What follows is an evolving partial description of only one person's rough draft definition of his vision of universally accessible and interoperable formats and communications protocols, which at this stage is intended for discussion purposes only.

The criteria have not been bent with a goal of accommodating any existing electronic data format or communications protocol specification. Rather, the criteria are intended as a statement of goals and as criteria for evaluating interoperability strengths and weaknesses of specifications and their legal suitability. Those who use the principles as a guide or criteria will undoubtedly often experience difficulties in identifying an existing specification for given functionality that fulfills all criteria given the present state of the software market globally.

However, the principles are intended as legally and technically sound criteria that are suitable for resolving or preventing disputes, e.g., by being incorporated into software procurement specifications and service-oriented architectures. They are derived principally from existing authoritative sources and the Interoperability School of Hard Knocks. Supporting references are hyperlinked from the notes.

Public participation and constructive criticism is encouraged via a web group/mailing list.

Paul E. Merrell, J.D. ("Marbux")
May 10, 2008

Criteria

Relationship of Definitions and Notes. The terms defined in the Definitions section of this document shall be thus construed wherever such terms appear in the text of the enumerated Criteria. The Notes section of this document is intended as commentary, but may be used in determining the intent of the drafters and legal sources of the Principles.

To the maximum extent permitted by applicable law, a universally accessible and interoperable electronic data format or communications protocol specification:1

1. Obstacles to trade ---MUST not be prepared, adopted, or applied with a view to or with the effect of creating unnecessary obstacles to international trade; 2

2. Cultural and linguistic adaptability --- MUST not give preference to the characteristics or requirements of specific countries or regions when different needs or interests exist in other countries or regions.3

3. Portability --- MUST be platform neutral and fully portable to any information technology system capable of processing the same kind of information; 4

4. Compatibility --- MUST safeguard the value of past investments and long-term access to information by requiring “vintage” (backward and forward) compatibility among all iterations of the specification.5

5. Accessibility --- MUST make information stored or exchanged universally accessible and usable by persons with disabilities to the maximum extent feasible;6

6. Availability --- MUST be fully specified in one or more non-ambiguous documents that are easily available in an assortment of widely used electronic document formats at no charge to the general public and are redistributable without restriction of any kind other than a prohibition against modification except for purposes of preparing new iterations of the specification. For purposes of this provision, the availability principle applies equally to specifications themselves and to all other specifications they incorporate by reference.7

7. Harmonization --- MUST demonstrably be compatible with any other universally interoperable specification to the full extent functionality is duplicated or overlaps;8

8. Intellectual Property Rights --- MUST require unequivocally that implementation of any portion of the specification that was unique to the specification when introduced shall constitute a self-executing, irrevocable waiver of all intellectual property rights reading on the conforming implementation of the full specification and use of such implementations by any other person or entity. However, relevant intellectual property rights may be irrevocably assigned to a custodial entity using a standardized form of assignment but only for purposes of specification defense and for enforcement of conformity.9

9. Liberty --- MUST be free of any and all restrictions or conditions of any kind on its implementation and use by any person or entity, other than conformity requirements, conformity assessment procedures, and the exception stated in the provision governing intellectual property rights.;

10. Conformity requirements ---MUST fully specify all relevant functionality only in mandatory terms, including conformity requirements essential to achieve interoperability, including any application behavior necessary for the interoperable exchange of information and its mutual use by two or more information technology systems. While a specification may specify methodology for extensions not specified by the specification for purposes of compatibility between earlier and later versions of the specification, such extensions shall not be deemed conformant with the specification. Likewise, application or vendor-specific extensions shall not be deemed as conformant. 10

11. Interoperability required and demonstrable ---MUST clearly and unambiguously require that conforming implementations be fully interoperable and that such interoperability be both demonstrable and demonstrated using fully specified conformity assessment procedures adequate to ensure interoperability;11

12. Complex specifications --- For complex electronic data format specifications, MUST specify both a superset and subsetting profiles as necessary to fulfill market interoperability requirements for the interoperation of less and more featureful implementations. 12

Definitions

The following definitions apply when interpreting the Principles:

Requirements keywords and phrases

The key words and phrases "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," "may," and "optional" throughout this document are to be interpreted as described in RFC 2119.

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

Compatible, incompatible

In the ICT context, compatibility is the qualitative degree to which one ICT system can correctly process information generated by a different ICT system. To the extent that information received by one ICT system from another cannot be processed correctly, the interfaces for exchange of information are said to be incompatible. Incompatibilities are barriers to interoperability.

Information and communications technology ("ICT") system

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

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

Universal, universally

Universal is to be interpreted in its logical sense of a proposition that asserts something about all members of a defined class. The particular class defined by use of the term in these principles is the universe of all those persons who utilize, develop, provide, or regulate information and communications technology. The term is not to be understood as suggesting that a single specification could fulfill all market requirements for data formats or communications protocols in the information and communications technology sector. The requirements of compatibility and harmonization, however, deliberately sets a high bar to the extent that universally interoperable specifications duplicate or have overlapping functionality.

Notes

1. 1.

   Exception and Applicability to specifications generally --- The exception for irreconcilable conflicts with governing law has several intended purposes: [i] the language chosen already has a high judicial gloss in other legal contexts and its meaning is well understood by courts, so the exception is intended to import well-established principles of interpretation; [ii] the exception functions as a preservation clause for the remainder of the specification to the extent that an adjudicative body might find a conflict between governing law and some portion of the specification, an important factor in a world where laws are not uniform globally; [iii] the language chosen deliberately focuses challenges to the specification on legal as opposed to factual or extraneous policy issues, thus reducing the expense of dispute resolution; and [iv] the exception promotes uniformity in the interpretation of the specification itself by inviting adjudicative bodies to focus their inquiry and written decisions on legal conflicts with the specification rather than on reinterpretation the specification itself to achieve a desired result.

   Notice that the criteria overlap substantially with many definitions of an open standard, e.g., the definition adopted during 2007 by the South Africa Department of Science and Technology in its Minimum Interoperability Standards (MIOS) for Information Systems in Government v. 4.1 (PDF), p. 10. However, the principles of universal interoperability are intended to apply more broadly to data format and communications protocol specifications whether or not adopted as a formal standard or technical regulation.

   As to uniformity of applicable law, the Agreement on Technical Barriers to Trade was selected as the specification's foundation because the Agreement governs in a majority of nations globally and is explicitly intended to regulate the preparation, adoption, and application of all technical regulations and standards throughout the territories of Member nations. See e.g., ATBT article 2 section 2.2 and Annex 3 to the Agreement. Through the Agreement on Government Procurement, article VI section 2, the use of technical regulations and international standards is mandated as government procurement ("technical") specifications at all levels of government in Member nations. These two treaties already address ICT specifications comprehensively in their Member nations and provide dispute resolution procedures. This specification thus is intended to have broad multinational utility. However, conflicts with laws in non-Member nations are foreseeable but unstudied, again pointing to the need for the exception clause.

   The exception also addresses unresolved areas of tension with existing unresolved areas of the law where an adjudicative body might find a conflict. For example, the specification requires that all standards incorporated by reference into specifications must be available to the public at no charge. This is an issue on which adjudicative bodies have apparently not yet rendered decisions. Although there are strong arguments that such a result is required by the relevant treaties, the decision in such a case is not certain. To accommodate this and other areas of uncertainty, an exception for conflicting law is necessary.

   The Criteria are drafted using a far more results-oriented approach than attempted in previous efforts to define an open standard. The results-oriented approach draws its inspiration from sources such as the Agreement on Technical Barriers to Trade and works such as that of R. Gosh, An Economic Basis for Open Standards, (PDF), European Commission DG Information Society, Free/Libre/Open Source Software: Policy Support report (December 2005), p. 11 ("open standards should be defined in terms of a desired economic effect: supporting full competition in the market for suppliers of a technology and related products and services, even when a natural monopoly arises in the technology itself") (note that Prof. Gosh's work is addressed to the European Community's implementation of the Agreement rather than to the Agreement itself).

   See also L. DeNardis and E. Tam, Open Documents and Democracy: A Political Basis for Open Document Standards, Yale Information Society Project (November 1, 2007) (expanding on Prof. Gosh's competitive analysis approach to address democratic and ethical concerns) (includes an extensive survey of the academic literature relevant to open standards).

   The approach followed in drafting deliberately de-emphasizes procedural factors such as the transparency of a standard's development process to focus on the characteristics of the resulting specification. This approach was chosen in part because the Agreement on Technical Barriers to Trade currently allows far less transparency than is required by existing definitions of an open standard and the fact that transparency and participation requirements in some definitions of an open standard would forbid use of international standards that are required as a matter of law to be used as government technical regulations absent specific exceptions specified by the Agreement that do not include some criteria specified in several definitions of open standard. An effort has been made to draft the Principles in harmony with the Agreement.

   The approach followed, however, nominates universally accessible and interoperable specification as a more appropriate term to define than open standard for a variety of reasons, including the fact that no definition thus far of an open standard has proved satisfactory and because of widespread disagreement on what "open" means in context that has rendered the term all but meaningless to the lay public.

   The term universally accessible and interoperable specification appears to better encapsulate the end result sought in recent definitions of an open standard by government bodies and is less susceptible to misunderstanding or deliberate misinterpretation. E.g., specifications encumbered by patent restrictions forbidding sub-licensing cannot defensibly be characterized as universally interoperable specifications because they cannot legally be implemented by developers already irrevocably committed to the most popular free and open source software licensing schemes.

   However, engrafting a prohibition against patent royalties and licensing restrictions upon a definition of an open standard is counter-intuitive to many because it has nothing to do with the "openness" of a specification in the same sense the word open is used in the phrase, open source software. I.e., source code may be "open" yet still be encumbered by intellectual property rights. For example, the ISO/IEC:29500 Office Open XML standard is open but its implementation is restricted by patent claims.

   There are other relevant factors. For example, the term open standard has long been used by standards development organizations notwithstanding patent licensing restrictions. Moreover, the term has also acquired a judicial gloss in the context of antitrust regulation of standards development organizations that is at odds with later efforts to adapt the term to fit the requirements of free and open source software developers and users.

   Further confusion has been introduced by the fact that the meaning of open is not co-extensive in the differing contexts of "open source software" and "open standards," with different, highly nuanced meanings required in both cases. Another source of confusion has been that the common and ordinary meaning of open does not encompass the full scope of the criteria enunciated in various attempts to define an open standard.

   The term universally accessible and interoperable specification, however, by its common and ordinary meaning defies definition as anything less than universally implementable. E.g., a party would likely have scant success in arguing that advertising a specification as "open" is false advertising, whilst the prospects of litigation success seem much more likely if the advertising falsely claimed that a specification is universally interoperable. Because the term chosen more descriptively encapsulates the intended result, it is far more bullet-proof in the legal sense and far less susceptible to misuse. The term was deliberately chosen to be more enforceable in legal proceedings than an "open standard," even absent further definition.

   The choice to focus on technical specifications in general rather than more narrowly on standards or technical regulations is intended to recognize that a specification may be universally interoperable without stamp of approval by a standards development organization or by a government body. (The approach also avoids the necessity of distinguishing in the suggested principles of unity among standards, technical regulations, and technical (procurement) specifications, which are often one and the same, differing only in their legal effect.)

   Major considerations in the decision to address the broader subject of "specifications" include: [i] the Agreement on Technical Barriers to Trade article 2 sections 2.2 and 2.4, read together, prohibit governments from using international standards as a basis for technical regulations to the extent that international standards are "prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade;" [ii] the fact that the same specification must necessarily have identical content to simultaneously serve as a government procurement technical specification under the Agreement on Government Procurement and as a standard and technical regulation under the Agreement on Technical Barriers to Trade; [iii] a desire to encourage experimentation outside the traditional standards development model when developing universally accessible and interoperable specifications. For example, there has been discussion within the free and open source software community of the need for community development of data format specifications as an alternative to standards that are incompatible with free and open software licensing requirements.

2. 2. Obstacles to trade --- Drawn verbatim from the Agreement on Technical Barriers to Trade, article 2 section 2.2;

3. 3. Cultural and linguistic adaptability --- Derived verbatim from World Trade Organization Committee on Technical Barriers to Trade, Decisions and Recommendations Adopted by the Committee Since 1 January 1995 (May 23, 2002), para. 10; in turn derived from Agreement on Technical Barriers to Trade, article 2 section 2.1. Cultural and linguistic adaptability is also identified as one of three mandatory "strategic characteristics" of standards by ISO/IEC JTC 1 Directives, 5th Ed., v. 3.0, pg. 11 (PDF).

4. 4. Portability --- This provision is corollary within the information technology sector to the requirements of the Agreement on Technical Barriers to Trade, article 2 sections 2.1 and 2.2. The requirement of portability is one of three mandatory "strategic requirement" for standards identified established by ISO/IEC JTC 1 Directives, 5th Ed., v. 3.0, pg. 11 (PDF); see alsosection 10.5, pp. 51-52.

5. 5. Compatibility --- Derived from Organisation for Co-operation and Economic Development, ICT Standardisation in the New Global Context -- Final Report, (PDF), OCDE/GD(96)86 (Paris 1996), pp. 16-17.

6. 6. Accessibility --- Voluntary guidelines for accessibility features in electronic data format markup languages have been ineffective in ensuring universal accessibility of electronic data formats. However, government-mandated accessibility in telecommunications have succeeded. communications.

   Therefore, the principles embrace the mandatory approach. The phrase "to the maximum extent feasible" is intended to require such measures as strong as a requirement that implementations not allow the writing of data if accessibility metadata fields are empty. A specification's documentation must, of course, itself be accessible.

   The accessibility principle's mandatory nature draws partial legal support from human rights law such as section 508 of the U.S. Rehabilitation Act of 1973, as amended by 29 U.S.C. 794d.

7. 7.

   Availability --- NeedsWork

8. 8. Harmonization --- Derived from the Agreement on Technical Barriers to Trade, e.g., article 2 sections 2.3 ("[t]echnical regulations shall not be maintained if the circumstances or objectives giving rise to their adoption no longer exist or if the changed circumstances or objectives can be addressed in a less trade-restrictive manner") and 2.6 ("[w]ith a view to harmonizing technical regulations on as wide a basis as possible, Members shall play a full part, within the limits of their resources, in the preparation by appropriate international standardizing bodies of international standards for products for which they either have adopted, or expect to adopt, technical regulations")

9. 9.

   Intellectual Property Rights --- Intellectual property rights ("IPR") reading on a universally interoperable specification may have either anti- or pro-competitive effects. To the extent that IPR impede or block conforming use of a specification, they are legal as opposed to technical interoperability barriers and are anti-competitive. To the extent IPR provide a basis for defending a specification from infringement claims or provide a legal basis for requiring that implementations conform to the specification, they are pro-competitive. The principle therefore requires waiver of relevant IPR as a self-executing condition for implementing any unique portion of a specification whilst preserving the ability to irrevocably assign IPR to a custodial entity for identified purposes only.

   However, to maximize the legal harmonization of specifications and to avoid the likelihood of inconsistent IPR assignments governing universally interoperable specifications producing legal incompatibilities, the form of assignment should be broadly standardized, ideally by binding international law.

   The phrase "use of such implementations" is intended to extend the IPR immunity required for developers and their assigns to likewise protect users of implementations. This phrase was felt necessary because many existing IPR documents bestow IPR protection on implementors but do not expressly extend such protection to software users. E.g., Sun Microsystems OpenDocument Patent Statement.

10. 10.

    Conformity requirements --- The requirement that characteristics be specified in mandatory terms is drawn from the definition of a technical regulation in the Agreement on Technical Barriers to Trade Annex 1 (article XVII) as clarified by the decision of the World Trade Organization Appellate Body in the case of WTDS 135 EC - Asbestos, (March 12, 2001), para. 66-70 (requiring that all characteristics of an "identifiable" product be specified in mandatory terms, using either "must" or "must not" terms).

    See also ISO/IEC JTC 1 Directives, 5th Ed., v. 3.0, p. 145 (PDF) ("[s]tandards designed to facilitate interoperability need to specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability. Complexity and the number of options should be kept to a minimum and the [interoperable] implementability of the standards should be demonstrable"); id.(requiring standardized interfaces for interoperability purposes).

    The requirement that all product characteristics of an identifiable product must be specified in mandatory terms goes to the very heart of what a standard or technical regulation is. One of the defining characteristics of a standard is the substitutability of a standardized product regardless of which conforming implementor created the particular product. In the ICT sector, interoperability is a prerequisite to substitutability of data format and communications protocol implementations. Note that in an increasingly networked world with dramatically expanded exchange of information, the discernable line between a data format and a communications protocol is blurring accordingly.

    The prohibition against conformant status for application-specific extensions itself pays due regard to the principle discussed in the last paragraph and also recognizes that application-specific extensions to data formats and are an interoperability breakpoint. At the same time, the prohibition does not deny rights to embrace and extend a specification. However, it contemplates that adoption of a new or amended specification is the only permissible means of achieving conformant status for such extensions.

11. 11. Interoperability required and demonstrable --- NeedsWork

12. 12.

    Complex specifications --- In the era of closed, proprietary, binary, and incompatible data formats, core functionality was often elaborated as part of "feature wars" to an extent that new market entries all too often could achieve interoperability only by using the application programming interfaces provided by market leaders. A sterling example is the traditional client-side office suite. Thus evolved a "stack" approach to interoperability that denied 2-way interoperability at the data format level to competing or complementary applications unless they first achieved a 1:1 feature and functionality match with the market leaders, a wholly hypothetical circumstance never seen in the wild.

    The barrier to entry of the market thus posed was compounded by a lack of support in the market leader's data formats for the full range of features required or realizable by specialty applications, e.g., outliners, abbreviation expanders, spell-checkers, lightweight editors, and applications designed for unique requirements of vertical markets.

    Developers of such applications were forced to use various workarounds to achieve 1-way interoperability with the market leading stacks, such as limiting their applications
    to generation of plain text only and stuffing the keyboard buffer, converting their output to a less complex proprietary format supported natively by the market leading applications such as Rich Text Format, requiring users to copy and paste information to the market leading stack applications, etc.

    However, the ability of software users to generate content in the mega-apps that could be processed by the less featureful applications was severely limited by the inability to set compatibility modes in order to send information to the less featureful applications. The net effect, whether intended or not, was to marginalize the specialty applications and to block them as a threat to the market leaders' hegemony by denying them 2-way interoperability.

    The principle enunciated for complex specifications is intended to address such issues by recognizing the "mega-formats" as inherently anti-competitive and anti-innovation, requiring remedial measures.

13. 13.

    Application-level interoperability --- A specification that does not clearly, unambiguously, and fully specify a standardized interface for interoperability purposes as well as conformity requirements essential to achieve the interoperability is inherently anti-competitive and raises grave legal issues under antitrust laws and the Agreement on Technical Barriers to Trade Article 2 section 2.2, made applicable to all technical standards work within the territories of Member nations by Article 4 section 4.1 and Annex 3 to the Agreement. Note that Article 2 section 2.2 is in harmony with antitrust law.

    An example of the anti-competitive aspects of inadequate specification is provided by the European Community Court of First Instance's recent Grand Chamber (en banc) antitrust decision in Commission v. Microsoft, (Judgment of 17 September, 2007) (requiring disclosure of interoperability specifications for Windows and Windows Server communications protocols sufficient to place competitors on an "equal footing" and rejecting a 1-way interpretation of "interoperability.").

    Industry standard-setting consortia and their participants generally are subject to regulation under antitrust laws without regard to the market power of their individual members. See e.g., Allied Tube & Conduit v. Indian Head, Inc., 486 U.S. 492, 501 (1988) (reinstating jury award of treble damages) ("trade and standard-setting associations routinely treated as continuing conspiracies of their members"); see also Article 81 of the onsolidated Versions of the treaty on European Union and of the Treaty Establishing the European Community, as amended (PDF).

    Therefore, specificity principles such as those announced in the Commission v. Microsoft decision discussed above should be regarded as applicable to industry standard-setting consortia and to their participating staff and members.

14. 14. Information technology system --- Identical to definition in ISO/IEC JTC 1 Directives, 5th Ed., v. 3.0, pg. 145 (PDF), except that the definition has been extended from "information technology" to "information and communications technology."

15. 15.

    Interoperability --- The definition is derived from that given by ISO/IEC JTC 1 Directives, 5th Ed., v. 3.0, pg. 145 (PDF). However, that definition has been expanded to cover communications technologies as well as information technologies.

    Interoperabilityis identified as one of three "Strategic Common Characteristics" of IT international standards by ISO/IEC/JTC 1 Directives, p. 11, and is, along with portability and cultural and linguistic adaptability, a fundamental requirement of the Agreement on Technical Barriers to Trade article 2 sections 2.1 and 2.2 as applied to information and communications technology. Because all three traits are encompassed by the term universal interoperability, the principles accordingly address all three strategic characteristics.

    The requirement that interoperability be enabled by specification of a standardized interface is included in the existing JTC 1 Directives definition, although in the sense intended here the word standardized extends to any specification that fulfills all principles of universal interoperability enunciated rather than merely requiring (as JTC 1 Directives do) that an international standard must specify an interoperability interface.

    The principles include four other elaborations on the JTC 1 Directives definition:

    • The definition has also been supplemented with an explanation of the term interoperable that is intended as no more than a corollary to the definition of interoperability.
    • The exclusion of application-level interoperability is implicit in JTC 1 Directives and fair competition law but has been made explicit here.
    • Inclusion of the adjective equal before the word mutual and of the qualifying phrase, without differences in use attributable to inadequacies in technical regulations, standards, or technical specifications, are intended to stress that interoperability unambiguously requires that no conforming implementation have its quality of interoperability impaired when compared to any other conforming implementation by lack of specificity in a technical regulation, standard, or technical specification.

    
    

    The changes summarized in the last bulleted item were deemed necessary because of the antitrust interoperability decision in Commission v. Microsoft, (European Community Court of First Instance, Grand Chamber (en banc) Judgment of 17 September, 2007) (interpreting very similar definition of interoperability to require specifications for competitors enabling 2-way interoperability of the same quality of interoperability that Microsoft achieves among its own software products, rejecting a 1-way interpretation of interoperability raised by Microsoft. Those two elaborations are intended, inter alia, to forestall arguments akin to those made by Microsoft in the European Community court.