Electronic Contracts

An online contract system controls access to web site features and permanently saves the exact full text that was agreed to is described. Saved contracts are date and time stamped. The system includes version control and provides for review of previously agreed to contracts. Access to protected functions is prevented unless the user has a valid current contract.

One of the more innovative ideas that I came up with while working on ATLA NET was the concept for electronic contracts that I implemented in the fall of 1998. Everyone reading this page has almost certainly read or skimmed past an online agreement in various forms and clicked on a button that indicated you agreed to and would be bound by the text that you had just (supposedly) read. One of the problems that I have with these is that unless the entity presenting the agreement is meticulous about maintaining version records identifying exactly what text was displayed at what dates and times and the users are equally meticulous about recording when they agreed to what, no one can really be sure who agreed to what terms. If the text of the agreement never changes, this is not an issue but if it changes with any frequency this is a very real issue.

My concept had two components. The smaller part was that the displayed text should be customized to include the user's name and in ATLA's case the user's member ID as well as the date and time. The more important part was that a complete unchangeable record should be preserved of the entire exact text, including all the customizations, that the user agreed to. The intent was to eliminate, or at least greatly reduce, any potential disagreements regarding what was agreed to and when.

A year and a half later, I still have not seen a single implementation of anything resembling this. I seriously considered trying to get a patent but quickly dropped that idea when I learned what it would cost. I thought of the idea working at home while thinking about how to apply online agreements to the Electronic Document Libraries that I had been working on. The initial implementation was all done from home over Columbus Day weekend, 1998. I did go so far as to raise the patent issue with ATLA's General Counsel, who after conferring with the Executive Director, decided that ATLA would have no objections if I sought a patent. I subsequently contacted a patent attorney.

In ATLA's case the online agreements govern use of data obtained from the online directory, assure ATLA that persons uploading documents have the right to do so and giving ATLA and its members the right to use those documents, place restrictions on how downloaded documents may be used and allow controlled use of selected ATLA NET content. Later, online contracts were applied to the use of list servers.

The basic implementation of this idea has a lot of similarity to the central security module. Each protected function has a call added to a single system function that controls access to the calling script. The calling script passes the name of a contract. The called function determines who the user is. Once again this is all working within the private areas of ATLA NET where access is restricted to authenticated users. It then determines if that user has a "current" contract. If so, it returns control to the calling function which is allowed to continue.

If the user does not have a current contract, the called function displays the latest version of the contract whose name it received, merged with data for the user and including the date and time. The only option on the form is an "I Agree" button. If the user does not agree they can use site navigation aids to go elsewhere but they cannot get into the protected function. If the user agrees, then the called function saves the user specific data along with the contract name and version number. No actual text from the contract is saved.

After the contract is saved, the called function re invokes the script that invoked it in the first place. For this to work, the calling script also needs to pass the name of the script to invoke when the user agrees to the contract, which would normally be the calling scripts's own name. Also since the contract function cannot be sure where its being called from and what might be going on between scripts that call it, all form variables are processed in a loop and written to hidden variables that are saved as part of the form that presents the contract text. This allows static forms and scripts that do not have contract protection or have a different contract protecting them than the script being invoked to pass parameters and expect the invoked script to work whether the user already has or needs to agree to a contract in between.

All data related to contracts, including all versions of contract text and all user agreements, is saved in a single GDBM file. A Perl script that generates an HTML form is used for contract maintenance. Each contract that is saved is given a logical name by the maintaining user. That is the name that protected scripts pass to the contract checking function. The script automatically adds a version number. If the contract was retrieved, the version number was read with the contract and automatically incremented when the contract is saved. It makes no difference how significant or minor or even if there are no changes, if a contract is saved, the version number is incremented.

In addition to the contract name, which is not displayed to the user during the agreement process, the maintenance page provides a title field that is used as a header in the contract. The contract text field is modifiable. Within the contract text "[fullname]" (without the quotes) is recognized as a marker by the scripts that use contracts, into which the current user's full name is automatically substituted. The full name, as it was retrieved from the member record at the time of the agreement is saved as a separate data field in the saved contract data. Regardless of future name changes, when an agreed to contract is retrieved, the name as the agreeing to user saw it will be displayed.

