Technical standards and their effects on e-commerce contracts: beyond the four corners

This Article provides an overview for practitioners by describing some of the sources and lifecycle issues for data standards, examining how they may affect the terms of those contracts, and noting emerging criteria used by governments and others for evaluating their use.

WHY DATA STANDARDS MATTER IN E-COMMERCE LAW

Broadly speaking, commerce has been dependent on standards for a few thousand years. Standardized weights and measurers apparently were reliable features in ancient Egyptian commerce

Today there are American and global standards for thousands of product attributes, including mundane matters such as the local conventions for the pitch of the thread in a light bulb socket, and the inner diameter of a paper towel roll. These conventions perform an important function: they allow us to buy light bulbs and paper towels without bringing along a measuring tool.

On the other hand, of course, manufacturers usually (1) are free to decline the guidance of standards, strike out on their own path and offer, for example, eccentric light bulbs that can be plugged only into their own unconventionally-shaped socket. The light bulb designer might have any number of reasons for this: better functionality, attractive design, or simply the hope that many users will follow her to this new socket size–creating a new market and perhaps an occasion to sell lots of new lamps. If the new socket design is proprietary, or hard to replicate, those barriers to entry may give her a strong advantage in the new market–assuming anyone wishes to buy the funny-shaped light bulbs.

Suppliers and users face this same tension in practically every industry–the converging force of commoditization and substitutability, versus the centrifugal pull of design changes, branding and product strategy. Standards for the organization of data are no different. In this Article we are discussing “data standards”: published common methods for expressing and organizing information, usually in electronic form.

A handful of data standards were responsible for the extraordinarily fast emergence and growth of the Internet. Several basic data representation methods, designed to be equally useable on any computer platform, were developed and made widely available for free. (2) When combined, they proved to be so easy to implement, and suitable for communicating information, that they spread virally across the Earth to become first accessible and then essential to millions of users in a few short years.

The argument of this Article is that data standards supply a great deal of content–terms, interpretive data and limitations–to transactions that invoke or employ them, to which a careful lawyer should pay attention.

The broadest definition of a data standard might include any common data structure of specification that is shared among multiple users. Such specifications can come from a wide variety of sources, ranging from official international governmental agencies, through industry associations and loose coalitions, to single companies or individuals.

WHO PARTICIPATES IN A STANDARDS PROCESS … AND WHY?

Data standards efforts, in varying proportions, enjoy participation from both the “buy” side of data–industrial, commercial and consumer users–and the “sell” side–software and hardware vendors, data service providers such as application service providers (ASPs), and data warehouses, and outsourced experts and consultants. What brings them together often is the opportunity to create a larger market:

[R]ailways, electricity, cars and telecommunications all learned to

love standards as they came of age. At a certain point in their

history, it became clear that rather than just fighting to get the

largest piece of the pie, the companies within a sector needed to

work together to make the pie bigger. Without standards, a

technology cannot become ubiquitous, particularly when it is part of

a larger network. …

Today, the [Information Technology] industry is finally getting the standards religion. In fact, standards have always played an important role in high-tech, but they were often proprietary. … The name of the game in IT has been locking in customers, making it costly for them to switch from one brand of technology to another. … It would be hard to overestimate the importance of this shift. (3)

Parties reach their own conclusions about using and participating in this work, and their perceived benefits and motives vary. Use of standards, and in some cases active participation in a standards development organization (SDO), may have several perceived benefits:

* More eyes on the work product should usually result in better

quality.

* It’s easier to build systems upon an emerging standard or industry

consensus. You may enjoy a bigger labor pool of experts, which

reduces the need for special in-house knowledge to design and

implement new work.

* You can work to ensure that the industry’s standard practices

include the functionalities and compatibility that your own products

and systems need. Or you may choose to participate with explicit

competitive goals in mind, such as swaying an industry standard

towards your product, or away from competing with it.

* In a robust group (one with broad, diverse participation), you are

better able to stay in synch with the best minds in the field.

* In a publicly-available, vendor-neutral group, you are

contributing towards a common good. (Don’t discount this as a

motivation for senior technologists).

* For vendors: a new approach’s chances of adoption are better if

multiple vendors are building to it and multiple users demanding it.

Tooling to a new standard (or way of doing things) often is a

significant development expense, and much less risky if there’s a

crowd heading in the same direction.

* For users, generally speaking, interoperability is good. (4)

Interoperable, standards-based software and data design give users

more options.

* Some methods of cooperating with competitors risk

antitrust/competition law problems. To some extent, however, there

are legal safe harbors for cooperation within standards efforts,

depending on their legitimacy and other factors

of their own rich academic literature. (5)

But participants may also choose to go their own way. Factors that contribute to avoiding standards efforts might include the following:

* Consensus takes time. A neutral SDO with broad participation and a

careful deliberative process might not be able to bring a new data

structure to market rapidly enough to suit a vendor’s plans.

* It may cost more–in development time, requirements collection and

testing–to build in interoperability with other standards.

* A technologist who thinks he has a substantial knowledge advantage

in a particular topic might view collaboration as a one-way

information transaction with no benefit for him. Note this might be

true on the “buy” side as well as for vendors: a user whose

proprietary business processes are an acute competitive advantage

probably doesn’t want to have them baked into widely available

software.

* For users: the practical interoperability advantage of standards

requires actual, everyday working connections between users of the

standards. If a standard is written without acute detail, different

implementers might reach different conclusions, resulting in two

installations of the “same” standard that can’t talk to each other.

These issues sometimes require outside conformance tests, which

increase the expense of coordination and alignment.

* For users: documentation for a collaboratively-developed standard

may include an assertion that it is suitable for a particular use,

but most often this is subject to “as-is” cautionary notices and

similar disclaimers of warranty Users who wish a contractual level

of assurance that a data structure will meet their precise goal may

need separate third-party undertakings. A standard’s intrinsic claim

to functional competence is reputational rather than contractual.

* For vendors: open standards remove a barrier to market entry. If

you already have a defensible market share, you might not want to

remove that barrier. Some go so far as to suggest that users should

routinely consider distrusting the motives of participants in

standards work. In the words of Professors Shapiro and Varian, whose

1999 book Information Rules is a key commentary on this field:

[In a networked market,] [m]ost companies need to cooperate with

others to establish standards and create a single network of

compatible users. But as soon as the ink is dry on the standards

agreement, [they] shift gears and compete head to head … you

cannot take it on faith that the other market participants truly

want to establish a standard. … An incumbent with little to offer

to the new generation of technology, offensively or defensively,

will have a greater interest in sabotaging new standards than in

promoting them. (6)

Consider these motives and opportunities, as we examine the manner in which data structure standards are created.

SOURCES AND LIFECYCLES OF DATA STANDARDS

Some will argue over whether any entity may create, or any shared practice may fairly be called, a “standard.” To some purists, the source of a proposed data structure is central to the definition: they may believe that only specifications created and maintained in an open of closely-refereed process should be called “standards.” Users should consider the source–and we will return to the concept of “openness” later in this Article–but for now let us refer to any published method for structuring information as a potential “standard” of sorts. In that broad view, many sources are possible:

De Jure Standards Authorities

By treaty and national legislation, there are a set of “official,” governmentally-sanctioned SDOs, with a top tier of three international groups: two quasi-governmental associations, the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), and one UN agency, the International Telecommunication Union (ITU). One level down in that hierarchy, most individual countries also have national-level official SDOs, such as the American National Standards Institute (ANSI) in the United States. (7) The expertise of these global groups overlaps somewhat in e-commerce and Internet matters

Associations and Consortia

A variety of interests and enterprises have come together to form SDOs by creating distinct, usually not-for-profit entities to act as a neutral party for owing and managing collectively-created standards. There are at least dozens, and perhaps hundreds, of these groups. (9) In e-business, the best known global SDOs of this type include the Internet Engineering Task Force (IETF), the World-Wide Web Consortium (“W3C”) and OASIS. Generally they are membership-run and self-funded through membership dues. (10) Most, though not all, are open to anyone who wishes to join.

Some groups are formed by a single industry to address vertical needs, and may be the principal or exclusive users of the standards they create. Examples of that type include the electronics industry coalition RosettaNet (11) and the financial transaction-processing agency SWIFT. (12) Some non-SDO organizations, although not themselves issuing standards, are involved in the standards process in other ways, such as The Open Group, (13) which acts as a certifier of standards compliance in some fields.

Proprietary Efforts: Joint Development Groups and Single Authors

Finally, there are quite a few entities generating proposed standards either as a sole software supplier or user, or a collection of like-minded parties. Typically, when there are multiple participants, a set of contracts defines who owns the joint work. Additionally, proprietary projects may be less transparent: confidentiality or competition-related covenants may be a condition of participation.

The boundaries between these categories can blur easily. Also, work started in one place may progress elsewhere. It is not uncommon for a private group to develop a standard, publish a first version, and then contribute it to an SDO for public review and further improvement.

