Don’t Like UCITA? Check the Contract of an Application Service Provider

by Andy Oram
January 26, 2001

Shrink-wrapped licenses have fanned a fire storm in the computer industry; it rages through various arenas from newspapers to legislative hearings to Dilbert cartoons. Controversy was by no means snuffed out by the finalization of the Uniform Computer Information Transactions Act. Instead, it has split technologists and consumers from the business and legal forces in the industry.

Thus, it occurred to me a few months ago: would fear of shrink-wrapped licenses push businesses toward the alternative of contracting with Application Service Providers? I made a list of everybody’s worst fears regarding shrink-wrapped licenses, and considered whether the same contractual problems could arise with ASP service. Of course, the ASP business is radically different from packaged software, but still I was impressed to see how many subtle problems with shrink-wrapped software could potentially turn up with unethical or cavalier ASPs.

For instance, some software manufacturers are invoking their licenses to prohibit customers or reviewers from commenting on their software. (To be fair, software isn’t the only industry where these “confidentiality clauses” appear.) Another concern of the anti-UCITA crowd—although I haven’t heard of it actually happening—is that a software manufacturer could release a product with known bugs and then charge customers for service calls to deal with those bugs. Half a dozen such specters, some quite real and some more speculative, hover over shrink-wrapped software and ASPs alike.

The real fun for me came at the next step in my research, when I contacted a couple dozen ASPs to ask them, “How does your contract or user agreement handle these issues?” I received several responses to specific scenarios, plus some generalizations about service level agreements in the industry. The results left me with a mixed impression.

ASPs know their success depends on keeping up a good reputation and delivering responsive service month after month. It may be reasonable to accept their assurances that poor actors won’t last long in the industry, and that customers should look at quality measures, staffing, and technical resources instead of contractual terms for evidence of good service.

But the ASPs themselves take service level agreements very seriously. I was told that most of their agreements include the kind of broad disclaimers we’ve seen on shrink-wrapped software. (Disclaim all warranties to the extent allowed by law, take no responsibility for lost data, etc.) They also tend to reserve the right to cut off service at their sole discretion. Since customers can abuse ASPs (for sending spam, for instance) and since many problems lie beyond the ASP’s control, it is reasonable for them to protect themselves—but the customers should also think of what protection they themselves need.

One excellent form of protection is to get a monthly backup of all your data from your ASP. This was advice from John Polgrean, Corporate Counsel to ManagedOps.com Inc. Backup tapes are offered for a small extra fee by his company, an ASP for mid-size businesses that offers Siebel Systems, Great Plains, Microsoft, and other integrated ebusiness applications.

Let’s look at a few UCITA horrors and parallel possibilities with ASPs. For my criticisms of UCITA, I rely mostly on the exhaustive analysis Software Engineering & UCITA by one of UCITA’s most prominent critics, Cem Kaner. (Kaner played no role in developing my article, though.)

Gold-plated bugs

Kaner proposes this scenario:

Suppose that a customer buys a computer game for $50. She starts to install it, is presented with the license and clicks OK. Thereafter, the program fails to install. The customer calls the publisher’s help line, and is billed $5 per minute for support. After 20 minutes ($100 plus long distance expenses), the customer realizes (correctly) that this is a defect that the publisher knew about when it sold the product and that the publisher has no solution that will work on her machine. She therefore rejects the product and asks for a refund. The publisher requires her to return the product (she incurs postal expenses) and sends her back a check for $50, choosing not to reimburse her for the $100 or the other incidental expenses. With the right pricing structure, the software publisher will make a net profit on this series of transactions. Under UCITA, this is acceptable.

Well, it would also probably result in fraud charges if it happened regularly. Now, what if your find a defect in ASP software? You don’t have much protection in the contract—but the contract isn’t the full story, according to Lou Parker, Senior VP of Law, Content & Public Relations at JurisDictionUSA.net, which describes itself as “the first full-service ASP for the legal profession”:

Our User Agreement provides “the use of JDUSA is on an ‘as is’ and ‘as available’ basis…” which is standard in the industry. However, regardless of any contractual obligation, we will strive to fix any defect that is our fault or within our control as quickly as possible, or else we will lose customers.

He also assured me that “We do not deploy software with previously known defects.” I’m not sure that’s a workable business plan, but I’m willing to believe that ASPs will do their best to fix their own bugs and will not charge customers extra charges for support around those bugs. Parker points out:

That’s one of the major aspects that differentiates an ASP from a software provider…As soon as we fix a defect, the customer gets the upgraded product and service automatically and immediately without any additional cost. The customer doesn’t have to buy a new version every year to stay current. Likewise, the customer doesn’t have to buy a service contract to use and maintain the program.