The other user modifiable field is a minimum version number. The called enforcement function uses this minimum version number to compare with the version number of any similarly named contracts the user may have agreed to. For a user to have a "current" contract they must have executed a contract with the name provided by the calling function and the users saved version number must be equal to or greater than the minimum version number saved with the contract. By leaving the minimum version number unchanged a contract can be updated with cosmetic or minor changes, and anyone who has agreed to the older version does not need to agree to the latest version to have continued access to a protected function. By setting the minimum version number to one higher than the displayed version number, i.e., what will be the new version number when the updated contract is saved, all users are forced to renew their agreements before being allowed to access the protected function. By setting and leaving the minimum version number as 0, all users who attempt to access a contract protected function will be forced to agree to every minor contract change that is saved.

If you're familiar with Perl hashes but not GDBM, think of GDBM as an efficient way to store Perl hashes to disk for long term storage. Each record consists of a unique key and data which could be null. Keys and data can be any value that Perl can have in a variable. In my contract system both are always displayable text values. There is one special key that contains a delimited list of contract names.

Each contract is stored as two or more records. One record is just the contract name which should exactly match the name stored in the special record. Its data is a single numeric string for the current version number. The second part has one record for each version that has been saved. This part is keyed on the contract name concatenated with a delimiter and a version number. For each version, the data contains a delimited list with the date and time the contract was saved, the title, the minimum version number and the full text of the contract. No contract version is ever deleted nor can it be if the system is to maintain any integrity.

User's agreements are stored in a single record keyed on the member's ID number. All agreements are stored in a delimited list with data for each agreement separated by a different delimiter. Each agreement has the contract name and version number agreed to, the exact system date and time the agreement was executed, the user's full name and the standard formatted text string that starts all contracts. There may be a large discrepancy between the time that was displayed in the contract text and the time the user clicked on the I agree button, depending on how long the user took to read the contract. Each new agreement is always inserted at the beginning of the list so the verification program does not need to check multiple occurrences of the same contract name. It knows the first matching name it finds will be the latest version. No agreement data is ever deleted.

Also included in the system was a contract review feature that allowed a link to be placed on any dynamic page protected by an online contract. The review function is passed the name of the contract to be reviewed. It determines the current user, retrieves their contract agreement record, gets the version number of the named contract to which the user last agreed, retrieves that version of the named contract, merges that version with the user data saved in the agreement record and displayes the results for the user. The contract name and version number are displayed at the bottom of the output page.

I'm not a lawyer and very little about electronic agreements is yet settled legally. What I do know is that a number of states have adopted laws recognizing shrink wrap agreements and that the Uniform Code that is being pushed on the states that have not already adopted it, recognizes shrink wrap agreements as valid contracts. I can't say how my electronic agreement or any other electronic agreement on which anyone clicks an "I agree" button will stack up against shrink wrap agreements. What I do know is that electronic agreements or contracts represent the future and this is still the only system I've personally encountered that makes any attempt to record who agreed to what and when.

Of course the system can be corrupted or perverted. I doubt there's an application system in existence where the authors can't get to and alter any data that is stored by the system, if those authors are also administrators of the machines the application is running on. In this case, there are no special security tricks so any good Perl programmer should be able to write a general purpose CGI maintenance script in less than an hour that would let them add to, alter or delete any data in this system. That is of course assuming the author can locate the script where it has write access to the data and subsequently execute it.

Though I know exactly what needs to be done, as I have no need of such a script, I've never written one. Even if I do, I wouldn't use such a script on live data. Paper documents can also be forged and altered. In real life, contract disputes almost never revolve around a dispute over what was signed. As both parties normally have copies of the final signed document, it's simply to risky to try to alter such a document when you know it will be subject to legal scrutiny. Real contract disputes are over what the agreed to language actually meant or whether the parties did or did not do what the agreement required them to do.

I expect that in the electronic world, there will be more disputes over the actual language that was agreed to, if for no other reason because there has been almost no effort to date to make any kind of record, and certainly not any automated record of what was agreed to, by whom and when. I belive that any party that makes an honest effort to do these things will be in a much stronger position than anyone who does not, when such a disagreement does arise. I don't think it will make much difference that the system is not fool proof as long as the technical staff who have access to the data can testify that they either don't have the tools to manipulate the data or at least that they have never used them on live data.

Obviously the legal landscape needs to be watched but I believe that my effort and other attempts to make an exact record of who agreed to what and when are the first steps to real electronic agreements that the courts will recognize. Ultimately they will probably require public key encryption or similar authentication technology but without first recording the basics of what was seen and agreed to, no elaborate security technology means a thing.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.