Negotiating the Landmine of Software Development Agreements
With any software development project, there is or should be a written agreement between the development firm and the customer. If the contract is well drafted, and if the parties are ethical (i.e., if they take their contractual obligations seriously), the contract will lay the groundwork for their future relationship. Some development agreements read more like a vendor-customer agreement; others are more collaborative. These relational nuances are based on the parties’ values and are ideally reflected in the terms of the contract.
In any software development agreement, there are a number of legal issues that routinely arise. The purpose of this article is to highlight the major issues that usually surface in connection with software development agreements and to suggest some possible ways to address them. Although there is no “one size fits all” agreement, there are some commonalities that transcend all software development agreements.
1. Ownership vs. license. The first issue that needs to be addressed in any software development agreement is whether the customer will own the code or whether the software firm will retain ownership of the code and license that code to the customer. Under applicable copyright and patent laws, the software firm owns the code in the absence of an agreement otherwise. Unless code is being specifically developed for a particular customer, it is rare that a software firm would give up its ownership rights. Even in situations where code is being written for a specific customer, there are occasions on which the customer will obtain ownership of that code and situations in which the customer will get an exclusive license but not necessarily ownership. The resolution of this issue usually depends on the relative bargaining strength of the parties. Obviously, the customer would rather have ownership of the code, and the software firm would rather license the code base to the customer. A license allows the owner of the licensed property (in this case, software) to terminate the license at any time if the licensee (customer) exceeds the scope of the license.
For example, let’s say that the customer has an exclusive license to use the code for an unlimited period of time, but only for the customer’s internal business purposes. If the customer ever starts distributing the code to third parties, and if the contract is drafted appropriately, the license would be revoked.
2. Exclusive vs. nonexclusive license. Another issue that arises in the context of licensing is whether the license will be exclusive or nonexclusive. If the license is exclusive, then it is important to define the scope of the exclusivity. In other words, will the customer only be able to use the software for a particular purpose or in a particular geographic region or for a particular period of time? Often when dealing with an exclusive license situation, there are corresponding restrictions on the licensor (or owner) of the code. For example, the contract may contain a provision prohibiting the licensor from competing with the customer in the customer’s market or from selling or licensing the code to a competitor of the customer. These issues are all negotiable, and the fewer restrictions on the development firm, the greater value that intellectual property represents for the firm. Conversely, the more restrictions the customer can place on the development firm’s use of the same or similar products, the more valuable the license is to the customer.
3. Compensation. Compensation is a necessary component of any contract. Compensation for the development of software can be structured any number of ways. With shrink-wrap software, the user is charged a user fee that may be recurring or a single payment. It may also be based on the number of locations at which the software will be installed and/or the number of users. Custom software development, on the other hand, offers opportunities for greater flexibility with respect to compensation. It is uncommon for the development firm to be paid the entirety of the agreed upon price up front. It is more common for payment to be tied to specific milestones
or deliverables and for there to be additional payments upon completion of the project. Compensation is often related to whether the development firm will be providing any ongoing maintenance or support services, upgrades, training or the like. Generally speaking, the longer the warranty period, the more compensation the software firm will demand. Obviously, the customer wants to obtain as much value as it can for the least amount of money.
4. Written specifications and change order process. It is critical in any software development project that the parties develop a set of written specifications against which the performance of the software can be judged. In addition, software firms need to protect themselves against customers who demand greater or different functionality than initially agreed upon, and customers need to allow themselves some flexibility to deviate from the initial specifications. That is accomplished by including a change order process in the contract. The software firm is obligated to deliver an application that will perform according to the written specifications. If the customer desires functionality that is not included in the specifications, then the customer must submit a written change request to the development firm. Typically, the development firm will assess the change request and inform the customer as to the effect that implementation of the request will have on both timing and cost. The customer can then decide whether to approve implementation of the request or to live without it. Without a written change request process to which both parties adhere, software firms can get buried in scope creep, and customers can end up with an application that does not suit their needs.
5. Access to source code. In an exclusive license situation, an issue that frequently arises is whether the customer will have access to the source code. Even with an exclusive license, the software firm may be reluctant to give up its code. This issue can be resolved in a number of different ways, often depending upon the relative bargaining strength of the parties. In some situations, the source code will be delivered to the customer as it is developed, but in others, the source code will be placed in escrow and released only upon the occurrence of certain events. These events may include the insolvency or cessation of business on the part of the software firm, material breach of the agreement by the software firm, or the death, resignation or unavailability of certain key players.
In situations where the software firm has fairly strong leverage (which is not typical), the customer never gets the source code. Instead, the customer gets the executable version (object code) of the software only. The problem that creates for the customer is that unless the development firm is of Microsoft’s stature, the customer has no assurances that the software firm will be around indefinitely to support the software, and the customer will not have access to the source code to maintain or extend the application itself, should the customer elect to do that.
6. Warranties. Particularly in the case of custom development, the customer will want some assurance that the application that is being developed for it does not infringe any third party intellectual property rights (namely, patent, copyright and trademark). It is customary for software development agreements to include a warranty against infringement, whereby the software firm represents that the application will not infringe a third party’s intellectual property rights and agrees to indemnify the customer in the event the customer is sued for infringement. Another type of warranty is the performance warranty, during which the development firm warrants that the software will perform to a certain standard for a certain period of time after the project is completed. This type of warranty typically only covers “material defects,” which are usually defined as those types of defects that render the software inoperable. The project plan should include testing and acceptance periods for each deliverable, and the warranty period is not intended to give the customer a second bite at the apple. Instead, it is intended to protect against catastrophic failures only.