The late movie producer Samuel Goldwyn, a Russian immigrant with a shaky command of English, was famous for his malapropisms. Perhaps his most famous, and wisest, was "An oral agreement isn't worth the paper it's printed on." What was true for the film industry of the 1930s and 1940s is equally true for the software industry of the litigation-happy 1990s. Oral agreements to develop or modify computer software are worthless at best and are usually invitations to disaster.

Writing agreements is difficult, boring, and often unpleasant. But when your client claims that he or she can terminate your services on 24 hours' notice without paying you for the work you've already done, you'll be glad you negotiated and signed a written document containing a far more reasonable termination provision.

View a written development agreement as your lifeline. If properly drafted, it will prevent disputes. If problems develop, it will provide ways to solve them. If the parties end up in court, it will establish their legal duties to each other.

You don't need a lawyer to draft a software development contract. All you need is a brain and a little common sense. All the possible nuances of software contracts cannot be covered in this article, but here is an overview of some of the most important points that should be covered by any software development agreement.

Let's Phase This In
A customer's worst nightmare is to pay a developer to create software and then to hear nothing until months later when the developer delivers a product that is unsatisfactory. The best way to avoid this scenario is to break down the project into discrete parts or stages, often called phases or "milestones." At the end of each stage, the developer should be required to deliver an acceptable product. Assuming this is done, the developer should be paid a specified amount. This makes it easier for both sides to monitor the developer's progress and resolve problems early on in the project -- or even terminate the project.

This type of phased development also has advantages for the developer. Having the customer sign off on each phase of the project is the best way to avoid unwarranted claims of nonperformance or unsatisfactory performance by the customer when the project is concluded. This approach also gives the developer an opportunity to deal with the customer's changing needs and wants. Few software projects ever completely follow the original specifications. The project usually grows as the work is done and the developer and user get ideas for a better and usually more complex project. Developing in phases is a convenient way to meet and discuss changes and how much they will cost. The developer must make sure, however, that the delivery schedule is reasonable and provides some flexibility.

No Blueprint Spells Disaster
Software specifications are the software equivalent of a builder's blueprint. They attempt to define the software to be created and provide a guide for determining if and when the software has been satisfactorily completed. The more complete the specifications, the less likelihood there will be of misunderstandings that can lead to customer dissatisfaction, withholding of payment, and possibly litigation. The specifications are the heart of any software development contract.

There are many ways to write specifications. One way is first to draft a "functional specification" in nontechnical language that the customer can understand. The developer may also prepare a prototype or demonstration program to show the customer how the software will look and function. Later, the developer should prepare a far more detailed and precise detailed technical specification.

Paying the Developer
There are two basic ways to pay a developer for creating custom software: a pay-per-hour (time and materials) agreement, or a fixed-price agreement.

Under a time and materials agreement, the developer is paid for the time spent and actual costs incurred in creating the software. This payment scheme is obviously more favorable to the developer than to the customer. Unlike in a fixed-price contract, the developer is assured of payment even if the project takes longer than originally anticipated.

Under a fixed-price agreement, the developer is paid a fixed sum for the entire project. In theory, this payment scheme favors the customer by giving certainty as to what the project will cost. Moreover, if payments are tied to the progress of the developer's work, it gives the customer substantial leverage to insist on timely and successful completion of the project.

However, as a practical matter, fixed-price agreements usually do not end up favoring the customer as much as one would think. If it turns out that the fixed price originally agreed upon will not provide the developer with fair compensation because the project ends up taking too long, the customer will probably end up agreeing to pay the developer more money. Otherwise, the developer may quit or end up delivering a hastily completed and shoddy product.

Who Owns the Software?
The moment computer code is written, it is protected by copyright. At that same moment, someone becomes the owner of the copyright. Similarly, patent and trade secret ownership rights may come into existence. Many customers of software developers harbor the misapprehension that, since they are paying for the creation of the software by the developer, they will automatically own it. However, this is not the case. Without an agreement transferring ownership from the developer to the customer, the developer will own the software's copyright -- unless the developer is considered the customer's employee or, perhaps, if it was part of a larger work and was prepared under a written work-for-hire agreement.

One of the most important functions of a software development agreement is to establish who will own the intellectual property rights to the software to be created. This is often one of the most hotly contested issues between the developer and customer, and can easily break a deal.

There are many ownership options available, ranging from sole ownership by the customer to ownership by the developer with the customer merely having a license to use the software. And there are many alternatives between these two extremes. Depending on the amount of money the developer is paid, any of these options can be satisfactory.

The Developer's Background Technology
A software developer will normally have various development tools, routines, subroutines and other programs, data, and materials that he or she brings to the job and that might end up in the final product -- for example, code used for window manipulation, displaying menus, data storing, and printing. One term for these items is "background technology."

If the developer transfers ownership of the software to the customer, the customer may end up owning this background technology as well. A developer is usually well advised to avoid this by making sure the development agreement provides that he or she retains all ownership rights in this material. But, in this event, the agreement should give the customer a nonexclusive license to use the background technology that the developer includes in the software delivered to the customer.

Promises to Keep -- Warranty Provisions
We all are somewhat familiar with warranties. Whenever we buy an expensive product -- a car, television, or computer -- the seller normally warrants or promises that the product will do what it is supposed to do for a specific or reasonable time period, and that the seller will fix or replace it if it does not.

Custom software developers are naturally hesitant about giving a warranty for something that is not yet in existence when the warranty is made. However, no customer in its right mind would agree to pay a large sum for custom software without some assurance that the product will work. Warranty provisions are included in most custom software development contracts. However, because this is an area of active bargaining between the developer and customer, they vary widely.

One of the most important warranties typically found in software development contracts is a warranty of software performance. This means the developer promises that the software will work the way the developer said it would and will fix it free of charge if it doesn't. Such warranties typically last from 90 days to one year after the software is delivered. Other important warranties include warranties of title (that the customer will get good title to the software) and of noninfringement (that the software will not infringe on anyone's copyright, trade secret, patent, or other intellectual property rights).

Testing, What Testing? Don't You Trust Me?
Testing is one of the most important phases of the software development process. The purpose of testing is to determine whether the software does what it is supposed to do and is reliable. Particularly where safety is involved -- for example, software implemented in a "911" service or designed to run an elevator -- the software should be tested as thoroughly as possible.

Of course, the developer should test the software before it delivers it to the customer, but the customer should not rely solely on such testing. Before it accepts and pays for the software, the customer should:

  • Test the software itself, assuming it has personnel qualified to do so
  • Have the developer test the software under the customer's supervision on the customer's hardware at its place of business
  • Have the software tested by an independent testing lab

Can't We Resolve This like Gentlepeople?
The single most important provision in any development contract is often the procedure for resolving disputes. If a problem develops and the other side turns out to make unreasonable demands, resorting to court litigation can be ruinously expensive.

Arbitration and mediation are two means of settling disputes without going to court. In arbitration, a person or panel decides the merits of the issues and renders a decision, which may or not be binding, depending on the arbitration agreement. There are a number of professional arbitrators' organizations -- notably the American Arbitration Association, which has offices in most major cities.

Mediation is less formal and even cheaper than arbitration, and by its nature is never binding. Typically, the mediator either sits the parties down together and tries to provide an objective view of their dispute, or shuttles between the two sides as a cool conduit of what may be red-hot opinions. Where the real problem is a personality conflict or simple lack of communication, a good mediator can keep a minor controversy from shattering the relationship between software developer and customer. Where the argument is more serious, a mediator may be able to lead to a mutually satisfactory resolution that will obviate time-consuming and expensive litigation.

No one can be forced into arbitration or mediation; one must agree to it, either in the contract or later when a dispute arises. Commercial contracts today frequently include a binding arbitration provision. However, this is not a matter to be agreed to lightly. By agreeing to binding arbitration, you're basically giving up your right to go to court to enforce the contract.

Copyright © 2000 Inc.