DRAFT 05/31/2000

"LegalXML-Contracts WG" Charter

Co-Chair(s):

Daniel Greenwood <dan@civics.com>
John McClure <hypergrove@olympus.net>

Mailing Lists:

Workgroup Mailing List: contracts@legalxml.org

Status: This is the first draft of the LegalXML.Org-Contract WG Charter.

Introduction

The definition of a contract varies, depending upon the context. For a transaction subject to the Uniform Commercial Code, a contract is defined as "the total legal obligations which results from the parties' agreement as affected by law." U.C.C. 1-201 (11). Section 1 of the famous contracts treatise by Williston holds that a contract is "a promise, or set of promises, for breach of which the law gives remedy, or the performance of which the law recognizes as a duty. Contracts typically include several essentials, in order to be valid, including "parties competent to contract, a proper subject matter, consideration, mutuality of agreement, and mutuality of obligation," 286 N.W. 844, 846; "a transaction involving two or more individuals whereby each becomes obligated to the other, with reciprocal rights to demand performance of what is promised by each respectively." 282 P. 2d 1084, 1088. According to Blacks Law Dictionary a contract is:

"an agreement between two or more persons which creates an obligation to do or not to do a particular thing. The essentials are competent parties, subject matter, a legal consideration, mutuality of agreement, and mutuality of obligation."

Blacks Law Dictionary, Abridged Fifth Edition

There are many methods of classifying contracts. Typical contract types (excluding definitions and examples, for space reasons) include:

• Adhesion contract
• Aleatory contract
• Bilateral contract
• Blanket contract
• Certain and hazardous
• Commutative and independent
• Conditional contract
• Consensual and real
• Constructive contract
• Cost-plus contract
• Divisible and indivisible
• Entire and severable
• Exclusive contract (related to requirements contract)
• Executed and executory
• Express and implied
• Installment contract
• Investment contract
• Joint and several
• Mutual and mixed (related to contracts of beneficence)
• Open end contract
• Option contract
• Oral contract
• Output contract
• Parol contract
• Personal contract
• Pre-contract (related to contracts "not to compete")
• Principal and accessory
• Quasi contract
• Record contract (aka contract of record)
• Requirement contract
• Special contract
• Subcontract
• Tying contract
• Unconscionable contract
• Unilateral and bilateral
• Usurious contract
• Voidable contract
• Written contract
• Yellow dog contract

There are many factors bearing upon whether an agreement between parties will be enforceable as a contract. The definition of offer and acceptance is itself premised upon an objective test. If a reasonable person under the circumstances would have taken words or conduct to constitute an offer to contract, then the power of acceptance may be vested in the offeree. Whether the conduct or words in question are deemed to have reasonably been a contractual offer may be ambiguous and not finally determined until a court has adjudicated the matter some years after the original episode. Similarly, there are several other factors that must be considered to determine whether a contract has been formed, including: mistake, misrepresentation and fraud, absence of consideration, various public policy defenses to formation (such as illegality), and lack of capacity to contract (including for reasons of youth, mental capacity or lack of volition due to duress of coercion).

It may be difficult or impossible to know at the time of an agreement whether or not there exists a valid defense to contract formation. This fact has implications for the usage of the word "contract" as applied to various data marked up using LegalXML.Org Contract standards. The U.C.C. definition for an "agreement" may be more applicable to many types of data that would be marked up with XML. Under the U.C.C. an agreement means:

"the bargain of the parties of the parties in fact as found in their language or by implication from other circumstances including course of dealing or usage of trade or course of performance as provided in this Act (Sections 1-205 and 2-208). Whether an agreement has legal consequences is determined by the provisions of this Act, if applicable; otherwise by the law of contracts (Section 1-103)."

U.C.C. 1-201 (3).

The salient point embedded in the U.C.C. definition of an agreement is that it is found in the language of the parties (content which may be marked up with XML) or other behavior and, depending upon the context, it may or may not constitute a contract or create any other particular legal right or obligation. This scenario will likely describe the state of affairs related to much of the data marked up with Contractual XML. This uncertain legal terrain is characteristic of several areas of e-commerce, wherein some users may seek to characterize their transactions as agreements rather than necessarily as contracts. Such transactions may include the observation of a link to the terms and conditions of use for a public web site, various web-wrap screens on the way to content (like click-wrap or shrink-wrap licenses) and esoteric documents incorporated by reference into computer screen text, like certificate practice statements for the use of digital certificates.