One well-known example of a successful private-label SDO is the Java Community Process (JCP) group, (14) using technology owned and licensed by Sun Microsystems, developer of the Java software language. Although Sun owns the key JCP work, it has enjoyed considerable success in bringing other companies to the table to work on its elaboration. As The Economist put it, Sun’s stated goal is that the JCP will run with the same openness as a neutral standards body, “[b]ut because Sun is worried that its Naval standard could splinter, just as that for the Unix operating system did, the firm has installed itself as the JCP’s benevolent dictator.” (15)

Sun’s retention of ownership of the core technology does not seem to have inhibited users and even competitors from participating in the JCP This suggests that nonproprietary ownership is not always a necessary component for encouraging broad standards participation.

Of course, even without any collaborative process, any single vendor’s software or data format may become a “de facto” standard, if widely enough deployed, or at least a “du jour” one if sufficient public relations efforts are applied. Considered as an asset, a data exchange format is more valuable as it is more widely adopted. Part of that value derives from network effects: the more users in a marketplace that adopt a particular standard, the easier it becomes for the others to follow. Another component of that value is consumer lock-in: once users adopt an established method, they may face a substantial switching cost to re-train of retool. (16) This “stickiness” can be a goal to avoid for some, or an engineered competitive advantage for others: data specifications may be deliberately designed to increase or decrease the ease with which they can later be abandoned, once adopted.

By including privately-held formats within our review of “standards” here, we acknowledge that widely adopted specifications enjoy some market advantages that should be taken into account, whether they are the product of public collaborative work of simply a pervasively-used single-vendor format (such as an Oracle database or a Microsoft Word text document). That a specification is “proprietary” is not necessarily a positive of negative feature, but rather one data point among many regarding its ownership, availability and possible influences.

HOW Do STANDARDS ORGANIZATIONS WORK?

The rules under which an SDO hosts, reviews, approves and publishes a standard vary from group to group. Most of the same basic elements are present in each, however. The path of a standard’s development by a typical SDO often includes the following stages, loosely diagrammed in Figure 1.

Concept Stage

At the outset, a perceived need for a new data standard is brought to the attention of the SDO, whether from within the group itself or from the outside world (ARROW A). With a few exceptions, SDOs support themselves through membership fee structures. Some may permit any member to propose new work items, while others maintain central editorial control over what new items may be launched.

Scope Stage

At the outset, most new standards work projects create a binding definition of their work scope. SDOs vary on the degree to which this scope later can be changed. Presumably the proposers’ original concepts (ARROW B) are a principal source of this definition. If sufficiently clear, this mission-defining step fulfills several goals:

* It guides potential users and contributors to the project.

* It helps organize the work, and defines its initial relation (if

any) to existing standards and products.

* It permits potential private-sector participants to decline

knowledgeably, if the planned scope conflicts with their own

proprietary work.

* It permits projects to be assigned to the proper panel and avoid

duplication in organizations that maintain a standing taxonomy

of subjects.

In some cases, a project’s first phase is to collect and analyze the business requirements of prospective users

Contributions Stage

Some projects may commence (ARROW C) without any explicit “seed” work product

Editing and Review Stage

During the principal work (ARROW F) on a draft standard, its editing and review are performed according to the internal operating rules of the SDO. Some are quite formal, whereas others are informal or relatively unregulated: this may result from the content of the organization’s rules, its inclination and ability to enforce them, the culture of the participants, or all three. SDO rule sets also may vary to the extent which they facilitate diverse participation, differences of opinion, and the role of project initiators versus other members. Another variable is the degree to which intermediate deliberations include public input (ARROW G) or are restricted to members (ARROW H).

Approval Stage

Most SDOs have some sort of formal approval mechanism for advancing a completed work (ARROW I) as an official or approved product of the organization. The breadth of participation in that approval, and the degree to which it is subject to a bottleneck editorial or executive approval, may vary. Many SDOs also require an open public review period of some sort prior to that approval

Deployment Stage

Once a standard is approved, the SDO makes arrangements to publish it or otherwise make it available (ARROW K). The ownership and terms of availability may vary, both for the standard as a work itself, and with respect to any proprietary or licensing claims made against it. Some SDOs also remain involved in the post-approval life of a completed standard, by defining conformance tests, promoting implementation demonstrations and the like, which may generate additional work product (ARROW L) such as updated versions and implementation guidelines. After a final standard is released, of course, things happen. The responsible participants may have future “versioning” plans

HOW Do DATA STANDARDS AFFECT CONTRACTS?

Agreements of projects that rely on the performance of technical information standards are dependent on them, and thus vulnerable to them, in several ways. First, use of one of more standards may be an explicit requirement of a deal. Second, a standard may directly of indirectly supply additional terms to a contract. Finally, a standard’s own dependencies, assumptions and biases may structurally impose constraints on a contract or project, even when no terms are stated or intended. Let’s consider each of these effects in turn.

EXPLICIT REQUIREMENTS THAT A STANDARD BE USED

Parties preparing for an e-business relationship should, and often do, take into account the transactional costs associated with maintaining stable electronic communication channels. They may wish to bind themselves and their anticipated counterparties into using specific formats, methods and standards. This need for certainty in e-commerce was anticipated in 1990 in the ABA Model Trading Partner Agreement, in which the authors recommended that prospective EDI trading partners resolve such matters by contract in advance, and provided a model for doing so:

9. “Standards” are the uniform specifications for the electronic

interchange of business data and include provisions of the structure

and format of data as well as the transmission of the formatted

data. There are also standards, among other things, for certain

security and communication procedures.

10. The selection of applicable standards is a matter of some

flexibility. The parties may mutually select and utilize one or more

sets of recognized standards, or, within certain technical limits,

customize those standards to their mutual benefit. Existing

technology also permits each party to adopt a different standard for

transmission of a Document, with [third party service] Providers

… subsequently conforming the different formats to each party’s

adopted standard.

11. Virtually all standards for EDI include detailed technical

requirements to facilitate EDI, including transaction sets, data

dictionaries, segment dictionaries and other uniform controls.

Pursuant to the provisions of the [model agreement’s] Appendix, the

selection by the parties of applicable standards acts to incorporate

by reference these additional requirements. Should the parties

desire to exclude or modify any of such requirements, such changes

may be made in the Appendix. (17)

That report analyzed the first wave of EDI transactions at the start of the last decade, and provided enforceability guidance to EDI pioneers. (18) Even then, the authors viewed standards invocation as a key issue. If anything, data standards have become more central in the ten years hence.

Distinct business communities with high-volume repeat business often are among the early adopters of standard electronic methodologies. In some cases, a highly regulated market (or equivalent economic constraints) makes transactions easy to regularize

* The “SMART” (formerly “eMortgage”) draft guidelines for optimal

electronic mortgage documentation, issued by the Mortgage Industry

Standards Maintenance Organization (MISMO), established by the

Mortgage Bankers Association of America. (19)

* Retailing leader WalMart Stores is one of the many companies that

require many suppliers to conduct their supply chain transactions

over specific, exclusive EDI or e-commerce channels. (20)

A large number of electronic commercial networks have been formed over the past six years. Often they require as a condition of participation that the users employ specific data structures. Some employ publicly available pre-existing standards

* RosettaNet, an electronics industry consortium, an early B2B

success providing supply chain e-transactions widely used by its

members, who govern it as a non-profit association (recently

acquired by the Uniform Code Council)

* Bolero (originally Bills Of Lading EuROpe), a cross-border trading

system that replaces paper with electronic messaging and title

transfer, owned by the TT Club (a mutual insurance association of

over 5,000 transport operators), (22) and SWIFT (see below), that

seeks to replace certain paper trade instruments such as ocean bills

of lading with electronic messaging and title transfer methods

* SWIFT, the global electronic financial transactions banking

cooperative, comprising in excess of 6,000 banks, which maintains a

widely used inter-bank funds transfer system

* PIDX, the Petroleum Industry Data Exchange committee of the

American Petroleum Institute

* CIDX, the nonprofit electronic standards trade association for the

chemical industry

* Covisint, an automobile-industry technical services company

originally formed jointly by DaimlerChrysler, Ford, General

Motors and Renault-Nissan, as a standards source and trading

portal for auto manufacturers and their suppliers. (26)

Finally, governments have begun to encourage or in some cases even require that certain classes of communication or transaction be conducted electronically. For example:

* The U.S. federal government portals http://standards.gov and

http:// www.xml.gov describe a prodigious and growing number of

implementations of governmental and regulatory electronic exchange,

filing and information services.

* The Securities and Exchange Commission has been managing its

voluminous set of public company reporting data using structured

data standards (specifically, XML and its precursor SGML formats)

for almost a decade. (27) Thousands of companies required to file

are mandated to use this standard, although many may not be aware of

it, due to their use of intermediaries such as a financial printer.

* In perhaps the most interesting development, U.S. federal law has

mandated that a large class of health and insurance-information

related transactions between private parties be conducted and made

available using specific structured information standards and

formats. (28)

DATA STANDARDS THAT EXPLICITLY SUPPLY CONTRACTUAL TERMS

