--- To enhance the value and performance of procurement and SCM practitioners and their organizations worldwide ---



Risk Assessment in Software Licensing

Author(s):

Sharon E. Meng
Sharon E. Meng, Principal Consultant, INH Consulting Services, Berkeley, IL 60163, 708/547-5755

81st Annual International Conference Proceedings - 1996 - Chicago, IL

Introduction. There are many risks associated with any type of acquisition made by a company. These risks represent the difference between what was planned and what actually happened. We have many of the same risks when we license software or, for that matter, hire a computer consultant to provide us software-related services.

As might be expected, all of our good practices still apply to these purchases, such as, competitive bidding, good specifications, strategic partnering, etc. Some of the risks associated with software acquisitions have to do with bad practices that are allowed to occur - wild-catting (signing contracts without authorization), single sourcing, improper evaluations and testing, etc. These are not unique to software acquisition but do SEEM to be more prevalent than in other acquisitions. It seems that people who normally would follow good purchasing practices for a new desk or computer seem compulsed to go it on their own to buy a new software package. Add to that the acquisitions made by the Information Technology folks who think they are the experts and the Purchasing Department (and Law, for that matter) are simply creating needless bureaucracy.

However, there are some unique characteristics to software that differentiates its acquisition from the standard purchasing process.

Software Acquisition Differences. Two related differences in software acquisition are that the software product is a copyrighted work rather than a work of manufacture and, therefore, the acquisition is not a sale but a license to a copy of the actual product for some period of time. This leads to numerous complications including not being able to use a simple purchase order, but having to enter into formal, usually quite lengthy contracts. There will be rights and obligations for both parties for the length of the license, which is frequently perpetual, but even that may be a shorter term and may be subject to obligations upon termination. These rights and obligations will cover copying rights, who can use the product, new releases and fixes to the product to maintain currency, etc. As an example of one of the problems created by not owning the product, but licensing it is that, over time, uses will evolve that were never originally contemplated by either party in the original license - outsourcing, upgrade, use by agents, business partners, etc. As a result, the buyer will have a relationship with the seller in which continued use of the product which is necessary in the buyer's business may require the buyer to pay an additional fee to the seller.

Another difference, but related to the first issue, is that the software license almost always excludes the Uniform Commercial Code. As it stands, the UCC does not adequately cover standard treatment for software, particularly in the areas of merchantability and fitness for a particular purpose. The UCC is undergoing legislative modifications as we speak, but even after the new UCC is in place, it will still only be primarily of importance for consumer transactions in the area of off-the-shelf (commodity) software. Most software acquisitions will still be undertaken with a formal written contract.

Software, by its nature is hard to test and verify it's completeness. The larger and more expensive the package, the more this is true. With a $100,000 car, you will immediately notice major parts missing, like steering wheels, tires, seats. With computer software, significant missing parts may be difficult to detect without substantial testing time. In addition, all of the parts may be there, but they don't work exactly right or don't work the way the user thought they were supposed to work. Mathematical calculations are particularly prone to errors of this kind. We may, therefore, ask for an acceptance testing period, but even during testing, someone may have to make a judgment about whether a function is "substantially in conformance" with the documentation.

Since the software is a copyrighted product, it is also subject to claims by third parties for copyright infringement. There are several issues involved in this topic. First, as buyers we want protection from the cost of trying such claims. This is called Indemnity and is typically the seller's responsibility. We also want to make sure that we get protection in case the seller loses the right to license the software.

We even have a difference in that what software is, what documentation should be, and how different uses are made of the product are hard to understand. Some examples are:

  • Very few people expected that the courts would find that the copy of the software on your disk is different from the copy of the software in the computer's memory (RAM) and that the RAM copy may be protected under the copying restrictions of the copyright law.
  • Very few people outside of the computer profession can understand all the different jargon used by computer professionals (like "RAM")- even other computer professionals have trouble at times. One of the classics is the word "bug" which everyone recognizes as a "problem" but is it a big "problem", a little "problem" an omission, a defect, etc.

