Drafting software development agreements

Publications >Drafting software developments issues for consideration

 

Software Development Agreements (Agreements) are unique.  In principle, they are not dissimilar to construction contracts, although clear issues arise that are unique to the information technology industry.  Broadly speaking the issues that both Software Developers (Developers) and purchasers of programming services (Clients) should consider can be categorised into the following non exhaustive list:

	Contract formalities;
	Pre-contractual negotiations;
	Scope of the Agreement and the deliverables;
	The specification and the requirements document(s);
	Intellectual property;
	Fee structure;
	Security issues;
	Restraints;
	Defects and modifications;
	Limitation of liability;
	Support; and
	General provisions.

 

Contract formalities

 

Formalities are an essential part of any Agreement for the agreement to be binding on the parties, however in the case of Software Development Agreements, particular care needs to be paid to the following:

	The recitals should include the assumptions on which the Agreement is based including an overview of the roles of the parties to the Agreement; and
	Definitions of all important (and frequently used) terms should be included in the Agreement so as to minimise confusion or ambiguity.

 

Rigor in documentation

 

In general terms, the more work that is involved in any sort of development (be it a software development or a building for that matter) the greater the attention that should be paid to the details of the specification and the contract itself.  For example, an Agreement to develop a simple HTML website for a small business costing a few thousand dollars is unlikely to result in much (if any loss) if something goes wrong, therefore the Agreements are generally very loosely defined (if documented in writing at all).  Conversely the development of an ERP system or high volume transaction based website, can, if something goes wrong can cause significant loss for the Client’s business, therefore creating risk for the Developer of the software that should be mitigated and documented in an Agreement very carefully.

 

Pre-contractual negotiations

 

Consideration should be paid to the extent that pre-contractual negotiations are incorporated as terms of the Agreement. Care should be taken by both parties to ensure that:

	statements made during pre-contractual negotiations are not able to be incorporated as terms of the Agreement, alternatively, that they are accurately documented in the Agreement; and
	statements made are not misleading and deceptive under the terms of the Trade Practices Act 1974 (Cth) see Unisys Australia Ltd v RACV Insurance Pt Ltd & Anor [2004] VSCA 81 (14 May 2004).

Scope of the Agreement and the deliverables

 

Once again care needs to be paid the detail in the contract to ensure that the deliverables are adequately documented.   For example:

	What is the development timetable?
	Will the deliverables be staged with resultant acceptance testing and payment schedules?
	What is the software development process ie classic waterfall, rapid application development or something else?
	How does this affect the specification and the project management approach?
	How will variations from the specification be handled? What variations cost?
	Who is responsible for the preparation of the specification and requirements documents?
	Will any specific personnel of the Developer have to work on the software?
	How is acceptance testing managed and documented?
	What warranties are offered in regard to performance criteria, run times and response times that need to be documented?
	What is the duration of the Agreement?
	Are delivery dates essential terms of the Agreement?
	Describe any additional software that is needed to run the software ie servers infrastructure. Who is to pay for this?
	What happens if delivery dates are missed?
	Will the Developer warrant that the software will work on upgraded versions of current server operating systems?
	What level of system documentation will the Developer have to supply to the Client?

What are the Client’s obligations?

	How long does the Client have for acceptance testing?
	Who is the Client’s Project Manager? Will they need to nominate an alternate?
	Will an acceptance testing certificate(s) be issued?

 

The specification and requirements document(s)

 

Considering that there is no universally accepted format for the specification and requirements documents, care should be taken that it is sufficiently detailed so as to enable it to be enforced.  In practical terms Developers need to be able to have their code measured against this standard so as to be able to make a claim for payment.  Issues in this respect include:

 

	Is the specification sufficiently detailed and in a format satisfactory to both parties?
	Is installation, documentation and testing etc included?
	Has the Client warranted that the requirement represents the wishes of the Client's organisation?
	What is the procedure for variations to the specification?

 

Intellectual property (IP)

 

Perhaps the first question that should be asked is whether the Client wants to own the code, or whether the Developer wishes to own it and license it to the Client.  If the business model is a license, then the software development Agreement will then need to be augmented by a license Agreement.

Therefore the following issues needs to be considered:

	Who will be the owner of the intellectual property that is developed?
	If intellectual property rights are to be retained by the Developer, what are the terms of the licence to the Client?
	Non transferable or assignable (what if the business is sold or becomes insolvent);
	What limitations are to be placed on the use of the product?
	Does the license to use the software include your library code?

 

IP indemnities

	What warranties will the Developer provide to the Client in regard to the intellectual property?
	Will the Developer indemnify the Client if the software is found to infringe another party’s intellectual property?

 

