A Fresh Look at Web Development and Hosting Agreements
by Eric Goldman
This article describes some of the issues at play in structuring and negotiating Web development and hosting agreements.
As a threshold issue, we must define our terms. Web development and hosting relationships encompass a broad range of substantive relationships, and it is crucial that the substantive relationships be kept separate to ensure proper analysis.
What is Web Development?
Development can encompass a broad range of activities. Although rarely does a customer obtain only one of these services, the services can be broadly segregated into the following categories:
(a) File Conversion. The most basic service, this involves file manipulation such as converting non-HTML documents into HTML and scanning photos or graphics and saving such files into GIF or JPEG.
(b) Web Design. This involves designing the look and feel of the website, including logos and banners, navigation bars or tools, page layout and object placement.
(c) Code Development. This involves coding HTML pages (from scratch), cgi scripts, Java applets or other applications.
(d) System Integration-Website Only. This involves integrating the website with one or more third party applications, such as chat engines, search engines, electronic commerce store fronts, and so on.
(e) System Integration-Website and Back End Systems. This involves integrating the website with one or more existing customer applications, such as legacy systems.
What is Web Hosting?
The generic description “web hosting” can encompass a number of different relationships, such as:
(a) Collocation. Collocation occurs when the customer locates customer-owned servers at the provider’s facility. The provider is “merely” responsible for connecting the servers to the Internet and (usually) ensuring that the servers are up. In a straight collocation relationship, the provider will not manipulate content on the servers. Providers of these services usually provide space for the servers in chain-fenced “cages.” Collocators often offer additional services, such as reselling equipment or software.
(b) Hosting. In a typical hosting relationship, the provider (as opposed to the customer) provides the servers and software in addition to the Internet connection. In some arrangements, the customer is solely responsible for managing the content; in others, the provider may handle some or all of the updates.
(c) Co-Branding. A popular technique has been to expand the scope of a customer’s website by co-branding pages on a third party’s servers. It is analytically appropriate to treat these co-branded pages as being hosted by the third party.
(d) Outsourcing. Increasingly popular, outsourcing occurs when a customer outsources one or more functions of its website to a third party provider. By way of example, WhoWhere? allows a customer website to offer co-branded email to its users by directing customer’s users to co-branded pages operated on WhoWhere?’s servers using WhoWhere?’s software. While outsourcing is similar to co-branding, because the outsourcer is operating software for the customer’s (or its users’) benefit, the customer is now also dependent on the provider for the operation of this software.
Although not literally part of development or hosting, parties engaged in these businesses often offer additional services such as:
(a) Domain Name Registration. The provider will register the customer’s domain name with Internic (or others).
(b) Search Engine Registration. The provider will often register the website URLs with the search engines to ensure that the pages are indexed by the search engines.
(c) Online Promotion. The provider may engage in promotional activities to promote the website or build the customer’s online image. This may include consulting on public relations on the Web, or perhaps advising about integrating Internet promotions with
Key Issues in Development Agreements.
From the customer’s perspective, website development is no different from other types of development. Therefore, customers usually start with their standard form of independent contractor agreement, of which most or all applies.
Within the parameters of a customer-favorable standard independent contractor agreement, ownership tends to be the stickiest point. Customer’s usual starting point-that all development is a work-for-hire or otherwise owned exclusively by customer-tends to be unreasonable in light of the actual manner in which most web developers operate. Like other software developers, web developers tend to recycle components and utilities from project to project. Furthermore, for maintenance convenience, web developers find it beneficial to have all of their clients use a uniform set of tools. Therefore, web developers aggressively resist assigning ownership over certain aspects of their development efforts to one particular customer, because this would prevent the developer from recycling and standardizing.
Because the Web is constantly and quickly moving, customers often will want to spell out a rigorous development schedule coupled with effective remedies for failure to meet contracted milestones.
The customer must make a few platform decisions prior to development commencement. First, the customer must decide what platform the website will reside on (i.e., Unix v. Windows). Second, the customer must decide if the website will be optimized for a particular browser or will offer features that cannot be accessed by certain browsers. If the customer decides to do so, the customer will want to set up meaningfully rigorous acceptance tests to confirm that the desired browsers can access the developed functionality.
Pricing and Updates
As with other development agreements, the developer wants to be paid early, such as on a per-hour basis paid monthly or on a retainer basis. However, the customer will want to defer as much payment as possible until after acceptance. Unlike other development agreements, however, a website is never “finished.” Although there may be an initial “go live” date, websites are living animals and will be constantly updated. Therefore, customer will want to specify clearly what it is buying and how the process of updating will be handled (and paid for). In particular, although there usually will be interim updates to the website, it is typical for websites to be completely overhauled, with respect to both look and feel and organization, periodically (i.e., once a year or every 6 months). Therefore, the parties should plan the development process and pricing for these redesigns-and what triggers a payment to developer and what does not.
Conclusion about Web Development
As is typically the case, the customer usually has lots to say in a Web development agreement, whereas usually the developer is happy to be silent on many of these points. As a result, state of the art developer-favorable agreements tend to be short-unacceptably short, from the customer’s perspective.
Key Issues in Hosting Agreements.
From the customer’s perspective, the most crucial set of provisions relate to the levels of service being provided. Unlike pure Internet service provision agreements, where providers are grudgingly making some promises about service availability (i.e., the service will be available 99% of the time, and if there are excess outages, the customer will receive discounts or credits), the state-of-the-art hosting provider-oriented agreements usually offer no such service promises.
Usually this is unacceptable to customers. There are a large number of substantive standards that the customers would like to see met:
(a) Server Response and Time and Throughput Capacity. Slow servers and inadequate throughput capacity of the Internet connection each mean long waits for users, which results in frustrated users.
(b) Server Uptime. Server outages mean that the website is completely offline. Therefore, customers want to see this minimized.
(c) System Redundancy. To reduce the possible effect of server problems or force majeure (such as an outage by an upstream ISP), some customers choose to require the provider to mirror servers or to connect customer’s servers via multiple ISPs.
(d) User Support. User support can be a tricky issue, because a user inquiry could be technical (i.e., the following URL did not load properly or my password does not work) or substantive (i.e., does the cardigan sweater come in taupe?). Therefore, a process needs to be developed to allocate responsibility for user inquiries. Furthermore, customer will want standards for how provider deals with user inquiries that are provider’s responsibility, including professionalism in communicating, timeliness of response and escalation procedures for user inquiries that provider cannot solve quickly.
(e) Security. Depending on the system configuration and the allocation of responsibilities between provider and customer, provider may not have sole control over the security of the website. However, to the extent that provider can control over security matters, customers will expect their provider to do so. Usually this means proactively preventing security breaches and laying out a process for fixing known security breaches once identified. At minimum, customers usually expect providers to notify them when security breaches or security holes are identified.
(f) Software Errors. To the extent that the host is also responsible for site development, the customer will want standards regarding how quickly provider must correct software or programming errors.
Rights in User Data
As Web-based business models become more refined, more customers are realizing that data collected from or about its users are an increasingly valuable asset. Therefore, customers need to take a number of steps to preserve and maximize the value of this asset. Since provider’s servers are collecting information from or about users, customer’s first step is to obtain copies of the server logs applicable to its website. Most providers now provide raw unprocessed server logs at no additional cost, but reports derived from the server logs may have a separate price tag. In any event, it is crucial for customers to get this data so they can learn more about their users.
Second, customer needs to treat all information about its users as a trade secret. Not only is this crucial to restrict provider’s behavior, but it is also crucial to preserve a possible misappropriation suit if some third party misappropriates user data (since if customer has not protected the confidentiality of this information in all circumstances, it cannot claim that such data is a trade secret).
If asked, collocators and hosts usually will designate customer’s user information as customer’s trade secret, but co-branding or outsource providers will often be less accommodating. Because user data has such great potential value, trade secret license/”sharing” clauses are becoming exponentially more complex and lengthy.
For customer, however, restricting any provider’s use of user data may be a bet-the-business proposition. If customer loses control of this data, usually this will have ripple effects on customer’s business-potentially leaving customer’s users exposed to spam or junk mail, providing customer’s competitors with a targeted list of potential customers for its own goods or services, and educating customer’s competitors and customers (such as advertisers) about the true inner workings of customer’s website.
Provider’s Post-Termination Duties
State-of-the-art provider-favorable agreements usually are silent about what happens to the website after termination. However, from customer’s perspective, this may be another bet-the-business provision. If the website’s post-termination transition to a new provider is not handled properly, the website will likely be off-line or error-prone for a period of time-frustrating users and causing a loss of business.
Therefore, the customer wants to minimize the number of circumstances by which the provider can unilaterally shut down the website or otherwise stop performing under the agreement. Furthermore, the customer will want to lay out a procedure, with time periods and effective remedies for failure to meet the timeframes, for provider to transition the website to a new provider and cooperate in all aspects of such transition. Ideally, customer will have such transition procedures apply even if the customer is in breach of the agreement.
To avoid the danger of a provider playing a hold-up game on termination, customer can plan for transition by obtaining a complete copy of the website periodically during the course of the relationship. Where feasible, provider should deliver a complete copy very frequently (on the order of every 24 hours or less) so that a minimal amount of data would be lost if customer makes a forced emergency transition.
On rare occasions, customers have gotten themselves into trouble when the provider registered the website’s domain name with Internic and listed provider’s employees as the administrative and technical contact (instead of listing customer’s employees). When this happens, Internic will only respond to provider regarding changes the IP addresses of the website servers, again permitting provider to play a hold-up game on termination. Immediately following domain name registration, customer should check its domain name registration to ensure that Internic will honor its request for changes to the domain name records.
To the extent that the provider is also the website developer, if customer does not obtain complete ownership of the website, then customer needs to provide a license for the provider-owned components post-termination.
Customers will want to restrict provider from making unauthorized modifications to the website (although, as described below, providers might demand the right to make changes to minimize their liability). If providers are given the right to make some modifications to the website, usually customer will want an opportunity to review and approve these modifications before the changes “go live.”
Compliance with Laws
Particularly in the co-branding and outsourcing context, customers will want to specify that provider will comply with all applicable laws.
Conclusion about Web Hosting Agreements
At their core, hosting agreements are like any other services agreement, and therefore all of the usual rules of commercial contracting apply. As is the case with development agreements, the service provider will usually benefit from the default rules and therefore will be silent on provisions in the agreement, while the customer will have a long list of needed provisions.
Provider Liability for Customer’s Content.
While much of this article has focused on customer’s wants and needs, web hosts should address the possibility of their liability for customer’s (or its users’) content. Historically, web hosts have feared that they would be liable for customer content. Recently, the trend has been away from host liability for customer content, but there remain some areas of concern.
Defamation and Other “Publisher/Speaker” Torts
47 U.S.C. §230(c)(1) says: “No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.” This section should insulate web hosts from possible liability for any publisher or speaker torts attributable to customer’s content. A recent application of this section was seen in Zeran v. America Online, 129 F.3d 327 (4th Cir. 1997), which held that AOL, as the host of a message board which contained allegedly defamatory statements by a user, was not liable for any possible defamation claim based on these statements (regardless of whether or not AOL knew about the defamatory statements and failed to act reasonably in removing them).
While Zeran certainly is favorable to web hosts, there remain a few points of ambiguity that could limit the benefits of Section 230(c)(1). First, we do not know the scope of torts deemed to be publisher or speaker torts; while this appears to be a broad set of torts, we do not yet know the boundaries. Second, the statute says that a “provider or user of interactive computer services” is insulated from liability; no web host yet has been determined to be a provider or user of an interactive computer service for purposes of this statute, and the statutory definition was drafted in a way that does not clearly include web hosts.
Though there are no clear cases involving web host liability for customer content that is obscene or child pornographic, web hosts may be protected by Section 230(c)(1) described above. If not, web hosts are likely to be protected at least as extensively as the bookseller was protected in Smith v. California, 361 U.S. 147 (1959), which invalidated a statute imposing strict liability for the distribution of obscenity as applied to a bookseller.
Marobie-FL, Inc. v. National Association of Fire Equipment Distributors, 1997 WL 709747 (N.D. Ill. Nov. 13, 1997) is the only case that has squarely dealt with web host liability for customer content. In Marobie, a customer infringed third party copyrighted material, and the copyright owner sued both the customer and the web host. The Marobie court found that the web host was not liable for direct infringement, because it only provided the facilities for the customer to commit copyright infringement, much like the provider of a public copying machine would.
With respect to contributory copyright infringement, it was unclear to the court whether the web host knew that any customer content was copyrighted and the degree to which the web host “monitored, controlled, or had the ability to monitor or control” the customer content. Therefore, the court could not reach a summary judgement. The Marobie court ruled that the web host was not vicariously liable for the copyright infringement, because the web host charged a flat fee irrespective of the volume of customer’s content, and the web host did not receive any compensation that depended on the number of visitors to the customer content.
The Marobie holding largely tracks what most practitioners believed was the state of web host liability for copyright infringement since Religious Technology Center v. Netcom On-Line Communication Services, Inc., 907 F. Supp. 1361 (N.D. Cal. 1995), which held that Netcom, as the provider of access to Usenet postings, was not liable for direct or vicarious copyright infringement in a Usenet posting and was liable for contributory copyright infringement only if Netcom knew or should have known of the copyright infringement and failed to remove it within a reasonable period of time. Several cases have followed the Netcom reasoning, including Sega Enterprises Ltd. v. MAPHIA, 948 F. Supp. 923 (N.D. Cal. 1996) and Sega Enterprises Ltd. v. Sabella, 1996 U.S. Dist. LEXIS 20470 (N.D. Cal. December 18, 1996).
However, the Marobie ruling leaves open several possible bases for web host liability, including:
(i) the web host knew that customer’s content was owned by a third party and web host failed to act in a reasonable period of time;
(ii) the web host monitored, controlled, or had the ability to monitor or control the customer content and failed to do so reasonably (note that this factor is broader than was contemplated under Netcom); or
(iii) the web host was compensated in a way that gave it a direct financial benefit from the copyright infringement.
Finally, although this line of reasoning was rejected by Marobie and Netcom, there are a number of cases that have held system operators directly liable for copyright infringement caused by users. See, e.g., Playboy Enterprises, Inc. v. Frena, 839 F. Supp. 1552 (M.D. Fla. 1993); Central Point Software, Inc. v. Nugent, 903 F. Supp. 1057 (E.D. Tex. 1995); Playboy Enterprises, Inc. v. Webbworld, Inc., 1997 U.S. Dist. LEXIS 21264 (N.D. Tex. December 11, 1997) (note that the Webbworld case is a bit confusing because the system operator did more to process user content than system operators normally perform). These cases hold significantly more peril for the web host, because they would effectively hold the web host strictly liable for copyright infringement in customer content.
Early cases such as the Frena case and Sega Enterprises Ltd. v. MAPHIA, 857 F. Supp. 679 (N.D. Cal. 1994) seemed to indicate that system operators might also be liable for trademark infringement caused by their users.
While these cases were not thoroughly reasoned, a more recent case still suggests that web hosts might be liable for contributory trademark infringement. Lockheed Martin Corp. v. Network Solutions, Inc., 985 F. Supp. 949 (C.D. Cal. 1997) involved a claim by a trademark owner against NSI for contributory trademark infringement for registering allegedly infringing domain names. While the court held that NSI was not contributorily liable, the court made several statements that suggested it might have analyzed web host liability differently. For example, the court comments that “[w]here domain name registration is necessary, the ISP usually acts as an agent to secure and maintain registration.” This type of statement implies that the court might hold the ISP (or, in our situation, a web host) who registers a domain name for a customer liable for contributory trademark infringement on an agency theory.
What Should a Web Host Do in its Contract with Customers?
In a web hosting agreement, providers should contractually restrict customer from providing any content that is illegal or could create liability for provider. Provider should also try to couple this restriction with an indemnity for any suits based on customer content. While these provisions are both helpful, there is always a risk that provider may be liable and the indemnity may prove insufficient. Therefore, it is also a good idea for providers to procure insurance for these types of risks; such insurance is becoming increasingly available.
Finally, provider should retain in its contract the ability to take any action it deems necessary or prudent (including without limitation removing content) if provider believes that customer’s (or customer’s users’) content may create liability for provider.
As repeatedly indicated, provider-favorable agreements tend to operate largely by silence while customer-oriented agreements incorporate a large number of substantive concerns. Empirically, this has proven true: agreements provided by providers tend to be painfully short, and agreements provided by customers tend to be egregious and oppressive. Perhaps this article, by helping focus each party on reasonable compromises, will serve as a catalyst towards reaching a more expeditious equilibrium in drafting Web development and hosting agreements.
Eric Goldman (formerly Eric Schlachter) is an attorney practicing cyberspace law with Cooley Godward LLP in Palo Alto, California. He also is an adjunct professor of Cyberspace Law at Santa Clara University School of Law. All cases cited in this article can be found through the “Syllabus” on Mr. Goldman’ personal home page, located at http://eric_goldman.tripod.com. Mr. Goldman can be reached at firstname.lastname@example.org .