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: [email protected].