How Do I Build an Enforceable Online Agreement? — Not (Always) the Way SalesForce.com or Google Would

The issue comes up on an increasingly frequent basis. A client is preparing to begin delivery of a new service (or product) through their web site. As part of their preparations, the client involves me (or, let’s say “an attorney”) to help them implement an online (“click-through” or “click-to-accept”) contract covering the terms under which the new service (or product) will be provided to their users. While almost all clients understand that this will entail the preparation of an online “terms of service” contract, not all also appreciate that the contract document itself is really only part of the equation. Creating a legally enforceable online agreement is also dependent on how that contract is implemented and whether the implementation is sufficient to create a legally binding agreement with each user. Examples of how to implement online contracts certainly abound — and in addition to contacting legal counsel many clients will also naturally look to major web sites for guidance on how to implement their own online contracts. However, it is not always a given that even these larger players have made the best decisions in designing their online contracting practices. As a result, simply asking “What would SalesForce.com and Google Do?” is not always the best approach.

At last year’s American Bar Association (ABA) Annual Meeting in San Francisco a panel hosted by the ABA Committee on Cyberspace Law discussed the results of a year-long working group on legal best practices for electronic contracting. Given the increasing frequency with which all companies (technology vendors or otherwise) must deal with online contracting issues, the findings of the working group are likely to be of interest to many companies (particularly if the alternative involves simply relying on whatever practices have been adopted by other web sites). While the current law in the area of online contracting is certainly still developing and in places resembles more of a patchwork of seemingly inconsistent legal decisions, the working group found that certain basic principles have emerged for establishing legally enforceable online agreements. In particular, the panel indicated that the working group had identified four “bottom line” steps for forming legally binding online agreements:

1. The user must have adequate notice that the proposed terms exist;
2. The user must have a meaningful opportunity to review the terms;
3. The user must have adequate notice that taking a specified, optional action manifests assent to the terms; and
4. The user must, in fact, take that action.

Among these four steps, adequate notice of the existence of the proposed terms is among the most important. The concept here is nothing new. Online contracts are not different from traditional paper contracts when it comes to notice of terms. As the panel indicated, the standard here asks quite simply whether a reasonable user entering into the agreement would understand what the terms were. The panel suggested that this generally means making the terms immediately visible to the user before assent is given — for example, through an on-screen window with a button that the user must click before moving on to the next screen. While there are many examples of what would be deemed “reasonable” under the circumstances, the more the notice of the terms is not straightforward, the greater the risk that the notice will not be deemed reasonable to form a binding agreement.

Despite the urging of counsel, the panel noted (and I would concur) that this simple step is often abused or simply not followed. Many times, it is a failure to provide the terms of the contract or at least a functioning hyperlink to a separate page containing the terms. Sometimes it is more subtle in that certain terms are only presented after the transaction has been completed on a confirmatory screen or email. Recently, I was working with a client who was reluctant to present the terms of their online contract as in fact being part of a “binding” agreement. Instead, the client wanted to present the terms merely as a request (or suggestion) to the users of their web site. As the panel noted, not only must the terms be presented to the user, but it must also be explicit and clear that the terms form a binding agreement between the parties.

While notice is a continual hot-button issue, the other “bottom line” steps are also important. It is of note that providing a “meaningful opportunity” to read the terms of the contract does not necessarily require that the user actually read the terms of the contract, only that they be given the opportunity to read the terms (you can lead a horse to water, but you can’t make it. . . ). The discussion by the panel specifically cautioned against using separate pop-up windows for purposes of accomplishing this step. As someone who has a pop-up blocker set on his own browser, I would agree that there is definitely a risk in this practice.

The issue of assent is also not to be overlooked. While the now ubiquitous “I Agree” button is the norm, I have reviewed sites that instead allow the use of standard browser navigation buttons to manifest assent. The panel noted this issue and stated that assent must be through some action that the user would not otherwise take automatically (like using the buttons on their browser to navigate to the “next” page of the web site). Instead, assent should be through an “optional action manifesting assent” to the terms of the contract.

In addition to the four bottom line steps, the panel also noted that the ultimate issue in any contracting situation is one of proof — can the party seeking to enforce the contract prove that the necessary steps were followed to form a binding agreement? The situation is no different in the context of online contracting. This means proving that a user either clicked a box (or was presented with a set of terms and continued forward anyway). While many web sites are set up to help provide this proof, it is worth considering what you would do if your agreement was challenged by a user and you had to prove that your web site implemented these four “bottom line” steps when the user accessed the site. While not always an easy task, the panel noted that particularly where a web site has gone through multiple updates or revisions (and what web site hasn’t), retaining records of the prior iterations of the site can be a valuable aide in helping to prove that users of the previous versions of the site did in fact enter into a binding agreement.