Whether a given user wishes to characterize such digital communications as a contract may be in doubt. A standard may permit, or even promote, a two-way bargain wherein users on the consumer as well as the organizational side of a transaction may put forth the framework of terms and conditions to which the parties will be subject (as by choosing the "agreement" rather than "contract" feature supported by appropriate XML markup). A user-centered standard would support and reflect the commercial, social and civic goals of all participants in a system, not only the desires of parties capable of forcing "take it or leave it" terms. Hence, the usage of the word "contract" may itself be too loaded for all foreseeable contexts in which the standard is expected to be applied. However, it is anticipated that markup for contracts will be a fundamental component to this standard, and that many parties will seek to use XML to create, transmit, negotiate, execute, store, reference and share contract language.

Assuming a contract has been validly formed, there may still be legal defenses to enforcement of the contract. The key defense to enforcement is known as the Statute of Frauds, which requires certain contracts to be in writing and signed by the party against whom enforcement is sought. The interplay between the requirement for a writing and signature and the advent of electronic records and electronic signatures under new laws being proposed at the state and federal levels (the Uniform Electronic Transactions Act at the state level and S. 761/H.R. 1714 federally). Many jurisdictions already recognize electronic methods as sufficient to create a "writing" or "signature" based upon case law and recent statutes. Unconscionability of a contract will also constitute a defense to enforcement. The doctrine is typically applied to procedural unconscionability (occurring during the bargaining process), rather than substantive unconscionability (resulting in unconscionability contractual terms). Terms that cause unfair surprise, exculpatory clauses that would release a party of liability for intentional harm or injury, and limitations upon remedies that are so extreme they "fail of their essential purpose" are among the types of clauses that may not be upheld due to unconscionability.

Table of Contents

• Mission Statement
• Scope
• Deliverables
• Duration and Milestones
• Confidentiality
• Coordination with Other Groups and Interdependencies
• Communication Mechanisms
• Decision Procedure
• Participants

Mission Statement

The XML Contracts Workgroup exists to develop and promote open XML standards that enable faster, less expensive and better formation, negotiation, use, amendment, termination and dispute resolution including litigation, of electronic contracts.

Principles, Purposes and Objectives:

Outreach and Inclusion of Stakeholders.

A guiding principle of this Work Group is that stakeholders must be included in the process of standards making, including interested persons who would invent, implement, sell, use, approve and service products based upon the open XML contracts standards. The requirements documents that will guide development of the Contract XML standard must be derived from a clear, consistent and correct statement of the actual demonstrated needs and desires of the stakeholders.

User-Centered.

A special class of stakeholders are the users. In a sense, the most important customer and beneficiary of sound Contract XML standards are parties to contracts that utilize the standard. Therefore, user-centered design principles will be employed at every stage to ensure that the voice of the end-user is ever present through the standards making process.

Business Case Aware

The business case is, in a sense, a real-world problem statement for which contract XML can be the solution. Whether a given standard will be implemented depends largely upon the existence of a business case. Users may desire many features or functions, but only some such desires may enjoy an actual business case, rather than inclusion solely in a pipe dream or wish list. Knowledge of actual and reasonably projected business cases must underlie

Well Modeled and Documented

For XML standards to be useful and understood, it is critical that clear and accurate models of use cases and other diagrams be developed which correctly reflect the requirements and guide the generation of the standard. The standard will also need to be well documented for the purpose of conveying the semantics and other relevant information.

Flexibility.

* As agreements usually require no particular form or content in order to be deemed a contract; and

* Since different types of transactions and parties may be subject to virtually innumerable distinct rules of applicable law that may create particular requirements for any given contract; and

* Since parties to electronic contracts currently use a wide variety of different technologies, tools and techniques, and

* Since the foreseeable future will apparently be characterized by more rather than less experimentation and creative ideas in this field; therefor