Fee structure

	What fees will the Developer charge?
	How are the fees calculated? If there are various fees and charges, then they should be included in a schedule;
	Will there be progress payments, if so how are they approved, and who approves them?
	Do fees include of GST?
	Will interest be payable on overdue fees or instalment payments?
	Can the Developer cease development if a progress payment has not been made?

 

Security

	What are the Client’s obligations for security and unauthorised use of the software?
	How is the confidential information that may be contained in the data dealt with by the Client and the Developer?
	Are separate confidentiality agreements required with the Developers staff?

 

Restraints

Do the parties wish to restrain each other from doing certain things? (the Developer from competing with the Client, and the Client from poaching the Developers staff and vice versa?).

 

Defects and modifications

	How will the Developer deal with defects that arise after acceptance testing is completed?
	How are defects reported and over what timeframe must they be fixed?
	What is the procedure for making variations to the system after it has been installed?

 

Limiting the liability of the parties

 

Where there is a likelihood of significant loss to the Client where the software does not perform according to their expectations or requirements, or alternatively is mission critical, then particular attention needs to be paid to issues associated with consequential loss.  Issues to consider include:

	Appropriate professional indemnity insurance for the Developer;
	How is liability for loss is calculated;
	Will liability be limited to a defined amount or not at all? (the enforceability of this should be considered);
	Should the Developer be indemnified for loss suffered by third parties?
	Where the potential risk is great, particular consideration needs to paid to liability issues.

Support for the software

 

After the software has been installed and is working according to the specification, what support does the Developer have to provide the Client? It is usual practice for Developers to enter into a separate Agreement in relation to support (Support Agreement) that will address various issues (including but by no means limited to issues associated with):

	What is the duration of the Support Agreement?
	Is renewal of the Agreement automatic or subject to certain provisions?
	Is support exclusive, or can it be done by others either in-house or external?
	If part of a multi-user arrangement, does the Client have to upgrade to new versions, or will the Client have the option of choosing to upgrade?
	What level of support is provided and what are the conditions around response times and hours of operation?
	What warranties are offered in regard to performance criteria, run times and response times that need to be documented?
	What must the Client provide to the Developer, for example access to staff for training, training rooms?
	What training will be provided by the Developer?
	What services are excluded from the support Agreement?
	Will the Developer have physical access to the Client’s premises? If so on what terms?
	Will the Developer have access to the Clients servers? If so on what terms?
	How are requests for support managed?
	How can the support Agreement be terminated by either party?
	Can the Developer subcontract the Agreement?
	What access will you need to your customer’s site, personnel, software and equipment
	What operating system will the software run on?
	Who will install and configure additional hardware for the software to run on?

 

General provisions

 

The following non-exhaustive list of considerations relate to the general provisions in the Agreement:

	Do financial undertakings need to be obtained from either the Developer or the Client?
	Do the Clients (or the Developers) need to obtain insurance if so what is the extent of coverage? If so are certificates of currency required to be produced?
	How can the Agreement be terminated?
	In the event of a dispute, do the parties wish to force each other to enter into mediation before litigating the Agreement?
	What warranties will be provided by the Developer about the performance of the software?
	Can the Agreement be assigned, novated or sub-contracted by either party?
	If there is a dispute over the Agreement, which court would it be decided in?
	What clauses do the parties want to be able to survive the termination of the Agreement?
	What levels of warranty will the Developer be providing to the Client?
	In the event of a dispute, do the parties wish to force each other to enter into mediation before litigating the Agreement or is there another method for resolving the dispute which should be documented?
	Can the Agreement be assigned, novated or sub-contracted by either party?
	If there is a dispute over the Agreement, which state or territory would it be decided in?

The above is by no means exhaustive, however it aims to show the level or rigor that should be applied to Software Development Agreements and the risks that need to be mitigated by Developers and Clients alike.

 

"The information contained in this article is general in nature and cannot be regarded as anything more than general comment. Readers of this article should not act on the basis of this comment without consulting one of Rostron Carlyle's legal practitioners who will consider their particular circumstances".

 

Expertise

 

Rostron Carlyle's lawyers have a wide range of experience assisting people in all aspects of IT & Software Development Law.

 

Not only will you find that Rostron Carlyle is likely to have assisted someone in your exact situation, but you’ll find that a Rostron Carlyle lawyer can distill a complex legal issue into a set of actionable options for you to consider.

 

A Rostron Carlyle lawyer will be a person that you can relate to.  We'’ll talk your language. Most

importantly, a relationship with a Rostron Carlyle lawyer will be "a relationship you can rely on".

 

more legal services