This checklist is designed to help those new to software development agreements ensure that they have considered the principal issues that a typical agreement should cover. It also provides a little guidance as to the different approaches to some of the issues.
I have categorised each issue under one of these headings:
- the software design and development process
- developer and customer testing
- intellectual property rights and licensing
- software installation and integration
- warranties and indemnities
- support, maintenance and service levels
- updates and upgrades
- other ancillary services
- source code escrow
- contract variation and change control
- termination and its consequences
- dispute resolution
The software design and development process
Design and development processes vary considerably depending upon the size and experience of the development team, the nature and complexity of the software, the demands of the client, and the development methodologies employed. Nonetheless, there are a number of almost universally valid questions that should be considered when preparing the software development agreement:
- In what document or documents will the specification be set out?
- By what process will the specification for the software be agreed or elaborated?
- How might the agreement or elaboration of the software specification affect charges and other contract terms?
- What will be the client’s involvement in the design and development process?
- What is the timetable for the development of the software?
- In what circumstances, and to what extent, should the timetable be flexible?
Developer and customer testing
Testing is built-in to modern software development techniques, but it is also often an express requirement of software development agreements.
Will the developer and/or the customer have a contractual obligation to test the software?
- Which specific tests will be used, and at what point or points must they be performed?
- What access will the client have to the results of tests undertaken by the developer, and vice versa?
- How will the results of the tests be evaluated?
- What will be the consequences of that evaluation process?
- Will testing form part of a formal software acceptance procedure?
Intellectual property rights and licensing
Software is protected primarily by the law of copyright, with particular elements of a software system sometimes benefiting from the protection of other intellectual property rights. Because using software always involves copying software, the developer must grant a licence to the customer, or must assign the required intellectual property rights to the customer.
- What intellectual property rights subsist in the software?
- Are different licences required for different software modules or elements?
- Will the software, or any element of the software, be open source? If so, which open source licences are or will be used?
- Are any other third party licences required?
- What licensing/charging model will be used, and how will this affect the drafting of the licence itself?
- What will be specifically included / excluded from the licence?
- What sub-licensing rights does the client need?
- Will the client have any rights to modify the software and/or access the software source code?
- Will any rights be assigned (i.e. transferred) from the developer to the client?
Software installation and integration
Before use, software usually needs to be installed, configured and integrated with other software systems. Sometimes the developer will take the lead in this process, sometimes the client. In either case, it is important to clarify in the development agreement the extent of the developer’s obligations.
- Which party will install, configure and integrate the software?
- What level of cooperation will be required from the other party in connection with this process?
- How will technical challenges arising from this process be dealt with?
- Will developer service in this area be subject to separate charges?
Warranties and indemnities
Warranties and indemnities are used to allocate risk between the parties to the contract. Warranties are promises that a particular state of affairs obtains; indemnities are undertakings to compensate by a defined measure (usually going beyond standard contractual damages) in defined circumstances.
- To what extent will the developer guarantee that the software will not infringe any third party intellectual property?
- Will the developer indemnify the client if the software does infringe a third party’s rights?
- Will IP infringement indemnities in the contract be subject to the standard quid pro quo: rights for the developer to control and conduct the dispute and any settlement with the third party?
- Will the developer give specific warranties as to the performance, stability or security of the software?
- What other warranties and indemnities should be included in the agreement?
NB for more information about indemnities in IT contracts, see:
Some, but not all, software development agreements include support provisions. These range from the very simple to the very detailed. If you plan to include support provisions in your agreement, you should consider the following questions, amongst others.
- How will support be provided: by email, telephone, in person?
- What types of questions and problems will be covered by the support services?
- Will specific commitments be given by the developer in relation to support services, such as specified acknowledgment, response and resolution times?
- What if any limits will be placed upon the provision of support services?
- In what circumstances will support services be chargeable?
- Will the details of support services provision be set out in a separate service level agreement (commonly attached to the main agreement as a schedule or annex)?
Maintenance services, updates and upgrades
Standard software programs tend to change quickly. Indeed, if they are to continue in use, software programs have to change to keep pace with changes in other software programs upon which they depends or with which they integrate. Custom software produced under a software development agreement may also need to be updated and upgraded.
- What sort of updates and upgrades will be necessary to deal with technological changes?
- Will additional functionality be requested by the client, and should this be addressed through maintenance provisions?
- What specific updating and upgrading obligations will there be in relation to both standard software modules and custom software elements?
- Which party will apply the updates and upgrades?
- Will updates or upgrades be forced?
- How will updates and upgrades interact with support services obligations?
Other ancillary services
Typically, a software development contract may provide for training and consultancy services, in addition to the core services.
- Will the scope of ancillary services be defined at the outset, or subject to later agreement?
- Can the developer refuse to provide the ancillary services, either generally or in defined circumstances?
- How will the developer be remunerated in respect of ancillary services?
Source code escrow
Software systems are critical to many business, and they may not be easily or cheaply substitutable; in practical terms, they may not be substitutable at all. This can leave clients at the mercy of their software vendors. For instance, if a vendor goes to the wall, how will the client maintain the software? That’s where source code escrow (the holding of source code by a trusted third party to be released upon defined release events) comes in.
- Who will or may act as escrow agent?
- What is the timetable for entering into escrow arrangements?
- How is “source code” defined in respect of the escrow arrangements?
- What obligations will the developer have to keep the source code held by the escrow agent up-to-date?
- What events will give rise to a release of source code?
- On what basis will the source code be licensed to the client in the event of release?
- Will a distinct escrow agreement be annexed to the main software development agreement?
Contract variation and change control
The world changes, and contracts must change too. Contractual variations can be as simple as an exchange of emails, but you need to beware of the possibilities of accidental, unauthorised or ill-considered changes.
- Will either party have any (limited) right unilaterally to vary the software specification or the contract generally?
- Should a formal change control procedure – usually taking the form of an exchange or series of exchanges of written notices – be introduced?
Termination and its consequences
It pays to take great care when drafting clauses governing termination and the consequences of termination.
- In what circumstances can the agreement be terminated?
- Does termination of the agreement imply termination of licences in the agreement?
- Generally, which provisions of the agreement will survive termination?
- Where a licence has been terminated, what if any obligations will be placed upon the client to remove the software from its systems, return materials to the developer and formally attest that it has done so?
- Will any charges be refunded in the event of termination?
- Will any additional charges be payable after termination?
Whilst one purpose of an software development agreement is to avoid disputes, the risk of a dispute cannot be altogether eliminated. Another important purpose, then, is to ensure that disputes are handled effectively.
- Which law will govern disputes under the contract?
- Will the parties submit to any form of alternative dispute resolution (such as mediation or expert determination)?
- If so, will all disputes be referred to ADR, or only some disputes?
- If the courts are to have jurisdiction to adjudicate disputes, which courts?
If you think of any other questions that should be asked, please post them below, and I’ll add them to the list.