* XML contract standards must permit maximum flexibility to allow and encourage innovative implementations and approaches to electronic contractual processes. As such, end-users must be able to customize and add to the tags which describe their electronic contracts and contracting processes.

Scope

The scope of work will focus upon drafting XML standards for the formation, use, amendment, dispute resolution and termination of electronic contracts.

It is proposed that the workgroup will develop a core generic set of elements and other XML components that would underlie all contracts supported by the standard. Then other elements can be developed to handle specific types of contracts, subject matter, or areas of law. It is anticipated that the Contract XML standard will be object oriented. RDF and SOX are viable tools with which to specify this standard in an object oriented manner. Other architectures will also be solicited and considered as part of the initial solution development phase.

We will also explore methods by which the Contract XML standard may be implemented, including setting up Java libraries to manipulate the XML in an object-oriented fashion. There appears to be a general abundance of XML specifications matched only by the paucity of software necessary to implement that code. Thus, we deem it within the scope of our workgroup to consider, and where appropriate to code java libraries. This activity will be used only to test ideas and will not be made production-ready within the workgroup.

We will pay particular attention to the higher-level XML contracts that give legal effect to lower level XML. Within the business to business procurement realm, an example of a higher level contract would be the Trading Partner Markup Agreement (see: http://www.oasis-open.org/cover/tpa.html). An example of lower level XML would be the purchase orders and related documents in, for a given implementation of a procurement system (see, for example: http://www.biztalk.org/library/schemaDetail.asp?SchemaID=128686) or the Common Business Library (www.xcbl.org). A "master contract" or set of "operating rules" may control the entire relationship between some transacting entities. This is an example of a contract at the highest level and will also be within the scope of this workgroup.

As part of our work on user and requirement modeling, we will prepare UML specifications including use-cases illustrating how the XML based upon the Contract XML standard will be used.

Deliverables

The Contracts WG will deliver the following:

• Development of a Requirements Document that Reflects and Supports the User-Centered, Business-Case Aware and Flexibility Goals of the Workgroup
• One or more general purpose DTD for expressing generic contractual issues;
• Specific purpose DTD's for multiple contract areas, such as procurement, real-estate, insurance and architecture/construction. We anticipate that these are related in an object-oriented manner to the general purpose DTD(s);
• Java or other code related to the XML standards for the purpose of testing ideas and standards under consideration;
• Tutorials on aspects of XML and the software that manipulates it for the education of those working with XML-based Contracts and the Legal XML group at large.

Duration and Milestones

1. December, 1999: Working Group is created
2. January - May, 2000: Initial Work Group Members Join
3. May, 2000: Draft Charter Published
4. June, 2000: Publication of Several Unofficial Notes Related to Contract XML
5. June-July, 2000: Polling of Contract XML Membership, LegalXML Membership at Large and Broader Community With Respect to Stakeholder Identification, Business Case Analysis and Requirements Setting for Contract XML Standard;
6. June - July, 2000: Development of Draft Requirements Document, to be authored contemporaneous with, and in response to, the polling of Stakeholders regarding the User-Needs; Business Case and general purpose for a Contract XML standard
7. July, 2000: Publication of Requirements Document
8. June-August, 2000: Development of Version 1.0 of Contract DTD(s)
9. August, 2000: Publication of Version 1.0 of Contract DTD(s)
10. August - October, 2000: Comment Period on Version 1.0 of Contract DTD(s)
11. October - December, 2000: Development of Version 2.0 of Contract DTD(s)
12. December, 2000: Publication of Version 2.0 of Contract DTD(s)

We reserve the right to change these milestones and deliverables to best meet the needs of the Workgroup, LegalXML and the end user community.

Confidentiality

This charter and the mailing list and archives of the Contracts Work Group will be available to all LegalXML Participants, and to any further extent permitted by the Operating Rules and as agreed by consensus of the Work Group.

Coordination with Other Group and Interdependencies

The Contracts XML Workgroup will work with all other LegalXML groups, as mutually needed and desired. In particular, we anticipate working with the Horizontal Group to assist in contributing elements derived from contracts that may be of relevance to other Workgroups and to utilize elements developed in other Workgroups to the extent they are useful within a contracts context. Special attention will be paid to the public law standards (to the extent such law is cited within contracts and is a source of requirements for valid and enforceable contracts) and the court filing standard (to the extent judicial proceedings relate to litigation of contracts).

The Contracts XML Workgroup will work with groups external to LegalXML to the extent useful to further the understanding of electronic contracting issues; to identify and adopt relevant technical, legal and business standards; and to facilitate the comment, revision and, finally, adoption of the ContractXML standard.

The Contracts XML Workgroup anticipates compliance with W3C standards and also with emerging relevant e-contract related standards including the eCo Architecture (http://eco.commerce.net) and TPAML (http://www.oasis-open.org/cover/tpa.html).

Communication Mechanisms

Contract WG members are expected to participate in the group through participating in discussions on the WorkGroups' electronic mailing list, and in one or more of the following ways: submission of unofficial notes, participation in LegalXML Polls and coming to face-to-face meetings, submission of comments on draft standards and contribution of code to test ideas and proposed standards. The sole WG consensus venue is the WG mailing list.

Communications regarding WG administrative matters may be addressed to either of the WG co-chairs by private email, or to a duly selected designee who volunteers to assist with administrivia.

Group Home Page

http://www.LegalXML.org/Contracts

Face to Face Meetings

The Contracts Work Group will meet at the next Legal XML Group Face to Face. Aspirationally, the Workgroup will seek to assure at least one-week prior notice of meetings, a two-day advance agenda, and posting of minutes no longer than one week after the meetings.

Decision Procedures

The Contract Work Group will govern itself by consensus as provided in the LegalXML Operating Rules and as further determined within the Workgroup.

Participants

Participation in the working group is open to all LegalXML.Org Participants. The LegalXML.Org Contracts WG will be co-chaired by Daniel Greenwood and John McClure.

Attachment 1

Examples of Legal Requirements that

Some Text be Conspicuous

Overview:

Some Requirements are National (via Uniform Law or Federal Law) and some requirements are jurisdictional. In some cases, the requirements are based upon prior contracts between parties that future agreements be posted or displayed in a conspicuous manner.

Federal:

http://www.lawdog.com/credit/usecr36.htm

Prescreening of Consumer Reports For Marketing Use of Information

(Certain parties must provide "must provide with each written solicitation a clear and conspicuous statement that the credit record of the consumer was used in connection with the offer, and that the consumer was selected because criteria for credit worthiness or insurability used to screen for the offer were met."

http://www.ftc.gov/os/statutes/fcra/steer.htm

(FTC Staff Opinion Letter regarding inclusion of a disclosure (which must be conspicuous) and a consumer authorization in the same document.)

Section 604(b)(2)(A) requires them to provide a clear and conspicuous disclosure in writing to the consumer before a consumer report is obtained; under the terms of this section, this disclosure is required to be "in a document that consists solely of the disclosure, that a consumer report may be obtained for employment purposes."

http://www.carolina-auto.com/ncada/archives/legal/regm_rules.html

(Federal Reserve Board changes to Regulation M's consumer lease advertising requirements)

The changes streamline the triggering and triggered term requirements, require that down payments and the amount due at lease signing are disclosed equally, and provide guidance on the standard for "clear and conspicuous" disclosure of lease terms. All dealers who advertise consumer leases must comply with the requirements in all forms of media, including television, radio, newspaper, and the Internet.

UCC:

http://www.laderapress.com/laderapress/inlegispar3.html

(UCC Implied Warranty of Merchantability Disclaimer - ways to made conspicuous in compliance with the law) Article Two states that this warranty can be

excluded only with language that mentions merchantability. If

the exclusion is in writing (and it should be, for evidence

purposes), the exclusion must be "conspicuous" (in a different

typeface, type size, or color from the rest of the contract). This

warranty also can be excluded by making it clear in the

contract that the goods are sold "as is."

Contract:

http://www.wisbar.org/werc/ga/1998/5713.htm

Arbitration decision in dispute on employment contract in public sector. Issue: Did the District violate the contract when it failed to award the Assistant Maintenance Mechanic position to grievant . . .

"All vacant or new positions recognized under Article I � Recognition of this Agreement shall be posted in a conspicuous place internally for three (3) working days prior to being posted externally."

Misc. State Requirements:

http://www.lpitr.state.sc.us/bil97-98/1158.htm

South Carolina Student and Family Privacy and Protection (Bill which was evidently not enacted)

When informed consent is required under this chapter, the consent shall be manifested on a form or paper used solely for the purpose of obtaining consent and providing written notice which contains a reasonable description of:

(1) the health care services for which informed consent is sought. This item requires clear and conspicuous notice regarding any health care service which may involve:

(a) an examination of the genital area or the removal of undergarments; or

(b) mental or emotional health screening, diagnosis, treatment, counseling, or referral.

(2) The student record and the purpose for which the student record is sought.

(3) The entities or persons who shall have access to the student record or provide the health care services in question if consent is granted.

http://www.complainthelp.dca.ca.gov/legal/s-6.html

(display of "return policy" for retailers subject to CA law, including:

- When Return Policy Must Be Displayed

- Location and Contents of Display

- Consumers' Remedies

It is an open question whether or how these types of requirements might be applied to the web storefront of a retailer doing business in CA)

http://www.waceo.com/archive/oct97/1097-Internet.html

(Suggestion that Acceptable Use Terms for Web Sites Be Conspicuous to Enhance Chance that they will later be found to be Contractually Enforceable)

Make the terms and conditions conspicuous. Merely giving clear notice of what behavior is expected will bring most users into line. Also, commercial contracting laws, particularly those applied to consumer contracts, favor terms and conditions that are conspicuous to the end user. In all cases, a link to the terms of use, or the terms themselves, should be clearly and prominently displayed and labeled on the home page.

Interesting NCCUSL Definition of "Conspicuous" for Computer Information:

http://www.law.upenn.edu/bll/ulc/ucita/ucitanc.htm

(Uniform Computer Information Transactions Act)

Definition: "Conspicuous", with reference to a term, means so written, displayed, or presented that a reasonable person against which it is to operate ought to have noticed it. A term in an electronic record intended to evoke a response by an electronic agent is conspicuous if it is presented in a form that would enable a reasonably configured electronic agent to take it into account or react to it without review of the record by an individual. Conspicuous terms include the following:

(A) with respect to a person:

(i) a heading in capitals in a size equal to or greater than, or in contrasting type, font, or color to, the surrounding text;

(ii) language in the body of a record or display in larger or other contrasting type, font, or color or set off from the surrounding text by symbols or other marks that draw attention to the language; and

(iii) a term prominently referenced in an electronic record or display which is readily accessible or reviewable from the record or display; and

(B) with respect to a person or an electronic agent, a term or reference to a term that is so placed in a record or display that the person or electronic agent cannot proceed without taking action with respect to the particular term or reference.

Excerpts from some substantive clauses requiring conspicuous terms:

Except as otherwise provided in subsection (e), a warranty under this section may be disclaimed or modified only by specific language or by circumstances that give the licensee reason to know that the licensor does not warrant that competing claims do not exist or that the licensor purports to grant only the rights it may have. In an automated transaction, language is sufficient if it is conspicuous.

. . . To disclaim or modify the implied warranty arising under Section 403, language must mention "merchantability" or "quality" or use words of similar import and, if in a record, must be conspicuous.

. . . Language to disclaim or modify the implied warranty arising under Section 405 must be in a record and be conspicuous. It is sufficient to state "There is no warranty that this information, our efforts, or the system will fulfill any of your particular purposes or needs", or words of similar import

http://www.cptech.org/ucc/reply.html

(Letter by Consumer Project on Technology regarding placement, timing and conspicuousness of disclaimers under a prior draft of UCC2b - now UCITA)

Furthermore, the implied warranty proposal, which was rejected at the April meeting, would have allowed the software publisher to disclaim liability for viruses for all customers (including small-purchase-price customers), just by including a "conspicuous" disclaimer, as you stated. What you failed to mention is that under 2B a disclaimer is statutorily defined as conspicuous even if it is contained within the software package, hidden from the customer