Standard electronic record formats often go beyond the duty of data transmission, and take the place of entire communications or paper documents. Even when the standards are not themselves an explicit part of the deal negotiation, their use may supply rules and constraints that shape and structure the transaction.

Some standards explicitly and directly supply rules, which are incorporated by reference into the transaction terms of exchanges using the standard–whether by a declaration to that effect, or inferred from the invocation of that standard–and thus become part of the enforceable agreement among the parties. For example, financial institutions who conduct transactions using an electronic financial clearinghouse operating under the standards set by the National Automated Clearing House Association (NACHA), (29) may simply by doing so subject those transactions to the provisions of NACHA’s Operating Rules. Those rules import substantial legal, timing, cost and risk-shifting rules into the applicable terms of a transaction conducted over that channel. (30)

Transactional practitioners may need to adjust their expectations when interpreting agreements of this class–by expanding their search pattern from the traditional “four corners” of the document, out into the terms imported by standards whose use invokes them.

IMPLICIT EFFECTS OF DATA STANDARDS ON TRANSACTIONAL RULES

Transaction terms may be affected by the indirect changes wrought by the use of electronic data standards, as well as the terms made explicit in the standard’s documentation. For example: a simple electronic signature standard–call it WhizSigML–might rely on a trusted third party’s certification as the user’s assurance of an identity. Imagine a User B who wishes to do business with another party, A. B receives data to authenticate an electronic document as being signed by putative signer A: the structure of that information is an apparent assertion from a third party C that the data associated with the document is authentically associated with A. The WhizSigML-conformant electronic record that B receives from A must carry a data element referring to the “C” who in a sense has vouched for its source.

The foregoing structure may be perfectly satisfactory, but note that it embeds an assumption that there will be an actual party C who can verify the identity of A, and whose assurance is of sufficient value to B to permit B to rely on the document as A’s. It carries a second assumption that C will understand, when affixing its certification data, the degree to which B expects to rely on C’s act as an enforceable warranty that A is A.

If the first assumption fails if there is no such C for each necessary A–WhizSigs may not be much use to B. This is not a criticism of WhizSigML, rather, merely a limitation of its usefulness. But it can be a problem if B expends effort to implement WhizSigs without noticing that limitation. If the second assumption fails–if C can plausibly assert that he was unaware of the degree of assurance implied by his authenticating act conforming to the WhizSigML standard–then B may not en joy the risk-shifting benefit that motivated her implementation of the standard and justified its cost.

So, when considering implementation of WhizSigML, B faces several questions:

* What limitations and assumptions are stated in the WhizSigML

standard’s documentation? (Does WhizSigML even have documentation?)

* How confident am I that all of the limitations have been

accurately detected by the authors? How confident am I that all of

the limitations known to the authors have been disclosed? Where can

I get assurance or closure about this?

* Do my business needs conform to those limitations and assumptions?

The tidal pull of electronic methods on contract meaning may be even subtler at times. Consider how the mete application of structured information methods may affect interpretive secondary contractual data, in the context of electronic data interchange (EDI).

Current conventional EDI practices emerged in the late 1970s, when groups representing several U.S. economic domains such as the transportation industry, approached ANSI and asked it to establish a set of national standards for EDI exchanges. ANSI established a new committee, denominated Accredited Standards Committee “X12,” according to its numbering scheme. (31) As described in the 1990 ABA Model Trading Partner Agreement article referenced above, (32) businesses were encouraged to make one-for-one substitutions of specific electronic records for legacy paper agreements with legal effect. The X12 committee worked out sets of message code sets to represent specific transaction documents that the proponent industries wished to convert to electronic form. See Figure 2 for several simple examples. X12 has grown to serve many different industries and applications, and has created “transaction set” document-equivalent standards that are maintained and periodically improved. (33)

Similarly, other projects referenced above developed sets of document-equivalent messages to achieve their own business goals. (34)

In many of these early, document-centric standard sets, the electronic document substitutes were intended to be capable of use interchangeably with paper. For example, a buyer and seller might exchange:

* The seller’s paper catalog of items for sale, followed by …

* the buyer’s electronic purchase order, followed by …

* the seller’s electronic acknowledgment (perhaps in response to an

agreed requirement that e-POs will only be enforceable if

acknowledged), followed by …

* the seller’s shipment of goods (and for simplicity’s sake, we will

skip past a large potential additional series of shipper, carrier,

insurance and inspection documents here), followed by …

* the seller’s electronic invoice, stating goods delivered, followed

by …

* the buyer’s paper payment by bank check through the mail, followed

by …

* the buyer’s electronic remittance advice identifying the payment

to the invoice.

Maintaining a one-to-one correspondence between paper documents and their electronic “equivalents” theoretically should reduce the cost of business process adjustments needed to adapt to EDI. For one thing, if there is a close correspondence between the paper and electronic forms, then users should be able to use many of their pre-existing data sources to complete them. Also, EDI’s document-centric approach makes it possible for businesses to adopt new electronic modes in piecemeal fashion, substituting single processes over time, rather than a single, highly-disruptive total conversion.

Yet some say that, after two decades, EDI has never achieved its potential for wide adoption outside of a few, often very centralized industry sectors. Is EDI adoption as easy as had been hoped? Perhaps not, if these theoretically “equivalent” documents prove not to be truly interchangeable in practice. There are some reasons for doubt here.

For one thing, the interpretative methods used to parse meaning from text on paper, drawn from practices accreted over centuries, may not always apply in the same way to electronic “documents” or records. The peculiar application of contract interpretation to e-documentation is an interesting topic itself, but beyond the scope of this Article.

Another reason is the special relationship between a structured data format and a message allegedly conforming to it. Even when a standard does not declare rules for the transactions ii facilitates, the structure that it dictates may heavily influence the interpretation of those transactions.

Consider some typical legal contracts, such as sales contracts, real estate mortgages or term loan agreements. One might generally expect to find repeating terms in any representative of each class, due to a variety of constraining factors, including evolved trade usages, the underlying economic nature of the deal type, and the convergence of market practices towards terms thought optimal.

Thus, for example, somewhere in any term loan, a moderately alert lawyer-reader would usually expect to find a principal amount, an interest rate, a duration, a repayment schedule, some data about the identity of the borrower, the occasions for consequences or default, and so forth–or, if any of those terms were absent, a good reason why. However, in spite of those common elements, the wording and configuration of individual loan agreement texts might vary widely in style and phrasing from author to author and from loan to loan.

When data is presented as structured information, rather than prose text, however, there is less room for elegant variation or ambiguity. Consider a simple hypothetical term loan contract whose terms are wholly structured, as in Figure 3. In such a form, less is left to the vicissitudes of interpretation or text parsing. Instead of being buried in legal prose, the key variables each are framed and exposed, like the heads of wrongdoers in the stockade in a village square. Any terms omitted are absent in an immediately conspicuous fashion

Of equal importance, the glaring absence of an expected term might be read as having more significance than would its failure to appear in a dense forest of text. Traditional contract law rules give courts a set of rules for gap-filling and for identifying the relative importance or centrality of specific terms. (35) This interpretative process assumes that fact finders must navigate amidst the dense verbal fog of natural language. Interpretive methods, and the risk of error, might loom less large in the case of a highly-structured document’s organization and presentation. (36)

As an example from current actual practice, consider the truncated forms of agreement provided in the forms developed by the International Swaps and Derivatives Association, Inc. (ISDA). ISDA’s standard methods dictate a short deal slip (“schedule”), stating key metrics, and otherwise look to a pre-existing, standard form Master Agreement for the bulk of deal terms. (37) In this way, a brief, efficient communication accomplishes the swap contract, while keeping the majority of re-usable routine terms safely standardized and efficiently out-of-band, (38) in a separate instrument. Arguably, in the U.S. residential mortgage industry, the homogenizing forces of automation cost savings and secondary market securitization requirements are causing the same kinds of changes. In that field, an entire legal industry of individually-negotiated contracts seems to be commoditizing into highly standardized forms. (39)

In that industry and others, current contracting practices increasingly may be moving closer semantically, and even syntactically, towards computable structured information methods.

INVISIBLE OR STRUCTURAL EFFECTS OF DATA STANDARDS ON CONTRACTS

Finally, even in cases where no effects on deal terms are stated–or intended–a standard’s own dependencies, assumptions and biases structurally may impose constraints on a contract or project that invokes it.

This is essentially the “embedding” phenomenon mentioned in Professor Lessig’s widely-cited book, Code And Other Laws of Cyberspace:

I’ve been speaking of two sorts of code. One is the “code” that

Congress enacts … The other is the code that code writers

“enact”–the instructions imbedded in the software and hardware that

make cyberspace work. (40)

Traditional legal rights (such as property boundaries, of copyright) are enforced and enabled informally by devices and installations (such as fences, or copy-prevention technology). A property law is not a fence, nor vice versa. A property owner who fences in property that is not his, usually has not changed the legally enforceable property line, at least for a while. Yet, in practice, a person traversing the parcel may be far more affected by the presence of an electric fence than by an invisible demarcation. It is true that the theoretical rights of the user may not be affected by a wrongfully-placed fence. Nevertheless, whether rightly or wrongly, the fencer has interposed a fairly effective obstacle, which increases the transaction cost of trespassing the fencer’s desired rules. (41)

In the context of structured information standards, a formal scheme that constrains the world of possibilities down to a few required or permitted data elements is making assertions about the completeness and appropriateness of information. Returning to Figure 3, the design of this (very hypothetical) loan contract form implies that no other terms need be made variable, and so exposes no others to explicit manipulation by contracting parties. If that implication is correct for some class of users, they may find the form useful. But what if the assumption is wrong? At a minimum, some variables or terms that should be made manipulable are inconveniently fixed, as a moderately immutable feature of the process that collects them, making them not just erroneous, but embedded errors.

A data standard always includes some assumptions and biases about the real world matters it expresses. Those assumptions may be explicit, unstated, or stated inaccurately It is for users (and their lawyers, when reviewing a contract which embeds standards) to consider whether a particular standard is logically consistent with the intended results, and what assurances of that consistency and reliability are available.

RECOGNIZING MULTIPLE STANDARDS IN A SINGLE APPLICATION

Another important step in analyzing the effect of data standards on a particular project is issue-spotting. How many standards actually have strategic significance to a particular contract or system? There may be more than are immediately apparent.

Figure 4 roughly illustrates the presence of multiple standards influencing a single eventual installed system. As a project moves from theory to reality, its ability to conform to, and weave together, its multiple data structures might start as discrete segments, which are validated first individually and then in varying combinations, before being aggregated into a complete system. In some cases, the collective interoperation of all of the various standards employed might not be fully tested until the system is used in live production.

[FIGURE 4 OMITTED]

Most information technology projects are likely to use a series of standards at various levels of functionality. Some directly manipulate business data important to the user–

* What’s the purchase order number?

* Who authorized the shipment?

* Are we required to authorize payment as soon as we receive a

certificate of delivery?

while others act below the waterline to keep the communications and their meaning in order–

* The confirmation came back incomplete, try again.

* Display this differently, it’s being read on a mobile phone

screen.

* Find the identity server that can authenticate a message

containing binding changes to orders from Foo, Inc.

The “waterline” in Figure 4, and the basic distinction made by the foregoing examples, is loosely based on a categorization first articulated in the Open-EDI Reference Model (ISO/IEC 14662) issued by a special joint committee on Information Technology (JTC1/SC32) of ISO and IEC. (42)

Like any other map or classification scheme, it represents only one view into a world of possibilities. Any representation of this informational space has its limits. Maps represent their author’s view of reality, just as the classic 1976 Saul Steinberg “map” cover for The New Yorker (43) depicts Manhattan’s West Side in vivid detail. Yet the map makes the Pacific Ocean the same size as the Hudson River, and sees nothing between New Jersey and Los Angeles other than Kansas City, Las Vegas and a few rocks. Undoubtedly, the Open-EDI model has its own biases. Still, it has quite a few qualities to recommend it. One is that it concentrates on the aspects of e-commerce communications most relevant to contract formation, and thus interesting to us for purposes of this Article. The other is that its core concepts have proven sufficiently useful that they have been incorporated into a large number of later e-commerce mapping efforts. So its view into the universe of e-business standards may be a helpful one. The Open-EDI scheme’s basic view of visible (business term) and submerged (technical) standards is more explicitly illustrated, in a simplified form, in Figure 5.

It should be fairly obvious from Figure 5 that many transactions are likely to rely on multiple data specifications rather than a single one. The categories of standard in the right column of Figure 5 (“TRANSACTIONS” through “XML SYNTAX”) are merely generalized samples not intended to be complete or even representative. They will, however, suffice for a quick example of the multiplicity of standards that may influence a single series of transactions.

An electronic transaction conducted over TCP/IP and using URI Internet addressing may be sent in several forms, such as an SMTP electronic mail message or an HTTP web form. (Four basic IETF standards so far, all from our footnote 2, and we have not yet even reached the level that is mapped on Figure 5). The content may be composed of standardized elemental data and invoke specific predefined functions (e.g., using RosettaNet’s PIPs of ANSI X12 documents, CONTENT & PROCESS LAYERS) which assemble into re-usable instances and patterns (TRANSACTION LAYER). During those exchanges, the degree of authentication, confidentiality and priority of delivery may be explicitly asserted (e.g., using an OASIS SAML assertion of ITU X.509 certificate, SECURITY AND MANAGEMENT LAYERS), and may vary from message to message. And so on. The content itself requires structure (such as a DTD or W3C’s XML Schema, XML SYNTAX LAYER), and each communication is likely to be given a specific message of page structure (e.g., W3C’s SOAP or OASIS’s ebXML MSG, MESSAGING LAYER). A series of transactions is often likely to require some inquiries regarding the location (OASIS’s UDDI or ebXML RegRep, REGISTRY/DIRECTORY LAYER) or nature (e.g., W3C’s WSDL, SERVICE DESCRIPTION LAYER) of specific services. Often there are multiple valid alternative paths, or combinations of approaches, to fulfill the intended data structure of an electronic business exchange. (44)

[FIGURE 5 OMITTED]

So a single data-dependent project may have dependencies on multiple standards, and be vulnerable to the attributes of each. A user who designs of contracts for a system that assumes the use of standards must consider the assumptions, dependencies and biases of each of those standards. Depending on the risks expected and functions desired, closer inquiry into their quality and reliability may be appropriate. How to assess those attributes? This is the subject of our next and final section.

METASTANDARDS: HOW ARE STANDARDS EVALUATED? WHICH ONES SHOULD I USE?

What criteria may be used when evaluating data standards that affect the content of contracts and transactions? It may be helpful to see how governments and others are assessing and responding to these questions. Some governments have expressed opinions about the way that standards processes should work, through statues, regulations of purchasing practices that include preferences or requirements for standardized technology.

FUNCTION OVER BRAND: TECHNOLOGY-AND VENDOR-NEUTRALITY

Technology-neutrality as a legal rule is visible in The Electronic Signatures in Global and National Commerce Act (“E-SIGN”), a key e-commerce statute that federalized some United States laws on electronic signature validity. (45) E-SIGN employs a carefully vendor-neutral definition of electronic signatures, written in terms of functionality rather than product of method, and thus avoided differential treatment among methods or vendors. (46) In this regard, it followed the United States modal law on which it was loosely based, the Uniform Electronic Transactions Act, (47) adopted in 1999 by the National Conference of Commissioners on Uniform State Laws, and enacted in a majority of the U.S. states (over forty at this writing). E-SIGN goes further: the statute explicitly pre-empts (invalidates) any related state legislation that would prefer of promote a “specific technology of technical specification” for generating enforceable electronic signatures. (48)

A number of other jurisdictions also are including explicit technology-neutrality of vendor-neutrality clauses in their rules and procedures. (49)

ECONOMIC ACCESS AND DEVELOPMENT

This evolving bias towards nonproprietary standards in some government sectors may be related to concerns about access to technology, economic development and barriers to market entry by developing economies, small-to-medium scale enterprises (SMEs) and entrepreneurs. Global economic development experts identify information and communication technologies (ICT) as a central resource for the development of disadvantaged economies and peoples, for a variety of reasons including the expansion of informational access and empowerment towards greater inclusiveness

TRADE BARRIERS AND THE WTO STANDARDS “CODE”

Increasingly, governments use standardization requirements as a tool in combating local or regional bias in international trade markets. Protective nations might seek to favor local suppliers of a good or service by imposing idiosyncratic local specifications. As one response to this, members of the World Trade Organization (WTO) in 1995 entered into an Agreement On Technical Barriers to Trade (the “TBT Agreement”). (52) Of special interest to this discussion is the TBT Agreement’s clause 4.1, in which signatory governments agree to encourage standardizing bodies in their countries to accept and comply with a “Code of Good Practice for the Preparation, Adoption and Application of Standards,” embodied in Annex 3 to the Agreement. (53)

The self-named “Code” begins with adjurations that standards bodies should not favor local products or promote rules that have disparate effect on foreign suppliers. It then moves on to broader harmonization goals, and articulates specific process requirements, including the following:

* Standards bodies should re-use existing international standards

where suitable, instead of building new or parallel ones, and

should participate in the international efforts where feasible.

(54)

* Standards bodies should specify standards in terms of function

rather than supplier, i.e., “based on product requirements in

terms of performance rather than design or descriptive

characteristics.” (55)

* Standards bodies should publicly post their work program at least

every six months, and provide copies to an ISO/IEC clearinghouse

for discovery and coordination purposes. (56)

* Standards bodies should conduct public review periods for at least

sixty days before adopting a standard, make copies publicly

available, and provide notice of those reviews to a central

location. (57)

* Standards bodies should note where their proposed drafts deviate

from pre-existing international standards, explain why, and log

and respond to comments received in public review. (58)

As the reader can readily see, the WTO signatories expect standards bodies to cooperate

GOVERNMENT USE OF CONSORTIA STANDARDS: OMB’s CIRCULAR A-119

This government sentiment is not limited to the context of foreign trade barriers. The U.S. federal government operates under a directive from the Office of Management and Budget (OMB), Circular No. A-119, originally issued in 1993 and most recently updated in February of 1998, which directs all federal executive governmental agencies to use voluntary information technology standards in their procurement and regulatory activities, wherever practicable. (59)

The OMB directive is fairly clear about participation in and re-use of ongoing standards work:

If a voluntary consensus standards body is in the process of

developing or adopting a voluntary consensus standard that would

likely be lawful and practical for an agency to use, and would

likely be developed of adopted on a timely basis, an agency should

not be developing its own government unique standard and instead

should be participating in the activities of the voluntary consensus

standards body. (60)

The document’s definition of a “voluntary consensus standards body” lists a number of required attributes, including openness, balance of interest, due process, an appeals process for decisions, and consensus, and makes a distinction between (favored) SDOs who practice these virtues, and those other efforts that may not practice them. (61)

Recently-introduced federal legislation would take these concepts further and bring more of an evaluative tone into the federal government’s standards practices. H.R. 1086, the “Standards Development Organization Advancement Act of 2003,” was introduced in the 108th Congress, adopted by the House of Representatives on June 11, 2003, and at the time of this writing (late July) is presently before the Senate. (62)

The principal purpose of the bill is to broaden explicit statutory relief from antitrust laws for the activities of voluntary consensus standards efforts. (63) In its definition of an adequately open standards process, however, it purports to restate, but may actually extend, the criteria in the OMB circular. Among the H.R. 1086 criteria are requirements of:

* notice to all parties known to be affected, and sufficient access

to participate,

* “balance” to the extent necessary to prevent standards development

from being “dominated by any single group of interested persons,”

and

* consensus procedures that reach “substantial agreement … on all

material points after the consideration of all views and

objections.” (64)

The foregoing requirements may be a more discerning and quantifiable set of rules than were the general platitudes of Circular A-119. Whether they clarify of modify the OMB rule, they do provide some useful checklists to potential users of a standard (and their lawyers). It may be worth noting that similar principles also arise within some private industry activities. For example, the Chemical Industry Data Exchange describes its own orientation as follows:

Three principles guide CIDX’s development and release of standards.

Standards must be:

* open–available free of charge to members and non-members without

royalties or licensing fees

* neutral–to support current and emerging business models

* platform independent–to prevent restricting the use of any

hardware of software platform (65)

The various renderings of these definitions demonstrate that “openness” and “neutrality” are important–and also that they may mean different things to different people.

GENERALIZED CRITERIA FOR STANDARDS: SUITABLE, RELIABLE AND AVAILABLE?

When software users and their lawyers evaluate using a standard as part of the critical path for their project, business or contract, it might be useful to organize their inquiry around some basic queries:

* Suitability: Does the standard meet the proposed use’s business

requirements? Is it sufficiently interoperable?

* Reliability: Does the standard’s development or “pedigree” have

sufficient process integrity and robust review?

* Availability: Can the user obtain stable access and sufficient use

rights from known owners of the work?

Suitability

A standard that is designed to do something inconsistent with your client’s needs may not be a good choice. As noted earlier, any data specification will have its own embedded assumptions and biases. Designers and customers who note the mandatory use of an unfamiliar specific data standard as a central requirement in their project or agreement might do well to ask:

* How it is used? Is the proposed use consistent with the standard’s

stated and demonstrated functionality?

* Why was it chosen for this project?

* Under what similar circumstances has it been deployed in actual

production uses?

* How are conformance tests conducted? What do they measure?

* What other dependencies or assumptions does it require?

Assurances regarding these matters may be stated in the standards documentation itself–although disclaimers there may make them more a matter of comfort than a warranty. Assurances, testing and warranties might in some cases also be available from sources, vendors or third parties. Some standards will make available official conformance testing criteria, which enable concrete tests of an assertion that an implementation correctly performs according to a designated data standard. Users also may ask vendors for lists of known variances from fidelity to a key stated standard, and in some cases may wish to inquire further about the reasons for the variances.

Often a prospective user should consider the fundamental business requirements of her planned implementation before selecting a data structure. In some cases, it may be helpful to pay special attention to functional, rather than brand-name or exemplary, descriptions of desired features of a standard or system. Smart buyers of many services consider neutral analysis of business requirements before examining specific solutions or vendors

Earlier we noted the frequent confluence of multiple standards brought to bear on a single project. This common phenomenon makes interoperability a key business requirement for many projects. Some data specifications are designed to be used with any–or only with certain–other designated standards or systems. It might be well to know this in advance. Professors Shapiro and Varian suggest that there is a shortage of angelic nature in the standards marketplace

Reliability

Short of a definitive test, which may not be available, what can a user employ to evaluate the likely quality and stability of a data standard? It is instructive that most of the government works discussed in this short Article focus on the fairness and inclusiveness of an SDO’s development process. Presumably a specification that has been exposed to wider input and criticism, and genuinely has taken it into account, is more substantively robust. That assumption may explain the use of process quality as a proxy for substantive quality–and the frequently cited virtue of “openness.”

“Openness” is a much-desired and much-claimed quality for standards. But open to what? Two possible concrete measurements are the permeability of the standard to outside input (process integrity) and the breadth of input actually received (robust review). (67) A prospective user who lacks the expertise to judge the technical quality of a specialized standard might, nevertheless, obtain indirect comfort about its merit from the probity and reputation of the process that produced it, or the expertise and breadth of the participants actively involved.

As noted earlier, standards development organizations each operate according to their own set of procedures. A given organization’s roles may be stricter or narrower, slower or faster, or to greater or lesser degrees susceptible to influence from particular quarters. These qualities may be in part discernible from rules, or indirectly from reputation or output.

Perhaps the core inquiry here is about the evenhandedness of the process leading to the standard in question. Are all opinions allowed to be heard? Are roles clear, and followed? Are comments logged, and offered the courtesy of a response or disposition? Are decisions made in a visible, clear and objective manner? SDOs are by definition voluntary, so they have few binding remedies with which to work. (68) On rare occasions, data standards are enacted into law and become the subject of legal mandate. But the majority seem likely to remain voluntary This does not mean there are no remedies, only that the SDOs are not likely to be their source. (69) As noted above, specific standards may find their way into enforceable legal schemes

Another common theme in the governmental policies noted above is the value of a “consensus” process. Whether this is interpreted to mean unanimity, or supermajority rules for approval, or something else, may vary from SDO to SDO. There are perhaps hundreds of SDOs today, under the broadest definition of any organization creating common specifications. Prospective users and participants may wish to perform some diligence or review of information about an unknown standards source, before committing substantial resources to its process or product. Professor Lessig has suggested that the expansion and privatization of this field raise new concerns:

We are just leaving a time when the code writers are a relatively

independent body of experts and code is the product of a consensus

formed in forums like the Internet Engineering Task Force (IETF)….

[T]hey were in one sense disinterested in the outcomes: they wanted

to produce nothing more than code that would work. We are entering a

very different world where code is written within companies

standards are the product of competition

dominant standard have advantages. We are entering a world where

code is corporate…. To the extent that this code is law, … we

should worry about how it is structured and whose interests may

define its constraint. … If code is law, who are the lawmakers?

(70)

From the perspective of a commercial lawyer rather than a constitutional law professor, it may seem less likely that all things that come from companies are bad, and that all things that are bad come from companies. Even in wholly volunteer bodies, noneconomic phenomena such as pride of authorship or fiercely held technology preferences, may be just as capable of skewing a standards debate as are financial interests. (71) Still, the professor’s warning that users of a standard should consider its sources and biases is unimpeachably correct.

Separate from the question of a process’ fairness is its inclusiveness. One aspect of this quality is a meaningful public review. Most of the government rulesets noted in this Article conclude that a routine public review opportunity is necessary to an adequately robust process. This gives such experts or interested parties as may exist an opportunity to be heard, whether or not their views (or existence) are known to the group authoring the work. The opportunity for such access is important. Note, however, that even the most sincere and aggressive efforts to obtain public comment may sometimes reap little response, particularly in highly specialized topics. (72)

In projects that cross functional domains, SDOs also may face choices regarding liaisons, coordination or reconciliation between multiple existing standards or SDOs. Practices vary here also: some organizations absolutely require unanimity among multiple implicated domains

Availability

Finally, when evaluating a prospective investment of time and money in a standard, one important factor is the extent to which a user or participant will have persistent and meaningful access to the work in question. Consider three different sources of claims or rights against the work: the SDO itself, nonparticipant third parties, and individual SDO participants.

The Rights of the Standard’s SDO, Owner or Steward. One threshold question is whether a specification is owned and managed in a way that will support reasonable reliance over a sustained period of time. Aspects to consider include the following:

* Who actually owns and holds the copyright in the definitive

standard? Is that publication itself available? How readily

available is it in practice? Has the owner made an irrevocable

commitment to keep it permanently so? (73)

* Is the owner or steward for the standard reasonably likely to

