Just now I have four sets of instructions relating to web design: two for developers and two for businesses that want to commission new websites. It is therefore a good opportunity to write down a few tips.
1. Resist the Temptation to Copy an Existing Contract
As with other commercial contracts, there is an enormous temptation to copy other folk’s design contracts. Sometimes this is with the developer’s consent but more often than not it is without it.
A contract is just as much a copyright work as code. Just as someone has paid you a lot of money to design and develop a website, someone else is likely to have paid a solicitor or barrister some money to draft the agreement. Copying a lawyer’s work is no more acceptable than copying a developer’s.
Even if you do have a developer’s permission to copy his or her agreement you may not necessarily be in the clear. As you know from your own business, copyright belongs to the person who writes the software unless there is a contrary agreement. Some web designers assign copyright in their work to their customers but most grant non-exclusive licences. That is also the case with most lawyers.
But, quite apart from legalities, copying someone else’s contract is unwise. Contracts set out the rights and responsibilities of the parties to a transaction. The interests of any two businesses are likely to be different and even the rights and responsibilities of the same party are likely to vary from transaction to transaction. Using an agreement that was designed for a different situation that the parties do not fully understand can lead them both into litigation.
“But lawyers are expensive and times are hard”, I hear you say. So they are but you can save money if you follow these tips.
2 KISS (Keep it Simple, Stupid)
The longer and more complex the terms or agreement the more likely it is to lead to disagreement. And if such a disagreement leads to litigation, arbitration or other dispute resolution process, the longer and more expensive will be the proceedings. Clauses should generally consist of no more than one sentence and each sentence should consist of no more than one subject, verb and object. Where that is not possible such as where different consequences are to follow different events, the draftsperson should set those out in short numbered or lettered paragraphs.
3. Avoid Jargon both Legal and Technical
The agreement has to be understood and implemented by business people or techies with no formal training or interest in the law so avoid log winder legal terminology wherever possible for their sake. However, it may have to be interpreted and applied by judges or arbitrators with no understanding or interest in technology who think wireframes are a pair of spectacles and CSS is something to do with George Osborne. So stick to the plain, simple, elegant language of the great writers of English literature that both techies and lawyers understand.
4. Incorporate as much as possible by Reference
If you are likely to need the same provisions in all your contracts why not park them in standard terms of business and incorporate by reference into individual contracts? If you design, develop and code according to a methodology, why not write it down in a manual and refer to the manual in those contracts. You can also do that with specifications such as functionality in specified browsers, the features and functions of a content management system or the use of a hosted solution.
5. Stick a Copyright Notice on Your Proposals
You put a lot of work into your proposals. The last thing you want is for a prospective customer to take one of them to a competitor and invite him to beat your bid. It is very difficult to proved that sort of skulduggery but one thing you can do is insert a notice stating that
- the proposal is a copyright work,
- its contents are also confidential,
- it is submitted to the customer for the purpose of evaluating your bid only and for no other purpose; and
- it is not to be copied or disclosed to anyone else without your prior, written consent.
6. Specify precisely what the Developer has to deliver
It is amazing how many contracts are silent on that point. The best way to make clear what the developer has to do is to incorporate his specification into the agreement either as a schedule or by reference. A good specification should list the features and functions of the website, its software components, the programming languages in which they are written and so on.
7. Set Objective Acceptance Criteria
Most contracts provide for the developer’s fee (or if a deposit has been taken the balance) to be paid on acceptance. Even in the most amicable transaction there is scope for disagreement between supplier and customer as to when that point is reached. The best way to avoid dispute is to set some objective criteria that can easily be verified such as the delivery of components or the processing of test data.
8. Guard against copyright infringement
As there is no copyright registration in the UK and most other countries the developer cannot always tell whether his customer owns the photo, artwork or text that you are asked to upload, By the same token from the customer’s point of view, not all web designers are squeaky clean. The answer is to require the opposite party to represent and warrant that he or she owns or is licensed to reproduce all the material that he or she offers you and to back it up with an indemnity against infringement claims by third parties. If that party has no assets you should also oblige him or her to take out insurance.
9. Make adequate provision for change control
If a customer wants functions and features that go beyond the spec he or she should expect to pay for it. But who in the customer’s organization should be allowed to request those extras? A difficulty that often arises is when changes are requested orally by an employee who has no authority to bind his company. The best way to avoid this problem is to require changes to be agreed in advance in writing and such agreement t be signed by a designated representative of the customer’s company.
10. Insert a dispute resolution clause.
Sadly some website development contracts end in tears. Unless the parties choose some other form of dispute resolution there is a risk that the parties will end up in court. And as everybody knows, litigation in England and Wales can be ruinously expensive. Some draftsmen insert elaborate escalation clauses into commercial contracts but these can actually prolong the dispute and increase the expense as the superiors repeat the posturing of the managers below. Mediation is becoming increasingly expensive and protracted. The least bad option is mediation to be completed within a very short time followed by arbitration before a specialist tribunal. This is my standard mediation clause:
“Any dispute or difference between the parties will be referred to mediation in accordance with the NIPC Mediation Rules by a mediator agreed by the parties or, in default of agreement within 14 days appointed by the Managing Director of NIPC Ltd.””
In case mediation fails I usually insert something like this:
“(1) Any dispute or difference between the parties shall be referred to arbitration before a single arbitrator agreed by the parties or, in the absence of agreement within 14 days of the reference, appointed by the managing director of NIPC Ltd.
(2) The seat of the arbitration will be England and Wales,
(3) The NIPC Arbitration Rules will apply.”
The WIPO also has an arbitration and mediation service and the IP Office aranges mediation.
These are my first 10 tips. I shall add to them in subsequent posts.