Beware vendor's line in software licensing

09 Apr Beware vendor's line in software licensing

Many negotiations for software licenses or system acquisition agreements begin with the vendor’s “standard” pre-printed terms and conditions. This is nearly always a mistake for the company acquiring a major IT system or software license (the “purchaser” or “licensee”). Standard vendor agreements generally lack several terms that licensees should have in their contracts, and the licensee’s ability to negotiate such terms is substantially reduced by using the vendor’s agreement as a starting point.
As one would expect, the standard agreement developed by a vendor that offers multiple similar licenses each year is designed primarily to protect that vendor. Issues that both parties want addressed will likely be skewed to favor the drafter. Terms that matter only to the purchaser are likely to be watered down or missing entirely, since they will not benefit or appear important to the vendor. This is neither evil nor surprising: it is good business from the vendor’s perspective. But it does not result in good agreements for the purchaser.
Some vendors will go further, routinely offering a set of very one sided “standard” terms, knowing that any knowledgeable purchaser or lawyer will reject them out of hand, and then offer up a less onerous “standard” agreement as a second position. This tactic is designed to persuade the purchaser’s business people that the vendor is willing to make concessions when they are reasonable, and insists on only those points that are truly important, reasonable, and non-negotiable. That is, this is designed to divide and conquer the opposing negotiator and lawyer.
Each license or acquisition situation is different and must be analyzed to determine what terms and conditions the purchaser needs. But here are some best practices to consider when you are licensing important software or acquiring significant IT systems for your enterprise.
Put your terms out front
Utilize a Request for Proposal (RFP) or Request for Quotation that attaches the organization’s desired contract terms. The RFP should indicate that although the proposed terms are not set in stone, nonetheless, any request for variance will be considered a negative in the vendor selection process. Vendors should be asked to accept the proposed terms explicitly or to identify any unacceptable terms, provide specific alternative language, and indicate the cost differential for each set of terms.
This approach increases the likelihood that the purchaser’s desired terms will become part of the agreement at the quoted price. A vendor still competing for selection will be less likely to object to any term that is not truly important. In contrast, if the contract terms are negotiated after the vendor selection, the vendor will commonly respond to the purchaser’s proposed terms by saying that the quotation was not prepared with such burdens in mind and they will require a price increase. At this point, the purchaser must either accept this price increase, abandon valuable terms, or reverse its vendor selection and start over.
State explicit business objectives
Include a statement of your business objectives for the acquisition in the agreement. This creates a touchstone for negotiating other terms and for implementing and interpreting the agreement later on.
Vendors commonly resist such language, arguing that the objectives are too broad or vague and that accomplishing them is beyond their control. The purchaser should demand that the vendor identify stated objectives that the software (or system) will not help the purchaser to achieve. If the vendor can identify one, and if the purchaser agrees, the objectives can be modified. Otherwise, the purchaser will have identified a serious disconnect between its expectations and the vendor’s. Doing this up front, rather than after the vendor is selected or, worse, after the software or system is installed, will save lots of time, money, and frustration.
Do the work plan before contract execution
Most licensors will provide a licensee with a generic workplan prior to execution of the agreement, and will promise to complete the workplan as an early deliverable once the agreement goes into effect.
Neither licensors nor licensees like being forced to complete the workplan before the contract is executed. Vendors do not want to commit the resources necessary to develop a detailed plan for a contract they may not win or for which they have, as yet, received no payment. Purchasers do not want to take people away from active tasks to focus on less urgent matters. But in almost every case, it is better for the purchaser to complete the workplan before the contract is executed.
Once the agreement is signed, the customer will lose negotiating leverage necessary to compel the licensor to meet the purchaser’s schedule and, as in the case of stating business objectives discussed above, going through the process of drafting and revising a workplan may be the only way to assure that what the purchaser is expecting to receive is what the vendor is expecting to furnish at the contract price.
If it is not possible to complete the workplan prior to execution of the agreement, try at least to agree upon the installation commencement date, installation completion date, and dates of key deliverables.
Also, consider adding language requiring the parties to finalize the workplan within a specified number of days. If the parties fail to complete an acceptable workplan within that time, the purchaser should have the right, at its sole option, to extend the workplan deliverable date or to terminate the agreement without further obligation.
Escrow source code and related materials
A licensee of significant software should get rights to see and use the source code and related source materials if necessary to obtain the bargained-for value of the software. Licensors seldom provide their licensees with access to a program’s source code 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 licensor’s intellectual property or that a licensee will subcontract or perform its own maintenance and support services instead of paying the vendor. As a result, most licensors provide access only to the machine readable Object Code.
But there are times that a licensee legitimately needs access to source materials. If the licensor files for bankruptcy protection or ceases to support the software, the customer should be able to access the source code and related materials to provide its own support for the software or to enable a transition to a permanent replacement program. This is accomplished by establishing a source code escrow.
There are two types of source code escrows: two party and three party. In a two-party arrangement, the licensor establishes a single escrow for the benefit of all of its licensees. Additional licensees become beneficiaries of the escrow by signing a simple form. Three-party agreements are created specifically for a given transaction and are signed by the licensee, licensor, and the escrow agent.
A three-party agreement requiring an independent escrow agent to divulge the software directly to the licensee may be easier to enforce in the event of a bankruptcy or business termination than an agreement that requires action by a bankrupt licensor. An escrow agreement protective of licensee rights should provide that upon the occurrence of a trigger event, the license is expanded to permit the licensee to provide its own support and to modify the source code as needed for its own use. A provision permitting each existing licensee to cooperate with other licensees to further develop, use, and support the software may also have cost saving and litigation avoidance benefits.
Standard escrow agreements may be sufficient for most purposes, provided they include a broad list of “trigger events” that cause release of the software from escrow. But they should be carefully reviewed by knowledgeable IT personnel and legal counsel, not blithely accepted as “standard boilerplate.”Future columns will discuss additional IT contracting best practices and important terms and conditions.
Other columns by Mark Foley
• A cost-effective way to protect global HR data
• Mark Foley: Developing global data privacy policies for HR data (part 1)
• Mark Foley: Expert testimony may be needed for e-discovery keyword searches
• Mark Foley: Internet law: 12 questions for board oversight of data privacy and security