remain stable?

* If the standard is expected to need maintenance or revision over

time, is there some assurance that the owner or steward will be

able, and inclined, to do so?

Determining that a standard’s owner or steward has proper title to its content, and likely will keep it published, is useful but not the end of the inquiry A prospective user must also inquire whether it is legally required to obtain a license or permission in order to implement or use a standard.

A user likely will wish to know what conditions, if any, will be placed on his use of a data standard by the SDO owning or maintaining it. Many SDOs explicitly promise that they will not restrict the use of standards they publish, nor themselves require licenses or royalty payments. (74) Note, however, that this is not the same thing as assuring whether others will claim rights, discussed below.

Not all SDOs make their works available without cost, however. A number of industry-specific organizations, particularly, elect to charge royalties, limit use to fee-paying members, or similarly keep their standards out of free public circulation. This tends to be more common among commercial projects than for nonproprietary membership-based organization: members of voluntary efforts may be less inclined to put time and work into a composite specification, if it later will be offered only for profit that accrues to a select few. However, there is nothing intrinsically wrong with the business model or quality assurance of for-profit data specifications. Plans to use such specifications simply should take into account the expected licensing costs and the risk of future increases to those charges.

A third model, that is neither precisely an SDO nor a for-profit effort, is open source of free standards development. These projects often proceed from works subject to GPL-type licenses patterned after the GNU GPL of Open Source Initiative models. (75) Many GPL-type license include unique characteristics that explicitly encourage further development and derivative work, but subject to specific constraints on profit-taking that must be considered in any implementation plans. (76) Those aspects of GPL-licensed work may sometimes induce the formation of an official community built around a work, or simply a loosely coupled group of spontaneous contributors.

The Claims of Unknown Third Parties. Most standards organizations are unable to assure a user that some third party will assert a hitherto-unknown infringement claim against some aspect of the standard in the future. There have been a number of publicized examples where a standard was unexpectedly attacked as an infringement of a later-asserted claim.

For example, the ISO/IEC 10918-1 image standard, known as “JPEG” and historically used by practically every major commercial web browser and most consumer imaging software programs for about a decade, struggled recently with an unexpected patent assertion against its methods. The claim moved the ISO committee to consider withdrawing the standard, regardless of the likely validity of the patent, in order to avoid liability. (77) Even widely-used open source of free software is not immune to the risk that an unexpected claim will be made against it

Of course, this risk is not unique to data standards. Any enterprise carries a risk of future impairment by as-yet-undisclosed claims of patent, copyright or other exclusive ownership. Systemic uncertainty about the actual enforceability of software and business process patents makes practical risk assessment even more difficult, when reviewing data structure standards. (79) This is especially true for participants who are not patent portfolio owners themselves, and thus not in a position to buy peace in this uncertain battleground through an industry cross-licensing program. (80) Potential participants in a standards process must take these risks into account in their own planning.

In the face of this uncertainty, SDOs often choose not to conduct patent or similar searches. Instead, many SDOs rely on a passive disclosure policy whereby they request or require the members to disclose claims (about which more shortly), and then post the results uncritically and publicly. (81) Most SDO policies include explicit disclaimers of infringement risk assurance. (82) Essentially, in this model, the SDOs facilitate but do not assure claim disclosure: each user is on his own to perform such diligence about possible adverse claims as he may choose.

The Claims of Contributors. A standard’s owner or SDO host is not the only “insider” claimant a user must consider. Any participant in the creation of a standard is in some sense contributing intellectual content. Were there no rules about reserving common law, copyright or patent rights work might emerge from SDOs with routine complex encumbrances, with the result that multiple parties could erect a toll bridge over use of the standard, by using their claims either to collect royalties or threaten infringement action: “One of the worst outcomes for consumers is to buy into a standard that is widely expected to be open, only to find it ‘hijacked’ later, after they are collectively locked in.” (83) Threats of infringement could be used as a lever to sway standards projects towards one’s own needs, or to delay or thwart standards developments that an individual participant finds competitively unattractive.

To address this risk, a few SDOs actually bar the inclusion of encumbered contributions. Many take a middle position, however, by requiring their members to disclose any known claims against a standard prior to its approval. Section 10 of the IETF’s RFC 2026 is a useful example of an open-oriented SDO’s procedure for doing so. (84)

This might be regarded as the “caveat emptor” approach to the risk of future claims. Many SDOs also reserve in their policies the right to seek, or in some cases demand, a prophylactic license from claimants, as a partial cure for the perceived obstacle of a discovered claim. The terms of licenses offered by contributors vary. Some require explicit written application and may be highly conditional. These require the applicant to evaluate the terms, conditions and revocability, and whether it is willing to advise the licensor of its planned use, prior to making a commitment. Others may be relatively unqualified, open-ended licenses which are “self-executing,” in the sense that they require no individual application or further documentation. One example of this latter approach can be found in IETF RFC 2339, in which a company licenses a specific Internet technology to the IETE. (85) GPL or similar open source licenses, mentioned above, (86) also are often self-executing.

Disclosure and licensing rules of SDOs may vary widely, (87) and as voluntary organizations, their ability to enforce those rules may be limited. However, the SDOs generally are noncombatants: primary, the rules permit self-help, by setting a disclosure standard that can be enforced among competitors if violated via a fraud claim or regulatory sanctions (as noted in the following section). Users and participants often must reach their own determinations on what is adequate. Shapiro and Varian warn:

Beware of vague promises [of openness] … make sure early on that

[other] holders of key patents are explicit about their commitment

to license for “reasonable” royalties. Reasonable should mean the

royalties that the patent holders could obtain in open, up-front

competition … not the royalties that the patent holder can extract

once other participants are effectively locked in [by a standard].

(88)

Governmental agencies and inter-competitor lawsuits occasionally step in to provide a remedy, when disclosure obligations are deliberately breached, (89) or misleading claims are made. (90) These regulatory and court actions serve as reminders that misleading behavior by SDO participants may be the focus of court and regulatory activity–and that the likely results of such enforcement attempts are hard to predict.

In summary, ultimately users should verify, not assume, whether a data structure offered as a “standard” is in fact available for use and implementation without known risk of infringement. The rules of SDOs often encourage public disclosure of any claims, but do not necessarily assure that all claims will be detected of disclosed.

As automated electronic business becomes more commonplace, the meaning and enforceability of commercial transactions will increasingly rely on the terms, assumptions, and design of embedded structured information standards. Evaluating their inclusion in a deal, and understanding their effects, will be a critical skill set. Understanding the sources and development of data standards, tracing their explicit and implicit effects on contractual terms, and analyzing their suitability, reliability and availability, may make this task easier.

FIGURE 2 Document-Centric Equivalencies

An ANSI ASC X12 850 is the …a paper purchase order, i.e., offer to

e-equivalent of … buy, usually at a stated price

An ANSI ASC X12 810 is the …a paper invoice, i.e., the seller’s

e-equivalent of … list of items sold

An ANSI ASC X12 835 is the …a remittance advice informing the

e-equivalent of … recipient what a payment was for

An ANSI ASC X12 997 is the …a message recipient’s acknowledgment

e-equivalent of … of message receipt

FIGURE 3 Hypothetical Truncated Loan Agreement

Principal amount: Legal name of borrower:

Interest rate: Legal entity type:

Date of advance: Jurisdiction of organization:

Scheduled maturity: Principal office location:

Periodicity of payments of Authorized representative:

accrued interest: GAAP net worth:

All terms set for in [external standard reference] apply to this loan

transaction and are incorporated in this record.

[signature] [signature]

(1.) “Usually” because there are some indications that governments are increasingly actively mandating standards use, in some regulated activities and when a government entity acts as purchaser.

(2.) Historians may quibble over this list, but there six fairly obvious candidates: the Simple Mail Transfer Protocol (SMTP), currently IETF RFC 2821, see Internet Engineering Task Force, Request for Comments 2821, Simple Mail Transfer Protocol, at http://www.ietf.org/rfc/rfc2821.txt

(3.) The Fortune of the Commons, THE ECONOMIST, May 8, 2003 available at http://www.economist.com/surveys/displayStory.cfm?Story_id=1747362.

(4.) On interoperability, see infra text accompanying note 44.

(5.) See, e.g., jack E. Brown, Technology Joint Ventures to Set Standards or Define Interfaces, 61 ANTITRUST L.J. 921 (1993)

(6.) CARL SHAPIRO & HAL R. VARIAN, INFORMATION RULES

(7.) Another U.S. agency worth special mention is the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST), which does not generally issue its own standards, but does provide direct support, analysis and testing services to a wide variety of domestic standards-related efforts. See generally http://www.nist.gov (last updated Oct. 2, 2003).

(8.) These agencies are party to a Memorandum of Understanding Concerning Standardization in the Specific Field of Electronic Business (the “E-Business MoU”) that establishes coordination mechanisms to limit overlap of duplication. Memorandum of Understanding Concerning Standardization in the Field of Electronic Business, Mar. 24, 2000, International Electrotechnical Commission, International Organization for Standardization, International Telecommunication Union & United Nations Economic Commission for Europe, at http://www.itu.int/ITU-T/e-business/files/mou.pdf. UN/CEFACT, the trade facilitation branch of the United Nations Economic Commission for Europe (UN/ECE), and the originator of the EDIFACT international set of electronic data interchange (EDI) messages, is also a signatory to the E-Business MoU, along with the Organization for the Advancement of Structured Information Standards (OASIS), the Society for Worldwide Interbank Financial Telecommunication (SWIFT) and several others mentioned later in this Article.

(9.) Shapiro and Varian, supra note 6, at 10.

(10.) At this writing, most of the SDOs, including ISO, http://www.iso.ch, through its national affiliates such as ANSI, http://www.ansi.org, OASIS, http://www.oasis-open.org, OMG, the Object Management Group, http://www.omg.org, W3C, http://www.w3c.org, and other standards-related consortia such as The Open Group, http://www.opengroup.org, charge membership fees, with organizational dues varying from $1,000 to over $60,000. Some have a relatively low-cost individual member rate as well IETF, the Internet Engineering Task Force, http://www.ietf.org, and UN/CEFACT, http://www.unece.org/cefact/, charge no fees and so can be joined without cost

(11.) See RosettaNet at http://www.rosettanet.org.

(12.) See SWIFT at http://www.swift.com.

(13.) See The Open Group at http://www.opengroup.org.

(14.) See The Java Community Process at http://www.jcp.org.

(15.) The Fortune of the Commons, supra note 3. See also Mark A, Lemley & David McGowan, Could java Change Everything? The Competitive Propriety of a Proprietary Standard, 43 ANTITRUST BULL. 715, 717-18 (1998).

(16.) Shapiro and Varian, supra note 6, at 11-12, 46-7.

(17.) Electronic Messaging Service Taskforce, The Commercial Use of Electronic Data Interchange: A Report and Trading Partner Agreement, 45 BUS. LAW. 1645, 1724-25 (1990).

(18.) The Task Force reported two principal conclusions. One was that then-existing legal rules for contract formation, validity, and interpretation were inadequate for assuring reliable enforceability of contracts formed electronically. The other was that trading partners wished their electronically formed contracts to enjoy the same level of validity and reliability as traditional paper contracts, which might be achieved by a sufficient physical “trading partner agreement” preceding the electronic contracts. See id. at 1654, 1659, 1680. The report attached a Model Trading Partner Agreement offered to meet that need. The model identified and proposed resolutions for key issues that are taken for granted today, but representing advanced thinking for its day, including the explicit negotiation of the formats, standards and channels over which data would be transmitted. See id. at 1717-49.

(19.) Mortgage Brokers Association of America, eMortgage Guidelines and Recommendations Release 1.0 at http://www.mismo.org/mismo/emgr_10.cfm.

(20.) See http://www.walmartstores.com/wmstore/wmstores/Mainsupplier.jsp? categoryOID=-8888&catID=8250&template=SubCntDisplay.jsp. See also, e.g., Richard Karpinski, Wal-Mart Mandates Secure, Internet-Based EDI For Suppliers, INTERNET WEEK.COM (September 12, 2002), available at http:// www.internetweek.com/story/showArticle.jhtml?articleID=6400516

(21.) See RosettaNet, supra note 11, al http://www.rosettanet.org/.

(22.) See Bolero, at http://www.bolero.net/aboutus/corporate/index. php3?printable=1.

(23.) See SWIFT, supra note 12, al http://www.swift.com/.

(24.) See American Petroleum Institute, at http://committees.api.org/ business/pidx/description.html.

(25.) See CIDX, at http://www.cidx.org/aboutCIDX/CIDXOverview.asp.

(26.) See Covisint, at http://www.covisint.com/about/.

(27.) Computer Science and Telecommunications Board, Commission on Physical Sciences, Mathematics, and Applications, White Paper: Technology Issues Associated With Modernization of the Securities and Exchange Commission’s Electronic Data Gathering, Analysis and Retrieval (EDGAR) System (National Research Council, February 1996), available at http://www7.nationalacademies.org/cstb/whitepaper_sec.html. On current rules and procedures, see http://www.secgov/info/edgar.shtml (last modified Sept. 5, 2003).

(28.) See Health Insurance Portability and Accountability Act of 1996 (HIPAA), P.L. No. 104-191, 110 Stat. 1996 (codified at various sections of Titles 26, 29, and 42 U.S.C.). See also 65 Fed. Reg. 50,312 (Aug. 17, 2000) (the final HIPAA transactional regulations, which specifically reference mandated ANSI ASC X12 specifications amending 45 C.F.R. Pts. 160, 162).

(29.) See NACHA at http://www.nacha.org.

(30.) NATIONAL AUTOMATED CLEARING HOUSE ASSOCIATION, 2001 ACH RULES, NACHA Operating Rules OR1 available at http://achrulesonline.org

(31.) See ANSI ASC X12 at http://www.x12.org (committee site)

(32.) See Electronic Messaging Service Taskforce, supra notes 17-18.

(33.) See ANSI ASC X12 at http://www.x12.org/x12org/index.cfm.

(34.) The Bolero.net project, http://www.bolero.net, created electronic XML-based data representations of documents commonly used in its trade finance and shipping domain, such as purchase orders, documentary credits, standby documentary credits, air waybills, inspection certificates, export licenses, advance ship notices, purchase orders and bills of lading. The RosettaNet electronics-industry consortium, http://rosettanet.org, has declared a RosettaNet Implementation Framework[R] (RNIF) core specification that includes a detailed and robust set of Partner Interface Process[R] (PIP) transactional message specifications. See http://rosettanet.org/RosettaNet/Rooms/Display Pages/LayoutInitial? Container=com.webridge.entity.Entity[OID[AE9C86B8022CD411841F00C04F689339]]. See also supra notes 21 and 22 and accompanying text.

(35.) See generally E. Allan Farnsworth, Disputes Over Omissions in Contracts, 68 COLUM. L. REV 860 (1968)

(36.) See William J. Woodward, Jr., Neoformalism in a Real World of Forms, 2001 WIS. L. REV. 971 (2001), and Russell Korobkin, Inertia and Preference in Contract Negotiation: the Psychological Power of Default Rules and Form Terms, 51 VAND. L. REV. 1583 (1998).

(37.) See the ISDA MASTER AGREEMENT (2002 ed.), at http://www.isda.org/ publications/isdamasteragrmnt.html.

(38.) “Out of band,” in the sense that the fixed terms are present only by incorporation from a separate source

(39.) See James Bryce Clark & Maura B. O’Connor, An Overview of Electronic Mortgage Origination and Recording Issues, 1 PLI COMMERCIAL REAL ESTATE FINANCING 2003 No. 490 at 175 (Practising Law Institute 2003).

(40.) LAWRENCE LESSIG, CODE AND OTHER LAWS OF CYBERSPACE 35 (Basic Books 1999).

(41.) Beyond the obvious analogy of a misplaced fence, there is an entire branch of tort law, known to most first-year law students as the “spring gun” cases, devoted to the consequences and remedies associated with placing deterrents in situations when perhaps you ought not do so. See, e.g., Katko v. Briney, 183 N.W.2d 657 (Iowa 1971)

(42.) International Organization for Standardization, ISO/IEC 14662, Information technology-Open-edi reference model (1997), at http://www. iso.ch/cate/d25154.html. The model extends considerably beyond document-centric systems in spite of the “edi” reference in its name. See also the ongoing work on ISO/IEC 15944, Information technology-Business agreement semantic descriptive techniques, which addresses implementations of the abstract 14662 model, available at http://www. iso.org/iso / en/ stdsdevelopment/techprog/workprog/TechnicalProgramme ProjectDetailPage.TechnicalProgrammeProjectDetail?csnumber=33322.

(43.) Saul Steinberg, THE NEW YORKER, March 29, 1976, at front cover, available at http://www.cartoonbank.com.

(44.) These are merely general, illustrative examples, and are neither recommendations nor assertions that specific protocols or combinations are optimal. Any one of the foregoing standards can be further explored by the curious by performing a web search on its colloquial name listed above. Only completed and currently-available final specifications are mentioned here

(45.) Electronic Signatures in Global and National Commerce Act (ESIGN),15 U.S.C. [subsection] 7001-7031 (2000).

(46.) See id. [section] 7006(5).

(47.) Unif. Elec. Transactions Act (UETA) [subsection] 1-21 (2002).

(48.) ESIGN, [section] 7002(a).

(49.) For example, model rules established by the State of Texas for county clerks to use in accepting electronic public filings require “generally available, nonproprietary technology” including nonproprietary file formats. TEX. LOC. GOV’T CODE ANN. [section] 195.002(b)(4)(5) (Vernon Supp. 2003)

(50.) See CARLOS A. PRIMO BRAGA, ET AL., THE NETWORKING REVOLUTION, OPPORTUNITIES AND CHALLENGES FOR DEVELOPING COUNTRIES 10-11, 23 (The World Bank Group, Working Paper, June 2000) available at http://www. infodev.org/library/ WorkingPapers/networkingrevolution.pdf