As I have mentioned in prior posts, the law in this area continues to evolve. The “bottom line” steps provided by the working group of the ABA Committee on Cyberspace Law are certainly of assistance — particularly, as noted above, when the alternative involves relying on whatever practices have been adopted by other web sites. However, best practices for online contracting are likely to continue to change as the law of online contracting continues to evolve. As a result, continued periodic review and update of online contracts and contracting practices will continue to be a must to help ensure continued legal compliance.

Affero GPLv3 Released

The Free Software Foundation (FSF) today announced the release of version 3 of the GNU Affero General Public License (AGPLv3). AGPLv3 is based on version 3 of the GNU General Public License (GPLv3), but has an additional term to allow users who interact with AGPLv3-licensed software over a network to receive the source code for that software (and modifications to that software). In particular, AGPLv3 modifes Section 13 of GPLv3 as follows:

While GPLv3 generally covers the distribution to third parties of modifications to software under GPLv3, it does not cover the situation where a user modifies software covered by GPLv3 and runs the modified software on a network without actually distributing a copy of the software. As a result, users making the functionality of software subject to GPLv3 available over a network (but not also distributing the software itself) are not required by GPLv3 to make available the source code to any modifications they have made to that software. This means that modifications to software covered by GPLv3 by companies operating operating under a software as a service (SaaS) or application service provider (ASP) model need not be released.

The fact that ASP/SaaS models are quickly becoming prevalent in the software industry and that the final draft of GPLv3 released earlier this year did not close this so-called “ASP Loophole” (or, if you prefer, “SaaS Loophole”) has led to a good deal of concern among open source commentators. The FSF intends that AGPLv3 will address these concerns by providing a means for developers to close this loophole. In particular, under AGPLv3, anyone running a copy of a modified version of software covered by AGPLv3 on a network must also make available a copy of those modifications as well (regardless of whether they have actually distributed the modified software itself). In their press release, the FSF notes that AGPLv3 is compatible with GPLv3 and, as a result, programmers who want to use the AGPLv3 for their work can also take advantage of software available under GPLv3. Given the additional coverage provided by AGPLv3, the FSF recommends that people consider using the AGPLv3 for any software which will commonly be run over a network.

Upcoming BCBA Presentation

For those of you in Colorado, I will be giving a presentation on open source software licensing issues for lawyers to the Boulder County Bar Association on Thursday of this week. I have included details on the presentation below. Further information is available on the BCBA website at: http://www.boulder-bar. I hope to see you there!

Thursday
November 8, 2007

Open Source Software
INTELLECTUAL PROPERTY LAW

 


It has become unrealistic for most businesses to avoid the use of open source software. Managing the use of open source software can, however, raise unique legal concerns not faced in the management of traditional proprietary software. Starting with a review of the legal foundations for open source software licenses, this session will cover current legal issues around open source software and discuss the legal and practical concerns generated those issues. The session will also present practical lessons learned in the field and best practices for compliance with open source software licenses. This session is designed to be of value both to those new to the field of open source software license compliance as well as seasoned open source compliance experts. 1 CLE $20, Lunch $10 (turkey, veggie, club or salad w/ or w/o meat)

Presenter: Jason Haislmaier
Hutchinson Black & Cook, 921 Walnut, 12:00 pm

 

GOSCON Here I Come

 

I will be speaking next month at GOSCON 07 (that’s the Government Open Source Conference). This year the event runs from October 15-16 in Portland, OR. The event has grown quite a bit over the last two years and the organizers are expecting over 500 attendees at the conference this year. As Stephen Walli and others have noted, this is an excellent event if you have anything to do with free and open source software from a government perspective (and that includes government contractors and vendors). Stehpe was a presenter last year and speaks very highly of the event — click here for his account of the conference.

My session is titled “Open Source Licensing 101.” The topic is relatively broad and gives me a license to cover a number of different areas — and with the recent legal activity around open source licensing, there is no shortage of areas to cover. I am still developing the materials, but regardless of your level of experience with open source licensing the session should be of value.

Special thanks to Deb Bryant for organizing the event (and for inviting me to speak). From the looks of it, she has done an exceptional job building, growing, and maintaining the conference. I am really looking forward to being a part of this event.