OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[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]