(51.) See, e.g., Nadadur Janardhan, Business Facilitation Needs, ELECTRONIC COMMERCE INITIATIVES OF ESCAP, U.N. Doc. E.98.II.F.47 (1998).

(52.) The full text of the TBT Agreement can be found at World Trade Organization, Agreement to Technical Barriers of Trade at http://www.wto.org/english/docs_e/legal_e/17-tbt.pdf. Further discussion and background about the TBT Agreement is available from the WTO at http://www.wto.org/english/tratop_e/tbt_e/tbt_e.htm, and from US government sources at http://ts.nist.gov/ts/htdocs/210/ncsci/tbtmotif.htm (last updated Nov. 18, 2002), and http://www.ustr.gov/wto/goodtech.shtml.

(53.) See TBT Agreement, supra note 52, at 120.

(54.) Id. at 135, [sub paragraph] F,G,H.

(55.) Id. at 136, [paragraph] I.

(56.) Id. [paragraph] J.

(57.) Id. [sub paragraph] L,M.

(58.) Id. [sub paragraph] L,N.

(59.) Office of Management and Budget, Circular No. A-119, available at http://www.whitehouse.gov/omb/circulars/a119/a119.html.

(60.) Id. [section] 7(j).

(61.) Id.

(62.) H.R. 1086, 108th Cong, (1st Sess. 2003).

(63.) Id. at 16.

(64.) Id. [subsection] 2(5)(C),(E).

(65.) See Chemical Industry Data Exchange, By the Industry … For the Industry, at http://www.cidx.org/AboutCIDX/CIDXOverview.asp.

(66.) See supra text accompanying note 6.

(67.) Some also may use the word “open” to mean availability. See, e.g., infra text accompanying notes 73-36.

(68.) Some think this is not enough:

One of the main difficulties is the inability of standard bodies to

enforce implementation of specifications. The W3C works with

consensus as a guiding principle…. In cases where neither of

these is possible, the solution voted for is usually fairly weak….

One possible solution would be to make sure that the initial

involvement between a corporation and standards organization was of

a more legally binding kind…. Another possibility would be to

involve the public as much as possible. (emphasis omitted)

Dimitris Dimitriadis, Standards: Optional Features of Law?, XML.COM, Mar. 2003, at http://www.xml.com/pub/a/2003/03/19/standards.html.

(69.) Shapiro and Varian, supra note 6, at 238.

(70.) See Lessig, supra note 40, at 702.

(71.) IETF PROBLEM STATEMENT 6-11 (E. Davies, ed. 2003) (work in progress), at http://www.ietf.org/ids.by.wg/problem.html.

(72.) Id. at 12-13.

(73.) See, for example, the inferred license in subparagraph 1 and the declaration in the last (unnumbered) paragraph of Section 10.3.1 of the IETF’s current standards policy. IETF RFC 2026, Internet Standards Process-Revision 3 (S. Bradner, ed. 1996), at http://www.ietf.org/rfc/rfc2026.txt.

(74.) Id.

(75.) Free Software Foundation, Inc., GNU General Public License, at http://www.gnu.org/copyleft/gpl.html

Views on the virtues, efficacy and drawbacks of these terms vary widely, and have spawned their own shelf in academic legal libraries, as well as business circles. See, e.g., OPEN STANDARDS, OPEN SOURCE

(76.) These licenses often have a unique characteristic that tends to promote the continued royalty-free availability of work subject to their terms, and extend that term into derivations as well. Among other provisions, the GPL imposes the following rules:

* The “free” aspect: Section 1 of the GPL permits a fee to be

charged for physical file transmittal, and optionally for the sale

of performance warranties (which are otherwise disclaimed). Id.

[section] 1. Section 6, however, prohibits any licensee from

imposing other restrictions, including any exaction of a lee for

redistribution, and is intended to bar (among other things) the

licensee from charging any royalties to later recipients. Id.

[section] 6.

* The “viral” or “copyleft” aspect: Section 2 permits modifications

or derivations from GPL software if the product also is available

under the GPL, and states that the above condition applies also to

compilations of GPL-derived software with other independent

software. Id, [section] 2. It should not, however, generally be

read to apply to the independent modules by reason of the

compilation. Sections 4 and 5 deny a license to any copying of

distribution that does not comply with Section 2. Id. [sub

section] 4, 5.

(77.) Andrew Orlowski, No More JPEGs: ISO to Withhold Image Standard, THE REG., July 23, 2002, at http://www.theregus.com/content/4/25711.html. See also Press Release, JPEG, Concerning Recent Patent Claims (July 19, 2002), at http://www.jpeg.org/newsrell.html.

(78.) Stephen Shankland, SCO Sues Big Blue Over Unix, Linux, CNET NEWS.COM, at http://news.com.com/2102-1016_3-991464.html

(79.) This is another bumper-crop field of legal academic writing. For a few popular treatments, see, e.g., James Glieck, Patently Absurd, N.Y. TIMES MAG., March 12, 2000, available at http://www.around.com/patent.html

“Once the province of a nuts-and-bolts world, patents are now being

applied to thoughts and ideas in cyberspace. It’s a ridiculous

phenomenon, and it could kill e-commerce.” Glieck, supra at 44.

(80.) See Mark A. Lemley, Rational Ignorance at the Patent Office, 95 N.W. U. L. REV. 1495, 1514-15 (2001)

(81.) Examples of public postings of known claims disclosed under polices of this type may be found at: (i) IETE IETF Page of Intellectual Property Rights Notices at http://www.ietf.org/ipr.html

(82.) See. e.g., the mandatory disclaimers specified in Section 10.4 of IETF RFC 2026, supra note 73.

(83.) Shapiro and Varian, supra note 6, at 231.

(84.) To summarize, in RFC 2026 the IETF:

* Requires that contributors grant a royalty-free perpetual license

to IETF in any claimed copyrights,

* Requires that contributors disclose any claims against the

contribution of which they are personally aware,

* Undertakes to post any claims of which it learns, to a public

location, and

* Undertakes to seek licenses, or other written assurances, from any

disclosed claimants that the standard can be used “under openly

specified, reasonable, non-discriminatory terms.” RFC 2026, supra

note 73.

Please note that these are broad generalizations

(85.) IETE IETF RFC 2339, An Agreement Between the Internet Society, the IETE and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols, at http://www.ietf.org/rfc/rfc2339.txt.

(86.) See supra note 75.

(87.) See generally Mark A. Lemley, Intellectual Property Rights and Standard-Setting Organizations, 90 CAL. L. REV 1889, 1896-97 (2002) (suggesting that these variations may result from an appropriate sorting by the marketplace of various standards activities, to accommodate both those which are better served by high degrees of competition, and those needing greater incentives towards collaboration).

(88.) Shapiro and Varian, supra note 6, at 241. The professors’ advice about how to back up this approach this is not oblique:

If all else fails, sue. No, really. If the dominant firm has

promised to be open and has reneged on that promise, you should

attack its bait-and-switch approach … get clear and explicit

protections early on, if you can, of else give serious thought to

fighting a standards war.

Id. at 288-89. Oddly, the authors say little about the transaction (litigation) costs of pursuing such a strategy.

(89.) See In re Dell Computer Corp., 121 F.T.C. 616, 616 (1996)

(90.) See Rambus Inc. v. Infineon Technologies AG, 318 F.3d 1081 (Fed. Cir. 2003). Rambus sought patents relevant to the work of industry standards committee for SDRAM chips, during the period while the committee developed the standards, and did not advise the committee of its pending applications. Id. at 1086. After the standard was adopted and became widely used, Rambus announced its patents and sought license lees from makers of the SDRAM devices. The federal trial court found that Rambus committed actual fraud, both by failing to disclose its pending applications, and by actually incorporating work from the ongoing committee process to amend and improve its applications. On appeal, however, the Federal Circuit overturned this finding, on the primary grounds that the standards group’s rule requiring disclosure of relevant patents was so vague and broad as to be unenforceable in this case. Id. at 1106-07. At the time of this writing, a further appeal was expected. See also Lemley, supra note 87. Whatever the outcome of that case, Rambus also is defending in a separate action filed by the FTC, which accuses the same acts as being deceptive and anti-competitive. See Cara Garreston, FTC Charges Rambus with Anticompetitive Acts, PC WORLD.COM, June 19, 2002, at http://www.pcworld.com/news/article/0,aid,102051,00.asp.

James Bryce Clark is the manager of technical standards development for the Organization for the Advancement of Structured Information Standards (OASIS) in Boston, Massachusetts, and a practicing lawyer in Los Angeles, California. This Article represents only personal views, and not a position of OASIS or any of its members or affiliates, nor of any other organizations or clients. This Article expands a portion of a presentation made to the ABA Section of Business Law at the ABA 2003 Annual Meeting entitled “Code and Codes: Why Technical Standards Matter in E-Commerce.” All Internet references cited were last visited for confirmation of availability in July 2003.