[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Contract Code: Manifestation, Machines and the Mind.
Hi John, I thank John and Rolly for their considered legal treatment of these issues. I especially thank Rolly for his wonderful statement of the issues and the context. John - I appreciate your effort to find a contract formation principle that is apparently more applicable to electronic contracts - especially those where one or both parties has chips instead of a mind. Meeting of the minds is clearly an antiquated and incomplete measure - though it retains usefulness. The "objective manifestation of assent" measure, while facially more applicable to computer systems, also is rooted in the mind of the other party. The underlying question remains "how do we know whether a given action was or was not an objective manifestation of assent"? Whether conduct constitutes a binding "offer", in the language of contracts law, depends upon whether an ordinary reasonable person would have taken that conduct to be an offer. Hence, we get right back into the murky and subjective recesses of the mind. This concept comes up again in the widely reviled but persistent Uniform Computer Information Act (UCITA). As noted in the Specht vs. Netscape case: "For example, ? 112 [of UCITA], which addresses manifestation of assent, provides that a user's opportunity to review online contract terms exists if a "record" (or electronic writing) of the contract terms is "made available in a manner that ought to call it to the attention of a reasonable person and permit review." UCITA, ? 112(e)(1) (rev. ed. Aug. 23, 2001) (available at www.ucitaonline.com/ucita.html). Section 112 also provides, in pertinent part, that "[a] person manifests assent to a record or term if the person, acting with knowledge of, or after having an opportunity to review the record or term or a copy of it . . . intentionally engages in conduct or makes statements with reason to know that the other party or its electronic agent may infer from the conduct or statement that the person assents to the record or term." Id. ? 112(a)(2). In the case of a "mass-market license," a party adopts the terms of the license only by manifesting assent "before or during the party's initial performance or use of or access to the information." Id. ? 209(a)." Though UCITA is not law in California, the U.S. 2nd Circuit Court of Appeals chose to cite it. It is very interesting to me that the text of UCITA assumes that an electronic agent is capable of inferring that a human or other electronic agent has assented. Inference is a characteristic usually available only to living creatures with higher brain function. Machine inference engines have only very limited functionality and scope of application at this time, and lack anything approximating "common sense". This type of fuzzy legal formulation represents the very early state of jurisprudence in this arena of law. I do not propose that we should lock our requirements to UCITA or any other particular law. But I do think it is a good idea to be cognizant of the general legal standards as they are applied to computer systems, and to be mindful of supporting and reflecting those standards in our technical specification. The emerging law of electronic contracts appears to support contract formation where parties have an opportunity to review terms (whether they actually do or not) and exhibit some sort of manifestation of intent. Best practice, of course, is to see, consider, and explicitly agree upon the final terms - in their final format. But this is not required by the law in all situations as a prerequisite to enforceability. While looking back at the scant legal guidance that exists to date is helpful, it is even more compelling to note that we have some latitude to be creative in generating our specification. There are many legal precedents and guidelines to inform our discussions and decisions - but we have an opportunity to, in a sense, be a player in the emergence of the legal framework itself. Technical specifications like the one we are creating are, indeed, becoming inextricably tied to the law itself. The lines are blurring. The first clear (and my favorite) statement on the subject is by Bill Mitchell at MIT, and I strongly commend it to all of your for review. The full statement is available at: http://mitpress2.mit.edu/e-books/City_of_Bits/Soft_Cities/HumanLawsCod edConditionals.html Here is a very relevant excerpt: "Out there on the electronic frontier, code is the law. The rules governing any computer-constructed microworld-of a video game, your personal computer desktop, a word processor window, an automated teller machine, or a chat room on the network-are precisely and rigorously defined in the text of the program that constructs it on your screen. Just as Aristotle, in Politics, contemplated alternative constitutions for city-states (those proposed by the theorists Plato, Phaleas, and Hippodamos, and the actual Lacedaemonian, Cretan, and Carthaginian ones), so denizens of the digital world should pay the closest of critical attention to programmed polity. Is it just and humane? Does it protect our privacy, our property, and our freedoms? Does it constrain us unnecessarily or does it allow us to act as we may wish? . . . So control of code is power. For citizens of cyberspace, computer code-arcane text in highly formalized language, typically accessible to only a few privileged high-priests-is the medium in which intentions are enacted and designs are realized, and it is becoming a crucial focus of political contest. Who shall write the software that increasingly structures our daily lives? What shall that software allow and proscribe? Who shall be privileged by it and who marginalized? How shall the writers of the rules be answerable? " There are many possible answers to Bill's final questions in this passage. Clearly, private interests are writing the software and the code. And government is in the game too. And another, more innovative and promising player is the standards organization. Like the OASIS/LegalXML eContracts TC. We are writing the Code. This is, in a sense, the Applied Restatement of Electronic Contracts, Number One. (Lawyers will get that reference). In other words, we are privileged to try creating a framework that can support the high aspirations of contract law: that parties be at liberty to negotiate agreements and be held to their word, that legal outcomes be predictable, that parties be able to make informed choices, that the terms and the process of contracting be fundamentally fair, that no party is surprised by contractual outcomes, that commercial and other contracts be formed and used in an economically efficient manner (e.g. less transaction costs, less drag), that contracting practices be flexible and responsive to the changing needs and methods of parties over time, and that other public policies be reflected in contracting practices (consumer protection, privacy, record retention, etc). It is certainly possible to capture these sorts of requirements in a technical standard. But it is unwise to attempt to reach this level of abstraction and philosophy as a first step in creating a standard. The proposed requirement that contract presentation (e.g. format, style, etc) be directly and conclusively supported by our specification is in the above category of aspirational goals . Is this a necessary requirement for any useful XML contracts standard? No. Clearly, automated contracts can be created and executed without ever being reduced to a final "hard copy" type record (whether on paper or in a format like html or PDF). And, perhaps unfortunately, even human to human / human to machine contracts can be formed without a person ever actually viewing the contract itself. As I noted above, there are situations when a party need not click on the link to the contract to be bound by it if they have manifested assent to be bound by the contract and the terms were available for your review. And standardized eContracts XML can still be very useful for these situations and for many others. The question for us is: do we want to take presentation on directly or not? This is really a scope and policy question. If we take it on and nail it, then we will definitely service a large block of current contracting practices (ensconced as it is in presentation) and we are posed to genuinely contribute to the evolution of electronic contracts. But there is a cost involved. It takes time. Focus paid to presentation is traded off against other requirements we could be meeting - like revenue recognition functionality or better automated contract practices for agreeing to receive subsequent notices electronically (e.g. like what is required under the federal ESIGN Act). Bottom line: I think we should plan to address presentation functionality in our specification. It is key to many (nearly all) forms of contracts currently in use. I think it should be a requirement, and we should agree as a group about exactly how to phrase and meet that requirement. But I believe we should spend time on it after we have finished the semantic markup (which we are currently calling the "legal markup") and whatever we are going to do with structural markup. By doing semantic markup first, and by using the benchmark contracts I proposed in an earlier e-mail, we will have focused our use cases and expected implementation scenarios to the point where the presentation requirements will be relatively easy to articulate, weigh and agree upon in the context of our shared concept of work. I am not in favor of spending much more time at this point debating the presentation and structure of contracts for which we have not yet begun to provide substantive markup treatment. Having indicated my preference, I must also note that I am sure we can also conclude a very useful and important technical specification even if it does not directly and conclusively address the presentation issue. Thanks, - Dan PS: I'm coming to perceive that our final specification will have to be accompanied by fairly detailed explanations of usage and examples. This is, after all, rather subtle subject matter and reasonable minds apparently differ on what we are talking about. It may be helpful to provide as part of our final product some sample contract provisions that indicate the underlying XML is not part of the final contract (similar to language that precludes the section titles from being read into the contract), or that it IS part of the contract, or that the conclusive presentation is to be included or is to be referenced externally, etc. It might also be helpful to include some example story boards or narratives demonstrating how it is envisioned vendors will implement the specification and how users will apply it to their work. ============================================== | Daniel J. Greenwood, Esq. | Director, E-Commerce Architecture Program | MIT School of Architecture and Planning | 77 Massachusetts Avenue, Room 7-231 | Cambridge, MA 02139 | http://ecitizen.mit.edu | or http://www.civics.com | dang@mit.edu ============================================== -----Original Message----- From: jmessing [mailto:jmessing@law-on-line.com] Sent: Monday, April 21, 2003 12:17 AM To: dang@mit.edu; legalxml-econtracts@lists.oasis-open.org; Chambers, Rolly Subject: RE: [legalxml-econtracts] The CSS issue (was .. Req #106) "Meeting of the minds" takes on a new dimension when one or both of the contractants are computerized agents. I always was told that the test was Corbin on Contracts, which is slightly different. "Objective manifestation of assent." That is, each party assents by manifesting objectively an intent to do so. The standards have subtle differences in the cases, with sometimes drastically different results. I think with regard to a strict presentation format, perhaps the Corbin formulation may be superior, at least with regard to the issues of structure vs. presentation issues. ---------- Original Message ---------------------------------- From: "Chambers, Rolly" <rlchambers@smithcurrie.com> Date: Sun, 20 Apr 2003 20:05:07 -0400 >I apologize in advance for the length of this message. I agree with >addressing the presentation issue. To me the issue is more whether the >XML representation of a contract or the presentation image of it will be >intended by the parties as the binding expression of their mutual >agreement and thus will be enforced by the courts as a legal matter >(i.e. will be "conclusive"). > >In common law (US, UK, AU, Canada, and related jurisidictions), one >important legal element of a contract is a "meeting of the minds" of the >contracting parties -- their mutual assent or intent. A fundamental >purpose of contract law is to enforce the mutual agreement or intentions >of the parties. Currently, the words the parties use, which often are >written down, exchanged, read, and signed by them, evidence their >"meeting of the minds." Thus, if a dispute later arises, it becomes >critical for courts and lawyers to decide what the parties mutually >agreed upon and intended based on the objective expressions they used >(typically the words in a written contract) so that the agreement they >reached can be determined and enforced. > >XML allows content to be separated from display. This technical feature >of XML creates something of a legal problem for contracts because an >agreement can be expressed and exchanged in two separate and different >formats -- in the XML representation or in the presentation image of it. >Either can be exchanged by the parties and either can serve as evidence >of the parties' mutual agreement or intentions. > >Because it is more likely that the presentation image (rather than the >XML) will be what most users exchange as the expression evidencing their >intent and agreement (at least when humans are involved), presentation >of XML contracts takes on particular significance from a legal >perspective. It is difficult to see how an XML representation can be >accepted as expressing or evidencing a "meeting of the minds" or the >intent of the parties, and consequently be enforced by a court, if >neither side even knows what the XML representation contains. This is >particularly the case when the parties themselves have instead exchanged >a presentation image of the XML for such a purpose. > >The parties are almost certainly free to agree that the XML >representation rather than the presentation image of it is the >"official" or binding expression of their mutual agreement if they >choose, but I doubt few people will do so. If the parties look to the >presentation image of the XML rather than to the XML itself as >evidencing their mutual agreement and intentions, then a court almost >certainly will do so as well and, like the parties themselves, ignore >the XML. Of course, it would also be important to have a single, >definitive presentation image in such situations to avoid disputes about >what each side saw, signed, and agreed to. > >I have not thought through all the legal implications this may have for >representing contracts using XML. It certainly appears that an XML >representation of a contract exchanged between two contracting parties >would probably not be the legally enforceable expression of their >agreement where they have neither seen the XML nor specifically agreed >that the XML would serve as the "binding" expression of their mutual >agreement and intent. This problem might be solved by requiring the >parties to exchange a "definitive" presentation image of a contract >document, such as a pdf version, along with the XML or perhaps by >requiring them to exchange technical details about how the XML is to be >presented (e.g. what stylesheet will be used, what browser or other >application will be used to generate a presentation image, etc.). > >It also appears that the presentation issue has little legal >significance outside the context of an exchange between contracting >parties (i.e. the legal issue does not arise where XML is used by only >one party as a tool for administering or generating draft contract >documents), where the parties have expressly agreed that the XML >representation they are exchanging will control regardless of what the >presentation image looks like, or where only XML without a presentation >image is exchanged (e.g. with automated contracting processes involving >only the exchange of XML between machines). > >While the presentation issue is important, I think an XML eContracts >spec would still be useful whether it creates the "conclusive" (i.e. >legally enforceable) presentation image of the XML or not. I also think >it would be helpful for an XML eContracts spec to provide sufficient >information to make it reasonably easy to create a presentation image of >the XML in case the contracting parties want or need a presentation >image for their purposes. > >Rolly Chambers > > -----Original Message----- > From: Daniel Greenwood > Sent: Sat 4/19/2003 6:28 PM > To: legalxml-econtracts@lists.oasis-open.org > Cc: > Subject: RE: [legalxml-econtracts] The CSS issue (was .. Req >#106) > > > > Hi all, > > I think, based on the attention paid to the presentation issue >on our > list, that we as a TC should formally address the question as >part of > our requirements phase. I suggest that we consider at least >starting > this discussion as an agenda item during our next teleconference >on > Wed. I further suggest that we'll be more productive by >carefully > articulating the question to be addressed - i.e. the requirement > statement itself. To that end, I have talked with John McClure >today > and derived the following draft statement that I think will help >us to > clarify the issue before us. Here is my first take at the >question, > please feel free to hack away at it. > > "Yes or No: The eContracts spec shall define an exchange >standard (XML > Schema or DTD) that includes the information needed to create > conclusive presentation of the contract as agreed by the >parties, > without the need for an intervening transformation via XSL-T or > similar process." > > I think we should first agree on the question presented and then >we > should determine as a group whether the answer is yes or no. > > Best regards, > Dan Greenwood > > ============================================== > | Daniel J. Greenwood, Esq. > | Director, E-Commerce Architecture Program > | MIT School of Architecture and Planning > | 77 Massachusetts Avenue, Room 7-231 > | Cambridge, MA 02139 > | http://ecitizen.mit.edu > | or http://www.civics.com > | dang@mit.edu > ============================================== > > -----Original Message----- > From: John McClure [ mailto:jmcclure@hypergrove.com] > Sent: Saturday, April 19, 2003 3:11 PM > To: legalxml-econtracts@lists.oasis-open.org > Subject: RE: [legalxml-econtracts] The CSS issue (was .. Req >#106) > > Jason, > You've asked me to reply, so I will. > > 1. You ask " What is so difficult about transforming where >necessary > to perfect > for CSS support? It is taken for granted that this will be >necessary > with the > other formats." The technical issue here is whether eContract >markup > will > support formatting using the so-VERY-common CSS standard. The > functional issue > is the definition of what is exchanged between the parties -- is >it > the pieces > that can be combined programmatically into the contract >artifact, or > is it the > artifact, the image, its complete text? > > 2. You ask "No legislation anywhere in the world is going to >mandate > that the > output must be XML+CSS, so why accord it any special treatment?" >My > expectation > is that if legislation were to exist on this subject, that it >would > state that > the "final image" constitutes the official record of the >contract, no > less than > the final image. That would include PDF, RTF, XHTML, SVG, >XSL-FO, flat > text, > etc -- all formats that represent a final image. My proposed >solution, > using a > "names" attribute on the XHTML/SVG/XSL-FO elements -- is >developed > with exactly > that sort of legislation in mind. My proposal is true to the >charter > of > LegalXML -- to create standards for the transmission of legal > documents using > the XML protocol. Worrying about PDF and RTF is an >application-level > concern, > outside the scope of LegalXML. > > 3. You ask "Can you please clarify what you are talking about >here? I > would say > (simple-mindedly perhaps) that either a contract is stored at a >URL > from which > it can be later retrieved, or it isn't. If it is stored at a >URL, then > how it > got to be there is irrelevant, but it could be XSLT output just >as as > it could > come from any other process." (1) Citations are made all the >time to > specific > text within a document. Specific text within documents whose > presentation is > generated using XSL-T cannot be linked-to using the most basic > machinery of the > Internet: the hyperlink. It's that simple. It's that realization >that > made me -- > 18+ months ago, from work in the LegalXML Citations WG -- >conclude > that the > proper subject of exchange between parties to a contract must be >the > presentation artifact. It was on that basis that I set about to > fashion a > proposal for preserving the semantic markup that we, in >LegalXML, want > to convey > as well with the final image -- and hence the notion of a >"names" > attribute on > XHTML/SVG/XSL-FO elements was born. (2) From your question. it >appears > you > believe that the document stored at the URL is the official >record, > and it is in > a presentation format. Fine, that correlates to my basic >assertion, > that the > document exchanged must be a presentation document. However, you >have > been > arguing forceably that the document you want to be exchanged -- > encoded using a > standard that we are defining -- is one that references an XSL-T > stylesheet > which creates the PDF/.../XSL-FO image. You've been saying you >do not > want to > exchange the final image -- you want to create one on the fly -- >you > want to > exchange something less than the final image. Your position >seems > inconsistent > with our charter -- to define the standards for a contract, the > official record > ..... you don't appear to want to define standards for a >contract, but > rather you > want to define standards for something that is used to create >the > official > record of the contract. > > Finally, you say you "can't see any justification for elevating >CSS > above all > these alternatives" -- suggests to the non-technical audience >that > this is a > matter of CSS _or_ XSLT. That is not true at all. Support for >CSS does > not > foreclose applying an XSL-T stylesheet to an XML formulated to > accommodate CSS > stylesheets, whether done server-side or client-side, whether > outputting PDF, > RTF, XHTML, SVG, XSL-FO, or something else that _your_ >application > requires. > > John McClure > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]