And finally, software companies go out of business either by bankruptcy or acquisition and trade personnel so often that it's hard to keep track of who is who. Doing a vendor financial viability is almost impossible because of the short period of time that most software companies have been in business.

Reducing and Avoiding Risks. There is no way to completely eliminate the risk of acquiring software and still get and use software in your company. However, there are some relatively simple methods that will reduce your company's exposure.

A first step is to Educate Yourself in the general areas of software licensing - take a course in intellectual property law, take a basic computer course at a local college, take a course in negotiation. You don't have to be a computer expert, but just as in labor contract negotiation, you should know about labor law and how unions evolved and work, you should know something about your subject area - in this case, computers and computer programming.

The next recommendation is probably a little more difficult and time consuming
Do Your Organizational Homework. Develop your own model agreements and USE them. This is a multi-step process that is outlined as follows:
Develop a list of agreements you use most often. We recommend that you develop Model Agreements to cover at least these licensing areas:

  • Software License for Mainframe products
  • Software License for PC, distributed or LAN products
  • Professional Services
  • Product Evaluation
  • Confidentiality

Develop other Model Agreements according to your organizational uses. If you by a lot of turnkey systems, you will need to develop a Turnkey Model Agreement.

  • Get a copy of "Buyer's Side" Model Agreements in the areas you choose. These Models will serve as a starting point.
  • Develop a list of issues in licensing including things like treatments for Outsourcing, Agents, etc.
  • Interview appropriate company staff (Law, Purchasing, Information Technology, Data Center Management, Significant Clients) for the company's view of the importance of each issue. Does your company like to litigate or arbitrate? Is price the most important issue? How does the company handle product maintenance and new releases?
  • The outcome of these interviews will establish a priority for these issues as your company's acquisition targets and their relative importance.
  • Based on the priority of the various targets, modify the Buyer's Side Agreement to produce your company's Model Agreement
  • Develop strategies for obtaining your targets by reviewing the justifications for the various targets and practice negotiating them with your peers.

Train your clients. Teach them to never accept the vendor's agreement. Make sure they include your company's Model Agreement with all RFP's for software or services. Help them learn to write good specifications. Explain company policy where appropriate.

Keep up to date on current issues in copyright law and in computer software. The more you know about.

Use an Acquisition Process. We recommend something along the following lines, but the most important point is that there IS an acquisition process for your organization.

An Acquisition Process. One of the biggest risks in software acquisition is bypassing the negotiation process - you would be surprised the number of LARGE companies who simply accept a vendor's agreement with little or no review or negotiation. Its not that EVERY acquisition needs to have months and months of negotiation, but at least a knowledgeable review and a list of problems. Your company should have standards for when negotiation is required - something like exceeds X $ or Y duration of time or Z number of users of the product.

Your organization may develop its own acquisition process, but it should, at a minimum, have the following steps:

Use an RFP. Your organization should have guidelines for the use of RFP's and guidelines for their preparation.

Use your Model Agreements that you developed above.
Negotiate tenaciously, but DO remember - its a business deal! Do not become a "single issue" negotiator - like cost is most important. The lowest cost is not always the best deal, especially in software and services. Since you've done your organizational homework, you know where to give and what's important. Use standard negotiating techniques and involve your client. There will also be times when you need to take the agreement to a higher authority - law, CIO, etc. - either for increasing negotiating power or to address a severe deviation from targets.

Document where the actual contract terms and conditions of the contracts differ from company targets. Assess levels of risk for missed targets by importance to the organization and the divergence from the target.

Estimate total costs of ownership, including cost of compliance to contractual obligations.

Get acknowledgment and authorization for both risks and costs from the appropriate authorizer, including the Law Department, when necessary.

Enter the contract on some sort of tracking system so that others in the organization will not waste time renegotiating an existing contract. This tracking system can also summarize and index the important terms of the contract for compliance measures and in cases of organizational changes.

File all documents, including risk assessments and a red-line copy of the contract for future reference.

Conclusion.
Although no acquisition or acquisition process will totally eliminate all risks, the most important risks can be greatly reduced by developing and using model agreements for you corporation, negotiating all important acquisitions and following up with proper authorizations and analyses of costs and risks.


Back to Top