A written software development agreement is key to getting the product you want (if you are the client), getting paid (if you are the developer), preventing disputes, and providing ways to solve problems if they develop. And, if the parties end up in court, it establishes their respective legal duties.
You don't need a lawyer to draft a software development contract -- you can do it yourself. This article doesn't cover all possible nuances of software contracts, but it does provide an overview of some of the most important points that should be covered by any software development agreement.
In the contract, break down the project into discrete parts or stages, often called phases or "milestones." The contract should require the developer to deliver an acceptable product at the end of each stage in order to get 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.
Advantage for software client. Getting the work in phases avoids the danger of getting an unsatisfactory product at the very end.
Advantage for the developer. Having the client sign off on each phase of the project is the best way to avoid unwarranted claims of nonperformance or unsatisfactory performance by the client when the project is concluded. This approach also gives the developer an opportunity to deal with the client's changing needs and wants.
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 misunderstandings which can lead to client 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 to draft a "functional specification" in nontechnical language that the client can understand. The developer may also prepare a prototype or demonstration program to show the client how the software will look and function. Later, the developer should prepare a far more detailed and precise technical specification.
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.
Time and materials agreement. Under a time and materials agreement, the client pays the developer for the time spent and actual costs incurred in creating the software. This payment scheme is often favored by developers since the developer is assured of payment even if the project takes longer than originally anticipated.
Fixed-price agreement. Under a fixed-price agreement, the client pays the developer a fixed sum for the entire project. In theory, this payment scheme favors the client 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 client substantial leverage to insist on timely and successful completion of the project.
However, as a practical matter, clients often agree to pay developers more money if the project takes more time than anticipated. Otherwise, the developer may quit or end up delivering a hastily completed and shoddy product.
Transfer of Copyright Ownership
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 client and can easily become a deal-breaker.
Developers own the copyright to software unless the developer is the client's employee or the software is part of a larger work made for hire under a written agreement. In order to own the copyright, the client must have an agreement transferring ownership from the developer to the client.
There are many ownership options available, ranging from sole ownership by the client to ownership by the developer with the client's 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.
For more on who owns a copyright, see Copyright Ownership and Rights.
Ownership of Background Technology
Software developers will normally have various development tools, routines, subroutines and other programs, data, and materials that they bring 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 client, the client may end up owning this background technology as well. Developers should avoid this by making sure the development agreement provides that the developer retains all ownership rights in this material. But, in this event, the agreement should give the client a nonexclusive license to use the background technology that the developer includes in the software.
Generally, a warranty is a promise from the seller 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. Warranty provisions are included in most custom software development contracts. However, since this is an area of active bargaining between the developer and client, these provisions vary widely.
Warranty of software performance. Warranties of software performance are typical in many contracts. In this warranty, 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 warranties. Others include warranties of:
- title -- that the client will get good title to the software, and
- noninfringement -- that the software will not infringe on anyone's copyright, trade secret, patent, or other intellectual property rights.
The single most important provision in any development contract is the procedure for resolving disputes. It is often advantageous to settle disputes without going to court -- which can be extremeley expensive. You can do this through arbitration or mediation.
Arbitration. In arbitration, a person or panel decides the merits of the issues and renders a decision, which may or may not be binding, depending on the arbitration agreement. Many commercial contracts today include a binding arbitration provision. Be aware that, by agreeing to binding arbitration, you're basically giving up your right to go to court to enforce the contract.
Mediation. Mediation is less formal and 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.
For more on mediation, see the Mediation, Arbitration & Collaborative Law area of Nolo's website.
For detailed information on the laws covering software development, get Legal Guide to Web & Software Development, by Stephen Fishman (Nolo).