June 10, 2009
Stop Saying "We Can Amend This Agreement Whenever We Want"!--Harris v. Blockbuster
By Eric Goldman
[I've been sitting on this case for a couple of months, but it's such an important case that it still deserves a write-up even at this comparatively late date.]
This case is part of the legal detritus from the Facebook Beacon program. As you recall, Facebook Beacon included purchases from third party e-commerce sites into the buyer's Facebook status reports. This required the e-commerce sites to report Facebook users' purchases back to Facebook. A Blockbuster user claimed that Blockbuster's reports to Facebook violated the Video Privacy Protection Act, which prevents disclosures of PII about video customers without their consent. (Beacon did have an opt-out of debatable efficacy). Blockbuster moved to compel arbitration of this lawsuit based on the mandatory arbitration clause in Blockbuster's user agreement.
Blockbuster used an industry-standard and entirely typical introductory clause to its user agreement, which said:
This industry-standard and entirely typical clause does not fare well in this courtroom. Among other defects, the judge notes that "there is nothing in the Terms and Conditions that prevents Blockbuster from unilaterally changing any part of the contract other than providing that such changes will not take effect until posted on the website." As a result, the court deems the arbitration clause "illusory," an odd Texas law descriptor that appears to be a cousin of lack of consideration.
I could wax philosophic about the ontological meaning of a "contract" that one party can amend unilaterally at any time without notice. However, I'd rather focus on the simple practical implication from this ruling. I've never been a fan of the language Blockbuster used, and I had hoped many websites would reconsider the language after the Ninth Circuit trashed such provisions in 2007 in Douglas v. Talk America (also see my follow-up post). Yet, these clauses are still ubiquitous, even at big websites that "should know better," so let me boil it down for you into a single all-caps mantra:
STOP PUTTING CLAUSES INTO YOUR CONTRACTS THAT SAY YOU CAN AMEND THE CONTRACT AT ANY TIME IN YOUR SOLE DISCRETION BY POSTING THE REVISED TERMS TO THE WEBSITE
This language has a significant risk of killing the entire contract, which would strip away a lot of very important provisions that should be/need to be in the contract. So far Blockbuster has only lost its mandatory arbitration clause, but it's possible other important risk management clauses (warranty disclaimer, liability limits, dollar caps, etc.) will similarly fall. If those clauses fail, let the plaintiff feasting begin!
I recognize that weaning ourselves from very flexible amendment language leaves us as drafters with few good options to modify online user agreements over time. I discussed this dilemma in my post on the Douglas case. I haven't found any better solutions in the past 2 years, but I can say with confidence--DON"T DO WHAT BLOCKBUSTER DID.
UPDATE: I got the following email from a reader proposing a good alternative to current amendment notification processes: "To avoid the spam-filter problem, the provider could give notice via an RSS feed as well, and then disclaim like crazy about the problems with the email option (which would indeed simply be an option -- a link to a page where users can sign up to receive notices)." I love this idea! RSS is a true opt-in with few of the challenges of email.
Also, this brought to mind the EFF's new TOSBack service, which I'll mention more in a future blog post, that effectively provides a third party service to track amendments of various user agreements into an RSS feed. I LOVE IT! I have subscribed to TOSBack and plan to blog on interesting user agreement amendments it reveals--and I suspect I'm not the only one queued up to do so. TOSBack is a game-changer for public scrutiny of agreement amendments--sites being monitored in TOSBack are now on notice that their user agreement amendments are being watched!
TrackBack URL for this entry: