Sometimes looks can be deceiving, and when it comes to software licenses, this proverbial phrase certainly applies. In general, there is more to a software license than clicking the “I Accept” button or signing the vendor’s form of license agreement. Though the vendor promises that a certain program is perfect for your bank’s needs, these licenses usually do not offer favorable options.
For example, some licenses are specific to a named employee. The boilerplate language near the end of a contract is usually skimmed and rarely read, but some of those terms may become crucial in the future. Any time your bank licenses a software solution, you will want to negotiate very different terms from the vendor’s form of contract.
In sophisticated high-dollar software transactions, software is often custom-built or at least significantly customized to the bank’s needs. This requires a lengthy contract describing the functionality of the software, exactly what is being licensed and what isor will be owned by each party. The description of ownership is critical, because if a bank hires a software developer to design a program, the bank might believe it should own the final software product, but the software developer might (and usually does) disagree. Therefore, the issue of whether the software product is a “work made for hire” is critical to the party who wishes to own the intellectual property rights to the software code.
Even in smaller transactions, which may involve the use of off-the-shelf software or access to vendorhosted web-based applications (called ASP or SaaS solutions), a separately negotiated license agreement has distinct advantages over the vendor’s standard form. First, the bank can negotiate better license rights to enable the entire bank enterprise to benefit from the solution. Second, the bank can obtain specific rights needed in order to fully utilize, maintain and support the solution. Third, the bank can give itself the rights and options it may need in the future. The list goes on. The negotiated license agreement will end up being much more than a document that only protects the vendor.
All license agreements include certain basic components. Below are some common issues that banks should consider addressing.
Banks want perpetual, global, enterprise-wide, transferable licenses for an unlimited number of concurrent users, teller stations and branches. Vendors prefer limited time and geography, non-transferable, terminable licenses that are specific to a user, computer or branch.
Payment of Fees
Vendors want all fees paid up front. Banks may prefer partial payments, spread out over the signing of the license, training, custom building, installation and acceptance testing of the solution.
How will the software be loaded on to the bank’s hardware? How will it be rolled out to branches? Can the bank kick the tires for a few months to be sure the solution actually works?
Banks need to be sure they are contracting with the party who owns or has the licensing rights to the solution, that it will operate under certain conditions, and that it will have the functionality the bank wants. For solutions hosted on the vendor’s servers, the vendor needs to assure the bank that GLB-protected data will be secure.
If the bank and its customers are sued because of a defect in the software, the bank will want to be indemnified by the vendor. Of course, indemnification will not be much help if there is a low cap on the vendor’s liability and is only as strong as the financial strength of the vendor.
Maintenance and Support
A bank’s ability to repair a defective or buggy software solution will be limited. A maintenance agreement with escalation procedures will help keep the solution up and running. Also, the bank might want the vendor to continually improve the solution with updates and upgrades. Negotiating the license agreement can improve the maintenance levels while keeping upgrade costs down.
Most vendor agreements prohibit the solution being assigned or transferred, including to an acquiring company or successor by merger. The negotiated agreement can remove this acquisition obstacle, and permit the successor company to use the solution or, at its option, to terminate the contract.
Other Issues for Banks
License agreements can speak to many other issues that are important to a bank, including:
- Disaster recovery procedures. Particularly with applications hosted by the vendor, disaster recovery and backup measures will be critical should problems arise.
- In case the vendor can no longer maintain or support the solution, it is a good idea to have the human-readable programming code, or “source code,” of the software in escrow so the bank can access it to maintain the software.
- If the bank already uses other key software solutions, it may be necessary for the new solution to integrate with existing programs. This integration may require early testing, customization and acceptance.
Similarly, the vendor will seek to have specific provisions in the license agreement:
- The vendor, and perhaps even the bank, may wish to impose strict confidentiality guidelines regarding the costs and other matters associated with the solution.
- The vendor will seek to have its liability for damages limited to as small an amount as possible. This will conflict with the bank’s need for broad indemnification rights.
- A vendor may want laws and jurisdictions favorable to software developers to apply in the enforcement of the agreement, such as California law and courts.
Smart banks understand that license agreements need more careful attention than simply accepting the vendor’s standard contract. Failing to consider and negotiate the key terms may leave your bank vulnerable to costly up-front fees, a solution that does not meet your needs or even liability exposure. Protect your interests by taking the time to negotiate all license agreements, even those involving off-the shelf or hosted solutions.