Chris Kruse of CaseCentral, an ebusiness platform for legal industry professionals, says that customers never have to pay for fixing bugs, and adds:

Because we have this easy termination clause [30 days notice from the customer at any time], and because we are fundamentally a service business, we work like crazy to fix bugs according to a very fast and strict set of guidelines…We fix them based on severity in a couple of hours to a day or two days. Our business is absolutely based on great customer service.

Now, what if the ASP is deploying a commercial solution written by another software vendor? This is a completely different problem. The ASP might have the clout to get bugs fixed, so you may be better off in their hands than as a small business with shrink-wrapped software. However, the ASP may help you work around the bug by offering special support under the category of “systems integration” (a well-established function in the computer industry), and that would probably be an additional fee.

I’ll Pay For the Defective Horseshoe—But You Gotta Shoot the Horse Yourself

Although it rarely breaks out in the press, one of the biggest economic issues of our day is the campaign by businesses to limit the damages they have to pay for their mistakes. (This is what the “tort reform” controversy is all about.) Everybody knows that software development is not a science; no one expects software to be perfect. In software, the questions are what companies should do when defects severely hurt a customer’s business, and whether they should be punished for hiding known defects.

According to Polgrean, software vendors and ASPs take similar approaches. The software vendor usually tries to limit damages to refunding the cost of the software, excluding the category known legally as “incidental or consequential damages.” (Courts don’t always agree, but UCITA makes things easier for the vendor.) The corresponding clause in many ASP contracts limits damages to a few months worth of service. And Parker writes:

If the problem is our fault and within our control, we will refund any customer any prepaid charges without question, and if it is something that is our fault or within our control, we will refund any unused, prepaid charges. However, we expressly disclaim any liability for any consequential, incidental, direct or indirect damages and we disclaim any responsibility or liability for damages caused by any 3rd party.

And its user agreement adds, “In no event shall JDUSA’s total liability for damages, losses, and causes of action exceed the amounts paid by user for JDUSA’s services.”

Don’t Badmouth Me and I Won’t Badmouth You

In 1999, PC Magazine complained that it could not publish a planned article with comparative benchmarks on different database products. The reason? The Oracle Corporation enforced a clause in their license that prohibited the publication of data about their product. Kaner reports that UCITA would legalize such gag orders in mass-market software.

Lots of companies believe it perfectly reasonable to stop customers from sharing their impressions of service with others. Thus, it is not surprising that many ASPs contracts state that each party—the ASP and the client—has to get consent from the other before publicly commenting on the service. And I guess I’d want my ASP to respect my privacy—but there is a point where respecting ASP privacy blurs over into a license to hide bad practices.

Luckily, poor service on a large scale can’t be hidden for long. It would leak out at trade shows and other casual forums. What the publicity clause might stop is formal reviews in the manner of PC Magazine.

Let’s See How the Chips Fall

How important are formal contracts? Well, a lot of people are taking shrink-wrapped licenses seriously. UCITA is alarming enough to bring protests from the Attorneys General of 26 states, and so far it has been passed only in two: Virginia (with a provision to re-examine it in a few years) and Maryland (after weakening some controversial clauses). UCITA is opposed by many business groups and consumer organizations like the Consumers Union and the Public Interest Research Group. Finally, the people who know best—software developers themselves—seem lined up against it, as represented by the Association for Computing Machinery, the IEEE, and the Software Engineering Institute.

Even without UCITA, software vendors are stretching the law. Check the license on any piece of software you like—downloaded or purchased on disk—and I’ll bet you it will contain a prohibition against reverse engineering, even though the courts have overturned such prohibitions in the case of mass-market software. UCITA will make it harder to overturn the prohibitions.

Similarly, vendors always try to prohibit you from giving your software to someone else. If this was enforced against businesses, it would jam up many a merger or acquisition. But again, it’s a prohibition of dubious legality. Despite the vendor’s claim that they’re “licensing” the software to you, the courts would probably consider the transaction a “sale” and give you first sale rights. UCITA codified the transaction as a license. So the widespread opposition to UCITA is not mere paranoia.

Some of the most worrisome provisions of UCITA apply to businesses, because individual consumers would continue to have more protection under the law. So my guess it that a serious expansion of shrink-wrapped license abuses will make ASPs increasingly attractive—and more power to them.

I would also guess is that ASPs currently, at this young stage, are trustworthy. Potential clients can assume they’ll do the best to honor their contracts in good faith, judging them by their professionalism in obvious areas like security and up-time. But what if a few ASPs build up a huge customer base and develop momentum? I’d hope that none get so secure in their position that they can adopt the cocky attitude of the software companies that bank on UCITA to shield them from liability.


Andy Oram is an editor at O’Reilly Media. This article represents his views only. It was originally published in the online magazine Web Review.