One of the functions of this blog is to address issues that arise with some frequency in practice, or those that arise from time to time with frustrating results. Enter the acquisition of major software licenses or IT systems that play a large role in the operation of a business. The majority of negotiations concerning software licenses or information technology related agreements (“Software Agreements” for this note) start with the vendor’s pre-printed terms and conditions or the standard “form” agreement.
Both sides are afraid to negotiate. Customers (or licensees) wrongly think that they must sign the standard contract presented or do not want to spend the money on an attorney if such documents are non-negotiable. Or, they do not fully understand all of the aspects of the contract and assume everything must be covered. Vendors (or licensors) are sometimes wary when customers propose changes but do not want to lose the business. It is important for both sides to understand that many vendors fully expect that a customer will negotiate from that initial draft. Negotiation is healthy and encouraged. Customers that fail to negotiate may end up in a lopsided agreement and face a significant disruption in business if things take a wrong turn. Vendors can also view some negotiation as a positive. After all, this is the beginning of a potentially long and mutually beneficial relationship. Further, customers that negotiate tend to understand the transaction better and have more realistic expectations. A reasonable goal is to achieve a balanced agreement that favors neither party.
Some of the key areas of a Software Agreement where negotiation may be appropriate include warranties, indemnities, support and maintenance and source code escrow. Software Agreements should also include provisions addressing many things such as the scope of the license, term, payment and implementation. Discussion and negotiation regarding those terms is somewhat more inherent, however, and likely to be a part of the deal regardless of the form or standard terms being used. The concepts below feel more like “fine print” that customers might tend to gloss over.
Warranties require that a vendor make promises regarding quality of performance, speed of response time, limited length of downtime, and other things. The performance warranty involves the vendor agreeing that the software will perform in accordance with the specifications and documentation as contemplated in the agreement, and will contain a general provision that the software is free from material or frequent errors. Warranties should continue during the term of the Software Agreement at a minimum, and for as long as the customer is paying for support and maintenance. Customers may also require a disabling code warranty such that the software does not contain elements causing it to stop running upon the occurrence of certain events. A no virus warranty that provides that the software is not infected with a virus can also be included.
Indemnification means that the vendor indemnifies (compensates or pays back) the customer for damages incurred because the software infringes the intellectual property rights of a third party. They can also cover bodily injury or death, or property damage caused by the negligent acts or omissions of the indemnifying party.
Support and maintenance is a key issue. Generally vendors should agree to correct programs and bugs, make minor improvements to programs, and provide enhancements or new features generally available to other customers. Ideally, the customer should require a guaranteed time by which problems are resolved, and customers might want to cap future increases in support fees if possible. In some instances support service and maintenance may be set forth in a separate agreement called a service-level agreement (SLA) which addresses scope and responsibility issues.
Source code escrow can be a touchy subject, but it is of high importance when a customer is working with a smaller vendor. Vendors rarely provide their licensees with access to a program’s source code (the computer instructions in written form, readable by a human, as prepared by a programmer) because it contains the key information required to develop, use, and support the software. Disclosing source materials creates a risk that a competitor will gain access to the vendor’s intellectual property or that a customer will subcontract or perform its own maintenance and support services instead of paying the vendor. As a result, most vendors provide access only to the machine-readable object code (what the end user ends up seeing after the source code has been run through a compiler). Source code escrow describes a situation in which the customer requires the underlying source code relating to the software being licensed is deposited on a regular basis with an independent escrow agent ( in a three party system, two party systems where the vendor sets up an escrow for all customers is also a possibility). Doing so is important, because if the vendor goes out of business, goes bankrupt, or if there is a material breach in the Software Agreement, the customer can take over the management of the software and avoid a disruption in business. Both customers and vendors should be sure to consult knowledgeable counsel when dealing with escrow source code matters.
In addition to being familiar with the terms and provisions just discussed, customers can level the playing field in the negotiation process by getting their own proposal to the vendor early in the process and setting goals to measure performance. Customers can use a request for proposal or request for quotation form that includes the provisions that they insist be part of the deal at the outset. They can also identify business objectives at the beginning of the relationship – being as specific as possible – and work with the vendor to enumerate ways in which the product can work to achieve those objectives. This will create a set of performance standards for both parties. Finally, it is important to plan the entire project, and detail any proposed work plan, before the contract is signed.
Vendors should have a standard base form agreement and a set of standard terms and conditions for use as a starting point for negotiations. More importantly, vendors should understand the terms and conditions that they are proposing. A solid working knowledge of what they are proposing is critical for negotiations so that a vendor can reasonably assess any proposed changes and the attendant risks and advantages corresponding to the proposed change. Further, vendors should work from that original base agreement for every transaction, rather than a variation that may or may not apply to a particular customer.
In conclusion, neither side should be shy about negotiating when it comes to software licensing or IT agreements. With a good understanding of the key terms included in such agreements parties can reach a balanced fair agreement and set the stage for future success. Consulting with legal counsel familiar with technology issues will help facilitate the transaction and prove valuable in the long run.