Marc is a patent attorney and shareholder of Poms, Smith, Lande & Rose, one of the oldest intellectual-property law firms in Los Angeles. Marc specializes in computer law and can be contacted at meb@delphi.com.
Developing software under contract is a risky business. Software is rarely finished on time, cost overruns are common, and something invariably turns out not to work.
A well-written development contract is essential to maintaining a good business relationship while you sail these stormy waters and to avoiding the expense and embarrassment of a lawsuit. Unfortunately, software developers and their clients often do not give careful attention to their written contract until after a dispute arises. By then, it is usually too late.
In this column, I'll cover many of the most important clauses to consider. Review them now, and save yourself trouble later!
You would be amazed at the number of contracts that do not clearly identify the parties to the contract.
This is more than a mere matter of form. Only parties to a contract have the legal obligation to perform it and the legal right to receive its benefits. When a payment is not made, you want to be absolutely sure you know who owes that payment. Similarly, when the software fails or is not delivered on time, you want to be sure that you personally are not held liable when it is your company that is receiving the payment.
The legal capacity of each party to a contract should be specified, as well as its exact legal name. Is it a corporation? Is it a partnership? Is it an individual doing business under a fictitious business name? All personal assets of an individual can usually be reached to satisfy a judgment against a fictitious name under which the individual is doing business. If a party is a member of a larger corporate structure (for instance, a subsidiary), the contract should also make crystal clear which entity within that structure is the contracting party. A parent is normally not liable for the debts of its subsidiary, nor is a subsidiary normally liable for the debts of its parent. When contracting with a business that has limited assets, consider asking for one or more personal guarantees.
You would never go to a dealer and buy a new car without carefully reviewing its list of options. Yet, software development often proceeds without the parties first having made sure that they each have the same understanding of what will be done. Such a blind approach is a time bomb waiting to explode. Don't let it happen to you.
Detail in writing the functions the software is expected to perform and the results it is expected to achieve. Sufficiently detailed specifications provide clear, objective standards by which the software can be judged. The more expensive the contract, the greater the detail. Don't forget to specify the operating environment, including hardware (processor type, RAM size, storage speed/size, and so on), operating system(s), and necessary (and prohibited) peripherals.
In many cases, the development of these specifications constitutes part of the work for which the software developer has been hired. In these situations, the specific details are not known at the time the contract is signed; nevertheless, general guidelines should be specified in writing. The contract should also contain a clause requiring the developer to later present the detailed specifications in writing to the client for review and written approval.
The contract should address whether the developer will be providing any services or materials beyond the software itself. For example, will the developer be converting existing data to run with the new software? Must he install the software, train users, or provide other user support? Must he be available to make upgrades?
One important area often not clearly delineated concerns documentation. Must the developer provide user manuals? Must he provide documentation sufficient to enable another developer to continue with the development, such as source-code listings, descriptions of subroutines, data descriptions and standards, and flowcharts? Clients often do not realize the importance of this material until long after the contract is signed. Developers, on the other hand, know that these materials are expensive to provide and sometimes use silence as a vehicle to omit them. That is a mistake. The contract should clearly specify the documentation the developer will provide and the documentation he will not.
Invariably, changes in the software will be requested during development, as well as changes in the associated materials and services that the developer is to provide. Unless documented in writing, misunderstandings concerning the costs and deadlines for making these changes may arise.
The contract should include a clause requiring all changes to the contract to be recited in writing and initialized by all parties. In addition to specifying the exact nature of the change, the writing should set forth whether the developer will receive any additional compensation for the change or additional time for making it. For the protection of the developer, the contract should provide that the developer is not obligated to make any change not agreed upon in writing. To protect the client, the contract should provide that the developer will not be paid or receive additional time for any change not approved by the customer in writing.
Cooperation with the client is often required during the development of the software. For example, the developer may need to meet with the client's staff to determine the operational requirements for the software and to review the developer's proposed specifications. The developer may also need access to the customer's equipment.
The contract should specify each required area of client cooperation. The more detailed the specification in terms of time and frequency, the better. Without this clause, it may be difficult for the developer to later excuse a delay in delivery caused by a lack of cooperation on the part of the customer.
Another fertile area for misunderstanding is scheduling. The client often has one expectation, the developer another. A good contract should never allow this to occur.
Deadlines for all stages of the software development should be specified. If the developer is to design the specifications, when will they be presented to the customer? How long does the client have to approve them? When will the first version of the software be ready for testing? How long will it be tested? When will the tested software be finished, fully operational, and ready for delivery? How long will the developer have to correct bugs that are discovered later?
A specification of what is to be delivered is just as important as a specification of when delivery is required. The contract should clearly describe exactly what the developer is to deliver. In addition to object code, is he to deliver source code? Also, what form will the delivery take? Will the software and documentation be on a floppy, CD-ROM, or tape?
Some contracts provide that the developer need not deliver the source code to the client. This approach forces the customer to use the developer for upgrades to the software and, as a practical matter, to fully pay for the software to get postdelivery help. For the protection of the customer, the contract should require the developer to deposit a copy of the source code with an escrow with instructions to turn the source code over to the customer if the developer breaches or is otherwise unable to continue his performance.
Payment, of course, is usually the only topic given consideration by the developer. Naturally, the contract should be clear about it.
The contract should specify the basis of the payment. If it is a fixed-price contract, that price, of course, should be specified. If based on time, the hourly rates of the various individuals (or classes of individuals) should be specified. If reimbursement for expenses can be requested, the types of reimbursable expenses should be itemized.
The deadlines for making payment should also be clearly specified. Most agreements provide for a series of payments, including an initial payment when the contract is signed. For substantial projects, it is often also useful to require the developer to provide detailed reports and invoices as a condition to each payment. This ensures the customer that the developer is on schedule and reduces the chance of the customer raising an objection to an allegedly problematic matter that was clearly disclosed in an earlier report or invoice.
Customers usually want the contract to provide that their final payment is subject to some form of validation, verification, and testing. This is usually a fair request which cannot easily be refused.
But safeguards can and should be built in. The contract should specify the types of tests which will be done, the identity of the testers, who will pay for the expense of the test, and how much time will be allowed for the test. Most importantly, the contract should specify an objective standard by which the success of the test can be measured.
Customers would be wise to insist upon the software being tested by someone other than the software developer. In addition to obvious bias, the developer often fails to operate the software in the sequences that cause a problem. After all, the developer usually designed the software to handle all of the operational sequences that he or she can foresee. Someone other than the developer may well operate the software in an unforeseen sequence, and it is this type of unforeseeable sequence that needs to be tested the most.
The agreement should clearly specify who owns the intellectual property that relates to the development work, as well as the tangible materials that are received or created in connection with the developer's work. This includes rights to copyrights, patents, and trade secrets. A variety of specialized concerns might need to be addressed.
One such concern arises when the developer uses independent subcontractors. Under copyright law, title to a copyright created by an independent contractor will usually not pass to either the developer or the customer unless the independent contractor signs an agreement promising to assign that copyright. If the customer wants to retain ownership of all copyrights in the developed software, the contract should require the developer to procure such written subcontracts with each independent subcontractor. Even in the absence of a requirement for such subcontracts, the developer would be wise to nevertheless procure them. Otherwise, he might be unable to deliver full title to the customer and hence be in breach of his obligation to do so.
Developers often use in-house subroutines in their software. If the developer wishes to retain the right to continue to use these subroutines in connection with software for other customers, the agreement should provide that ownership of these subroutines remain with the developer. Similarly, the agreement should excuse the developer from delivering title to underlying commercial products that the developer has chosen to incorporate into his design.
Sometimes, the customer may want to modify the software. The agreement should specify whether the customer has this right and, if so, who owns the resulting work.
In general, it is normal for the customer to obtain all rights in original software purchased for resale. On the other hand, the customer usually receives only a license (with the developer retaining title) to software developed merely for use by the customer. When only a use license is granted, the contract should specify whether the customer has the right to transfer his license to another and whether the developer is then entitled to receive additional compensation.
Customers often provide developers with highly sensitive information during development. Developers similarly often provide customers with equally sensitive information, sometimes including the software itself. When this occurs, the customer, developer, or both may often want that confidential information to be protected.
The contract should require that the customer, developer, or both use reasonable efforts to protect the confidentiality of this information. It should further provide that the party providing the protection will not use or disclose the confidential information to others, except to reasonably further his performance under the contract. All confidential information that is to be protected should be specifically identified.
A "confidentiality" clause should be included, even when the parties have a high degree of confidence in each other's integrity and competency. The absence of a "confidentiality" clause is often cited by courts as a reason for refusing to protect what otherwise would be enforceable rights in trade secrets.
Another approach often used to protect the value of the software is to include a clause prohibiting the developer from developing similar software for a competitor or from directly competing with the customer. These clauses will be enforced in many states if they are reasonable--that is, if they are limited in duration, geographic area (when appropriate), and areas of competition. However, in some states (California, for example), even reasonable restraints on competition will usually not be enforced. If you have made a noncompetition promise that you no longer wish to honor, legal research can determine whether you are likely to be bound to it.
Normally, the contract provides that the software will conform to the agreed-upon specifications, meaning, of course, that it will work. A clause is sometimes included also making the developer liable if the software infringes a patent, trademark, copyright, or trade secret owned by another. Liability may also be imposed upon a developer who fails to deliver the software on time.
In many instances, these liabilities will be imposed upon the developer, even if he or she does not expressly promise to assume them in the contract.
Read this section carefully!
The liability imposed upon the developer may often far exceed the amount of money the developer is paid.
What can developers do to protect themselves? The answer can be stated in three words: Disclaim, disclaim, disclaim!
The contract can disclaim all liability for what is known as "consequential damages"--damages caused by defective software or its late delivery, such as lost profits, injury to reputation, and damage to data.
The contract might also provide that the developer is to correct any deficiencies in the software within a stated number of days after they are brought to the developer's attention, and that such correction is the sole and exclusive remedy that the customer has for a defect in the software. The contract might also limit the period of time following completion of the software during which the developer shoulders this responsibility.
Courts do not always enforce disclaimers. Usually, a court will refuse to enforce a disclaimer for one of three reasons:
Another method to protect against large liabilities is to require liability insurance to be purchased. The customer can be required to make the purchase and to name the developer as an "additional insured" or vice versa. Sometimes, a customer's existing commercial general-liability policy can be inexpensively amended to name the developer as an "additional insured." The type of liability that must be insured should also be specified.
In the absence of express language, a material breach provides the aggrieved party with the right to stop performance. Thus, if the customer misses a payment, the developer can usually stop work. On the other hand, if the software is behind schedule or is not working, the customer can often stop making payments.
These legal rights can and often are modified by the contract. For example, the contract can be written to give the developer a stated number of days following written notice of a defect or untimely delivery to cure that problem before the customer can start withholding payment. The contract can similarly give the customer a stated number of additional days to make a late payment after receiving a late-payment notice from the developer, before the developer can stop work.
It is usually difficult for both parties to the contract to predict the damages that might arise because of a breach in performance. This is particularly true for the developer.
To limit liability, a "liquidated damages" provision is sometimes inserted. Such a clause specifies an exact amount of money that the customer will receive because of certain breaches by the developer. For example, it may provide that the customer will receive $100.00 for each day the software is late or $500.00 for each defect in the software. If both parties are reasonable, the use of a "liquidated damages" provision often eliminates disputes that otherwise might arise.
Development contracts sometimes provide that all disputes arising in connection with the contract must be resolved by arbitration, rather than court litigation. Arbitration is usually faster and far less expensive than court litigation.
The contract can also contain a clause providing the prevailing party with an award of reasonable attorney fees, in addition to all other relief, whether the dispute is resolved by arbitration or court litigation.
It is often difficult to predict whether either of these clauses will be beneficial. Among the factors considered are the relative wealth of the parties and the perceived likelihood of one side being more litigious than the other.
Most good contracts contain what is called a "merger clause." This clause provides that the software-development contract contains all terms of the contract between the parties and all representations that each is making. The clause can also provide that any statements that may have been made in the past by either party do not form a part of the contract and that no party is relying upon any such past statement in entering into the contract, unless it is expressed in the contract. Finally, the clause usually provides that no modification to the contract will be effective unless the modification is in writing and signed by both parties.
The value of this clause is obvious. Don't overlook it!
A carefully thought-out contract should lie at the foundation of every independent software-development project. At all times, be comprehensive, specific, and reasonable. If these three rules are followed, the contract will nurture the business relationship like a marriage counselor and, if necessary, will pave the way for a clean divorce without expensive and embarrassing litigation.
Copyright © 1995, Dr. Dobb's Journal