Formost businesses, their Web site is a highly visible and important element intheir public presence and customer interface. It may be the first point ofcontact for a potential new customer or it may be a method for existingcustomers to transact business with the Web site owner. For dot.com companies,the Web site will be its only or main interface with the outside world and itsonly way of transacting business. It follows that a poorly designed or poorlyfunctioning Web site could destroy the company’s hard-earned goodwill, or evenits business.
Web site development agreements have not yet come of age andthere is no accepted standard format. Few precedent books contain highlydeveloped Web site development agreements and such precedents as there are tendto be rather unsophisticated.
Typically, a draft agreement will be presented to the client bythe Web site developer as their standard form. But many of the issues in whichthe client is interested are of little benefit to the developer. They may,therefore, either not be addressed or be unsatisfactorily addressed. In manycases, Web development companies are small or recently formed and have notdevoted the time or resources to developing a comprehensive legal document whichwould have any chance of being acceptable to a remotely sophisticated client. Insuch cases, therefore, it will be in the client’s interest to put forwardtheir own form of agreement to the developer.
For the purposes of this article, I shall assume that we arerepresenting the client rather than the developer. I will go through some of themain issues that will need to be addressed in the agreement, focusing on thoseareas which may be contentious or require more careful consideration.
Web site development agreements have many of the characteristicsof traditional software development and services agreements. These can be usedas a good starting point. However, there are also many points which are specificto Web developments.
Services
The fundamental aspect of any agreement for the provision ofservices is to define clearly the services which the developer is to supply. Ina Web development contract, there can be a range of potential services apartfrom pure Web development work. For example, the developer may also be providingsome or all of:
hosting
domain name registration
training
support services
marketing services.
Hosting
Typically, a small or medium-sized enterprise (SME) will nothost its own Web site. To do so would be uneconomic and may require skills whichare not readily available within the organisation. Accordingly, the provider ofhosting services will allow the client to place the software and contentrelating to the client’s Web site on the provider’s servers which areconnected directly to the Internet. The provider will be responsible formanaging those servers and maintaining the connection. Often, the client’s Website will be one of a number of Web sites which are hosted on the same servers.Whilst this is a cost-efficient solution, it can raise questions regarding theperformance of the site and the bandwidth which is made available. These areissues which should be addressed in the contract.
A slightly different model of hosting, known as co-location, iswhere the customer has his own servers but locates them at the provider’sfacility. Where co-locating is involved, the provider is responsible formaintaining the servers, for their overall security and for their connection tothe Internet. In this case, no other Web site will be hosted on the same serverwhich will be dedicated to the client’s Web site. This is a more expensivesolution but one which may provide the client with greater performance and aguarantee of bandwidth availability.
Domain Name Registration
It can be risky to outsource the registration and management ofdomain names unless it is managed and closely regulated by contract. The clientmust ensure that the details of the registration are correctly set out. Forexample, whilst the developer may register the client’s domain names, theyshould be in the client’s name and not in the developer’s name. Difficultiescan arise in relation to the contact and billing details that are provided withthe domain name registration. These details are used by the Domain NameRegistrar to provide reminders and invoices when renewal fees are due. If therenewal fee is not paid – perhaps because the client did not receive thereminder because the contact details were incorrect or out of date – then thedomain name may be lost to someone who is waiting just for this moment. It canthen be difficult and expensive to recover the domain name. Also, therelationship with the developer may not subsist in the long term beyond thedevelopment of the agreement. It may, therefore, be unsatisfactory to rely onthe developer in the long term to maintain the domain names.
Training
Where the content on the Web site is to be maintained by theclient, the client’s personnel may need some training in uploading andupdating the content. As with software development contracts, the nature andextent of the training should be clearly specified to avoid any additionalunexpected cost items.
Support Services
As with software development contracts, it may be beneficial forthe client to enter into a support agreement with the developer under which thedeveloper agrees to maintain the site following the initial development phase.This may mean that the developer will be assisting the client with uploadingcontent, or it may just mean that the developer is fixing any bugs that appearin the site or making changes to the site as required from time to time andproviding support to the client’s staff who may be managing the content.
Marketing Services
Marketing Services may also be provided by the developer. Theservices may include registration of the Web site with search engines, promotingthe Web site and providing the client with periodic Web site statistics andanalysis with recommendations of action to be taken in light of the statisticalfeedback.
Specification
The specification is one of the more important aspects of thedocument. The specification will describe the aims and objectives of the Website, its functionality and content, the look and feel issues and how data is tobe collected and processed. It can also specify in more technical detail suchmatters as performance levels, capacity, response times and browsercompatibility. Where the Web site is involved in e-commerce, the specificationwill need to address the data processing at a more detailed and technical level,including perhaps any interfaces with back office systems of the client.
There is always a difficulty with regard to the specification.Contractually speaking, unless an aspect of the Web site is addressed insufficient detail in the specification, it will be difficult for the client toreject the site, withhold payment or make any form of claim or complaint thatthe developer has not performed in accordance with the agreement. On the otherhand, it may be impossible or uneconomic to develop a specification whichcontains every last detail. To do so could take an inordinate length of time.Often, the specification produced by the client will be rather general and willnot be an adequate document from a contractual point of view. Sometimes theclient will not have the expertise to develop the specification itself. Indeed,this may be one of the services which the client is looking for from thedeveloper. In this situation, part of the developer’s brief will be to developthe specification and design concept for the Web site. Where this happens, notechnical work will commence until the specification has actually been agreed.We then need to consider the possibility that the parties may never reachagreement on the specification, in which case the development will not moveforward. In these circumstances, the contract may need to be written in phasesso that the parties move to phase two only if the specification which is beingwritten as part of phase one is agreed.
A further complication with this scenario is that, where theparties have not agreed the detailed terms of the specification at the time theyenter into the contract, it may be impossible for there to be agreement on theprice for developing the site as the precise scope and extent of the site willnot have been agreed. It is unsatisfactory for the client to enter into acontract purely on a time and materials basis. Accordingly, one of thepre-requisites for entering into phase two of the agreement may be also anagreement as to price for the Web site development. Commercially, however, theclient’s negotiating position may be weakened at this point as it will bepsychologically committed to the developer who will have developed thespecification and the concepts in it. One of the points which needs to be bornein mind in this context is the ownership of the intellectual property in thespecification where this is written by the developer. If the parties partcompany, will the client be able to take the specification forward with anotherdeveloper?
It is desirable for the specification to address technicalissues relating to the site. For example, the question of compatibility of thesite as between browsers. Different Web browsers, and even different versions ofthe same Web browser, may display Web pages differently. This is because thereis no consistency between Web browsers in the HTML standards which they haveadopted. HTML is an open standard that is evolving. This means that to seek tomaintain a consistent appearance amongst different Web browsers is a difficult,and perhaps impossible, task. This problem can be addressed in various ways. Ata basic level, the client could ensure that the Web site adopts the lowestcommon denominator in terms of browser standards, but the downside to this isthat some more highly functional elements of the Web site may not be available.At the other end of the scale, and therefore a more expensive solution, the sitecould be developed in different versions so that the appropriate version isdelivered according to the browser which you are using. Bearing in mind thesedifficulties, a pragmatic solution may be to leave it up to the developer to befree to develop the site without being too concerned over slight differences inpresentation, but with a basic obligation to ensure that the site performsgenerally consistently across all browser platforms.
Particular difficulties can arise with graphics, their colourpresentation and the choice between whether to use the GIF format or the JPEGformat. Although a Web site has the potential to deliver multi-media, it is arather poor medium for delivery of high-quality graphical interface, althoughtechnologies like FLASH have moved this on. One of the difficulties is that thegraphical capability of users browsing the site will vary according to thequality of their monitor, their settings and so on. Although JPEG files cansupport 24-bit colour, many computers will support only 8-bit colour offeringonly 256 colours, which is the limit of the GIF format. To address performanceissues, the parties can agree on the maximum file size for graphics, can agreewhich graphical format is used in different situations and also agree that allgraphics should have, so far as possible, a consistent cross-platformappearance.
When considering this issue, bear in mind that one of thereasons given for the failure of Boo.com was that its Web site was too slow andover-engineered. The company had over-estimated the connection speed which itscustomers would be using and ended up providing an unsatisfactory Web shoppingexperience.
Something that can give rise to potential difficulties with Website development contracts is the concept of ‘feature creep’. This ariseswhere ideas develop and new features are added to the site which were notcontemplated in the original specification. This can lead to difficulties forboth parties as the developer may seek to claim additional payment from theclient for features that were not specified in the original specification. Theclient may be aggrieved about this if it had not pre-agreed any increase in theprice or believed that all work which the developer was doing was included inthe original price. This is in large measure a matter of contract management,but it can be assisted by a change control provision in the contract. Under thisclause, the parties must exercise the discipline such that if there is anychange to the original specification by way for example of additional featurethen the developer must provide a price proposal for making this change whichmust then be accepted by the client before being progressed. Changes made by thedeveloper other than by following this procedure and without obtaining theclient’s consent would not attract any additional payment.
Implementation Timetable
The timing for development of a new Web site can be crucial.Accordingly, an essential aspect of the agreement is the implementationtimetable, setting out various milestones during the development process. Thesemilestones could include agreement on the specification, delivery of a pilot Website for assessment of the general look and feel for client feedback, contentloading, the delivery of the Web site for testing, acceptance and the going livedate.
It is also useful to link the payment schedule with theachievement of the milestones. This avoids a situation where the developer isentitled to payment regardless of the stage he is at on the plan.
We then also need to consider downside issues. What if thedeveloper fails to deliver in accordance with the plan? This is not aboutrejection of the site following acceptance testing. This is about failure todeliver the site before acceptance testing in line with a timeframe. Dependingon how critical the timeframe is, you may wish to consider any or all ofliquidated damages for delay, bonus payment for achievement of the target dates(stick and carrot approach) and ultimately termination of the agreement andrecovery of monies paid for failure.
Clearly, termination is a last resort as it would mean theclient having to start again with a new developer, which would have an adverseeffect on the overall timing.
Acceptance Testing
Provisions relating to acceptance testing, acceptance and theconsequences of non-acceptance are crucial for the protection of the client. Inparticular, acceptance of the Web site usually involves the making of a final orsubstantial payment. This tends to motivate the developer to ensure that the Website achieves acceptance. Also, acceptance implies that the site has moved fromthe development stage into a warranty period or support contract.
It may not be possible to test all aspects of the site, butacceptance tests should be designed to test the major functionality of the site.Tests may include, for example, verification of response times, veracity oflinks, overall conformity with the specification, correct handling of inputdata, cross-browser compatibilities, printing and so on.
The acceptance clauses may be similar to those found in complexsoftware development agreements. However, bear in mind that the performance of aWeb site in a controlled environment may be very different to that where the Website is live on the Internet with multiple users accessing it simultaneously.This point was made very strongly in a case where a Web site was developed for apopular broadcasting company and was to be launched in a splash of publicity.The Web site was operating fine before the publicity launch, but within hours oflaunch it received several hundred thousand hits. As a result, it collapsed andhad to be taken down with much embarrassment. This is, of course, somethingwhich would be difficult to test prior to launch, but it is worth bearing inmind in case any secondary stage or post-launch acceptance procedure should beincluded, or any retention from payments made during a warranty period.
If the site fails acceptance tests, the best remedy is to getthe developer to correct the problems as quickly as possible so that theacceptance tests can be repeated. The client should have some control over howmany times the acceptance tests can be repeated. After say two rounds ofacceptance testing, the client should have more serious remedies. This mightinclude accepting the site as is, albeit deficient, with some retention orreduction in price. In serious cases, where the site is unacceptable, the clientshould have the ultimate remedy to withdraw from the agreement and recovermonies paid. Again, in these situations, as mentioned before, the client maywant to have the ability to pick up the pieces left by the developer so thatanother developer can continue the work without intellectual property problems.This may be fine in theory, but in practice it is likely that it will be moredifficult for a third-party developer to pick up the work of someone elsewithout significant re-engineering. It can also be difficult to persuade anincoming developer to take over the work of the outgoing developer and inparticular an incoming developer would not wish to provide any warrantiesregarding the work which it had taken over. In some cases, therefore, the onlysolution may be to start again. This right of termination is, therefore, a lastresort.
Intellectual Property
The issue of intellectual property in the developed site oftengenerates a lot of heat. On the client’s side, there is the thought that, ifthey are paying for development work to be carried out, they should own allelements of the work done. There is also the legal point that the client musteither have ownership of all aspects of his Web site or secure licence rights inrelation to it.
From the developer’s point of view, the position is morecomplex. Imagine that a client wishes you to draft a Web site developmentagreement for them. The client also wants to own all copyright in the finishedproduct. This may present you with difficulties because, in reality, the Website development agreement may be based on your firm’s standard precedentwhich you will wish to re-utilise for other clients. It may contain somestandard clauses which appear in a number of your agreements. Again, you wouldwish to reuse these on other work, and will inevitably already have used theprovisions in many previous documents. It would not, therefore, be feasible foryou to assign copyright in the finished product to the client. It may be,however, that part of the document which you are asked to prepare contains aclause which is specific to the transaction and which requires you to undertakesome original drafting. This provision is very unlikely to appear in anothercontract and you may be able, therefore, to assign copyright in it to theclient, at least in theory. If another client wanted something similar, then youcould redraft it without any substantial copying so as to avoid infringing thecopyright. The client may then say that they think the clause provides them withsome sort of competitive advantage and they would not wish you to use the clauseor anything like it in any agreement which you prepare for any of theircompetitors.
This situation, although perhaps somewhat unlikely, provides afair analogy with the position of the developer in relation to Web sitedevelopment. He will not wish to give away his stock-in-trade, which may beelements of coding or design tools which he would wish to reuse in other Website developments. In practice, the elements on a Web site may be broken downinto the following main constituents:
content
developer tools
client bespoke work
user data
escrow.
Content
Content may be provided by the client and so the client shouldretain intellectual property rights in relation to it.
Developer Tools
These may be elements of the site which represent thedeveloper’s stock in trade and which remain the intellectual property of thedeveloper. There could also be third-party components which the developer hassourced. In this situation, the client will want a licence to use the developertools free from third-party infringement. It is best if the licence forthird-party elements is direct from the third party to the client as otherwisethe client’s position will be uncertain should the relationship with thedeveloper terminate.
Client Bespoke Work
These may be elements of the site which have been speciallycreated by the developer for the client. These could include graphical imagesand look and feel. In these areas, the developer should be able to assigncopyright freely to the client.
In relation to materials which will be used or created by thedeveloper, the client will want to extract the usual warranties and indemnitiesin relation to intellectual property that might be found in a software licenceagreement. However, in the context of Web development, the position is perhapsmore critical in that the risk of third-party infringement is increased. Forexample, there is a method of Web development known as ‘an example-led designsolution’. It is common among Web developers to look for cool Web sites, viewthe source of the site and ‘borrow’ coding so that they can apply similarsolutions to their own sites. Whilst this might be an efficient way ofdeveloping a Web page, it is also the most efficient way of infringingintellectual property. Particular difficulties can arise with scripts or‘applets’ that provide functionality within a Web page. In one case, thedeveloper of a site borrowed some script from a third-party site which includedan instruction to run a program on the infringed third-party’s server. Everytime the infringing site ran this instruction, it caused the aggrieved party’sserver to crash, causing enormous business disruption. It took a long time totrace the cause of the problem which was finally isolated to the rogue Web siteand litigation immediately ensued. This raised arguments as to whetherintellectual property could, for example, subsist in a file name or HTML codingwhich perhaps has been generated by Web authoring tools. As with most cases, thecase settled without creating any authority.
User Data
One of the most valuable aspects of an interactive Web site isthe user data that is gathered by the site. This is perhaps an issue that shouldbe considered in the context of hosting services where the provider’s serverswill be gathering information about users and their activity on the Web site.The Web site owner will wish to obtain copies of the server logs applicable toits Web site. Most service providers furnish raw data without any additionalcost. However, providing more detailed analytical reports based on the logscould be an additional cost.
From a Data Protection Act point of view, it will be importantto ensure that the service provider undertakes to maintain the confidentialityof the server logs and not to disclose or use them for any other purpose. Inthis context, bear in mind the seventh principle under the Data Protection Act1998. This principle requires appropriate technical and organisational measuresto be taken against unauthorised or unlawful processing of personal data andagainst accidental loss or destruction of, or damage to, personal data. The Acthas express obligations upon data controllers where the processing of personaldata is carried out by a data processor on behalf of the data controller. Inorder to comply with the seventh principle, the data controller must ensure thatthe processing is carried out under a contract which requires the data processorto comply with obligations equivalent to those imposed on the data controller bythe seventh principle.
Escrow
Where access to the source code is required to carry outsupport or further development work on the site, then it may be desirable toenter into a source code deposit agreement (for example with NCC or Fort Knox)to protect the client in the event of the developer’s insolvency or failure toprovide support.
Warranties and Liability
Again, the considerations are similar to those encountered insoftware development contracts. Apart from warranties relating to intellectualproperty, which we have already discussed, the Web site owner will wish toextract warranties relating to the development and performance of the Web site.
A warranty of conformity with the specification is a cornerstonebut, of course, it may not be the complete picture as the specification will notbe exhaustive. There are a number of other warranties that are Web developmentspecific, including waranties that graphics will have a consistentcross-platform appearance and that the Web site and associated programs canhandle the maximum load that the client anticipates. A general warranty that thesite will be free of material defects is a useful sweeper to catch anyinconsistencies.
Recently, there have been a number of news reports of serioussecurity breaches with online banks. For example, Barclays’ customerscomplained of being able to view other bank customers’ account details. Onlearning of this, Barclays immediately took the site down to fix the loophole.However, the damage in terms of consumer perception was already done. Securitybreaches of this type are embarrassing, but would be insignificant when comparedwith the damage caused by a malevolent hacker engaging in fraudulent activity.For many Web sites, particularly those engaged in some form of e-commerce,security is an important issue. Warranties should be extracted from thedeveloper in relation to security, together with undertakings to install patchesfor the Web server and associated software to fix any security holes and to keepthem up to date within, for example, 12 hours of release. In the event of asecurity breach being identified, the developer could be committed to take thesite offline within, say, an hour of being notified. Ultimately, in the event ofa serious security difficulty, the client may wish to have the right oftermination of the agreement, coupled with a requirement on the developer toassist in the migration of the site to a more secure server.
As regards liability, the usual debate will ensue about theextent of any limitation of liability provisions. It is perhaps outside theremit of this article to go into the detail of limitation clauses. Suffice tosay that the issues that arise in relation to software development contracts andthe Unfair Contract Terms Act 1977 will also prevail in Web site developmentagreements. One of the points made at the beginning was that it is usually morefavourable for the Web site owner to present the developer with a contract,rather than rely on the developer’s standard form. If this is the case, bearin mind whether the contract will be on the supplier’s standard terms andtherefore whether the limitation and exclusion clauses will be subject to theUnfair Contract Terms Act.
One of the developer’s key concerns will be to ensure that hedoes not assume any liability for business being transacted on the Web site.Whilst the developer should not have any liability in regard to products andservices being sold or marketed by the Web site owner, he should be liable if,for example, the technology fails and does not allow the Web site owner togenerate sales or collect revenue as anticipated. As in many commercialcontracts, financial loss will be the main item of loss which the Web site ownermay suffer in the event of a breach of warranty on the part of the developer.Standard clauses which seek to exclude liability for loss of profits andeconomic loss, where this is a direct loss as opposed to an indirect loss, willnot be acceptable.
When considering any overall limit on the developer’sliability, in practice the most important consideration will be thedeveloper’s professional indemnity insurance. If none is available, then alimit equivalent to the total amount paid by the Web site owner (or a multipleof that number) may be an acceptable way forward. However, if insurance isavailable for a greater amount, whether the Web site owner should limit thedeveloper’s liability to a lesser amount is questionable.
Hosting
As mentioned earlier, Web site hosting may or may not form partof a Web site development agreement. If the developer is providing hostingservices, you may consider separating this out into a separate stand-aloneagreement. This is because hosting will continue beyond the development phaseand the client may want to terminate it independently of the ongoing obligationsunder the development agreement.
Performance Warranties
From the client’s point of view, the most important aspects ofhosting agreements relate to the performance levels of service which theprovider offers. Service level warranties could include:
service response and bandwidth – if a Web site is slow to respond, then it may be to do with its design or it may be to do with the servers or the bandwidth being made available to it
server downtime – inevitably, servers will need to be maintained and backups taken and this can lead to short periods of server downtime. Minimum levels of downtime can be contractually committed. If the client can tolerate no downtime at all then it may be necessary to consider mirrored servers.
Portability
One of the important issues with regard to Web site developmentand hosting concerns Web site portability. If, for whatever reason, the clientwishes to migrate the Web site from one provider to another, it will need thesupport of the developer and the host service provider. Contractual commitmentsin terms of the timetable for co-operating in any migration can be included toprevent the client becoming locked in to a single provider in circumstanceswhere the service levels are poor but for technical reasons it may be difficultto migrate the site without assistance from the developer.
Nigel Miller is a partner at Fox Williams and leads thefirm’s ecommerce group. He can be contacted by e-mail to nmiller@foxwilliams.com;Web: www.foxwilliams.com
