The Bug List: A Checklist of System-crashing Flaws in Software Development and License Contracts

Stephone E. Gillen, Wood Herron & Evans LLP

You've already done a lot of work: creating your requirements definition, identifying and qualifying prospective vendors, evaluating their proposals, selecting a winner and doing your due diligence, negotiating refinements to their proposal. But before you sign the vendor's form agreement, be sure and measure it against this list of common shortcomings that can, if not corrected, leave your expectations unfulfilled.

What are you really getting?
Contemporary software applications are complex, and ever evolving. You want to be sure that the license accurately specifies: which applications you are getting; whether it will run in your existing environment and if not, who pays for required improvements; whether you are getting the software in executable form only or whether you are also getting source code; and what sort of documentation will be provided.

It's undoubtedly correct to say that if you don't get this right, nothing else will matter. But as a practical matter, it is unlikely that you as a business person will be able to provide the details. Much of this will take the form of schedules and exhibits to the agreement (requirements document, RFP and response, published documentation, proposal, etc.). Your task is to ask the right questions of the right people to be certain that both you and the vendor have a common understanding and that the details have been adequately memorialized in the agreement.

And as complex as all of this sounds, understanding the scope of your ownership rights or licenses can be even more bewildering.

Using your software in ways not permitted by your license will almost certainly constitute a material breach of your license agreement (probably voiding your warranties and in some cases triggering an automatic termination of your license). Moreover, such activity may well constitute an infringement of the vendor's copyrights in the software.

What will it really do?
If you've made your purchase decision based on the performance representations made in the vendor's sales literature or made by the vendor's sales agents, you may be in for a disappointment. Make sure that you understand exactly what the license agreement says about what the software will do and that, if the license references user documentation in this regard, that you look to see what that documentation says about functions, features, and performance (including meaningful, measurable response time parameters) and do not simply rely on what you have been told. If you have spent the time and effort to work up an RFP and negotiate a proposal in response, be sure that the contract includes an affirmative obligation on the part of the vendor to deliver a system that complies with that documentation.

What will it really cost?
Is the license offered for a one-time fee or must it be periodically renewed? In either case, the license fee may be only a part of the cost of acquiring a new application. Will some customization be required? Will existing databases have to be converted? Are there separate support and maintenance costs? Are increases subject to some sort of limit or notice requirement? Don't overlook these additional costs as they may outstrip the initial license fees.

What happens if you have a problem?
Try as you might to diligently check out the vendor and the product, and as careful as you might be in reviewing the license agreement, contemporary software applications are complex and error free operation should never be assumed. Assume that, having completed your implementation and having switched over to your new system, you will experience an error, failure, or disruption at the most inopportune moment -- satisfy yourself that, under those circumstances, the remedies laid out in the agreement would be sufficient to allow you to sleep at night and that's just what you will be able to do.

  • Is there a monetary remedy in the event the vendor can't make it work?
  • Do you have to surrender the system in order to get access to the monetary remedy? Are you allowed to retain the system for long enough to make an orderly transition to a substitute?
  • Does the contract include a limitation on the vendor's liability -- to a refund of license fees only (common)? Or do you get back all sums paid? What about reimbursement for data and file conversion costs?
  • Is a copy of the source code in escrow? Will it be current? Will it be useable by you?
  • If failure would be catastrophic, do you need to consider insuring against this risk?