Software Development Agreements: Put it
in Writing, Part II
By Eric S. Freibrun, Esq.
Software developers and their clients who
embark on development projects without clear written agreements stating each party’s
responsibilities -- and defining the expected results -- have often unwittingly sown the
seeds for future conflict. In May’s issue, we covered some of the reasons why both
developers and their clients should have a detailed written agreement governing their
projects. We also reviewed some of the critical provisions such an agreement should
contain and a variety of positions each party should reasonably expect the agreement to
reflect. This month’s article addresses how software development agreements typically
address these key areas: scope changes, payment terms, ownership rights, and warranties
and liability.
Scope Changes
Changes in project scope or software
functionality from what the parties originally envisioned are almost inevitable during a
custom software development engagement. Disputes between the developer and the client
often arise concerning whether the developer was obligated to make a change, who should
bear the cost of the change, the cost itself, and who should be responsible for any
resulting delay.
A written development agreement should
state a clear mechanism for requesting, approving and implementing any changes in scope or
software functionality. The procedure should require the client to request the change in
writing and the developer to respond, again in writing, with a proposal describing the fee
and schedule impact of implementing the requested change. The developer should not be
obligated to proceed with making the change until the parties have agreed on the cost and
schedule impact, as well as the specifications for the revised software. In the absence of
a clear contractual provision addressing change orders, the developer is particularly at
risk in fixed price projects. The client might request a change it perceives to be minor
but which actually entails a significant amount of extra effort by the developer.
Payment Terms
Software development engagements are
typically paid for on either a fixed price/milestone or time and materials basis. Since
developing software is extremely labor-intensive and complex projects can take years to
complete, the developer will usually prefer to be paid on a time and materials basis so as
to recoup all its costs and maintain its profit margin. The client will usually want the
job to be done on a fixed fee basis so as to be able to budget for a known expense.
It is hardly reasonable for the developer
to be expected to fund the entire development process and wait until project completion
before receiving any payment. Accordingly, many development agreements provide for regular
periodic payments. An initial payment may be made upon signing the agreement, followed by
a second payment upon completion of the detailed design specification phase. Subsequently,
payments can become due after completion of the coding phase, completion of the program
testing phase, and finally, upon successful acceptance testing including operation of the
system in production using live data.
The client will typically want to avoid
making large payments at the beginning of the project so as to keep the developer’s
interest in performing promptly. Similarly, in order to maintain an incentive for the
developer to provide needed assistance during the often painful conversion from an old
system to a new one, the client may find it useful to withhold a final payment until after
the system has proven itself capable of successfully operating in a live environment for
some period of time, e.g., 90 days.
A very clear payment schedule in a
written agreement also benefits the developer. Once a project milestone has passed, the
developer can rightfully refuse to proceed with further work until it receives the
required payment.
Ownership Rights
The area of ownership or proprietary
rights presents a challenging and complex range of issues. Without a written contract
clearly stating the parties’ agreement on ownership of the software created by the
developer, copyright law will apply to vest ownership of the copyright in the developer.
Ownership of the copyright is, for practical purposes, ownership of the software. The
copyright owner has the exclusive rights to copy, distribute and modify the software. The
client will own the actual copies of the software delivered by the developer and residing
on its computers, but without ownership of the copyright it cannot market, distribute or
duplicate the software.
In many cases, however, the client may
only be interested in using the software for its internal business purposes, in which case
ownership of the software, as opposed to a license to use, is not a critical concern. The
client may object, however, if after paying millions of dollars to fund the development of
new system, the developer then wishes to commercially distribute the software to others,
including the client’s competitors.
One way to resolve this concern is for
the client to receive royalties from the developer’s further distribution of the
software. While there are no standard guidelines as to the amount of the royalty, it is
not uncommon for the royalty to terminate once the client has recovered the cost of the
software.
Warranty & Limitation of Liability
Software is so inherently complex that
even the most extensive battery of acceptance tests will not uncover every programming
error. Some will usually be found after the system has been delivered and the client
begins using it. Accordingly, the client should insist on a provision in the written
agreement requiring the developer to fix software errors at no charge for a specified
period of time.
Typically, the developer will be expected
to warrant that the software will substantially conform to agreed upon performance
specifications. If it doesn’t, the developer will be expected to correct the defect
if it is brought to its attention within, e.g., 120 days of a specified date, such as the
date the client accepts the software.
The developer will want to limit its
warranty responsibility to correcting the defective software brought to its attention
during the warranty period. A carefully drafted warranty provision will usually include a
disclaimer of all other warranties other than the one specifically stated, along with a
clause limiting the developer’s total liability under the contract. For example, if
the developer is unable after numerous attempts to correct defective software and it
remains unusable to the client, the developer will not want to be responsible for
potentially ruinous "consequential" damages, such as the client’s lost
business opportunities or lost profit. A reasonable remedy for the client in this
situation may be a complete refund of the fees paid to the developer.
The client’s remedies and the
developer’s liabilities are very often hotly negotiated issues. Without a written
agreement limiting its liability, the developer’s liability is potentially unlimited,
which may be the most compelling reason of all for the developer to insist on a written
agreement. Conversely, a carefully drafted warranty clause gives the client specific
enforceable rights and a bit more comfort than the developer’s verbal assurance,
"don’t worry, we’ll fix it."
[This article is provided for general
informational purposes only and does not constitute legal advice. Everyone’s
situation is different and requires specific analysis.]
Attorney Eric Freibrun specializes in
Computer law and Intellectual Property protection, providing legal services to information
technology vendors and users. Tel.: 847-562-0099; Fax: 847-562-0033; E-mail: eric@freibrun.com.
Copyright © Eric S. Freibrun, Esq., Law Offices of Eric S. Freibrun, Ltd. All rights
reserved.
