Custom Software

28 April 2006

In a perfect world you would be able to walk into a store or pick up the phone and get the perfect software. However, as you may have noticed, we don't live in a perfect world. Often, the best (or only) option is to buy software custom-made to fit needs of your business.

Having software custom-made or modified for your company requires that you negotiate an agreement that touches on a whole slew of issues. Dealing with custom software is not like buying off-the-shelf software at the computer store. There, you're typically dealing with a non-negotiable license agreement that appears during the installation process. Agree to it and you get to finish the installation. Say "no" and you get a refund.

Things get much more complicated in the custom software world. Here, the typical corporate buyer may have more negotiating position, but still be at a tremendous disadvantage due to lack of experience in negotiating these types of agreements. With custom software, you should never consider accepting the vendor's "standard form." They're inevitably one-sided in favor of your vendor. Trust me when I say this because I write those one-sided agreements.

My goal this week and next is to give you a feel for some of the issues that you should consider.

It's Usually a License

Even when you "buy" custom software, the most typical transaction has the "buyer" getting a license to use the software rather than the customer buying all of the rights to the product. True purchases of software raise their own unique issues. This column will deal with the more typical license situation.

A license is simply a grant of a right to do something that you would not have the right to do without that license. With a software license, the single most important issue is defining the precise scope of the license. Your license must clearly state whether it's exclusive or non-exclusive, who in your organization can use it, and whether there are any limits on the location of its use.

The key here is that you must accurately project your needs for the software. You must ensure that your license permits your anticipated uses and you should have a structure in place if your needs grow. A mistake here can be costly because you will have less negotiating power down the road.

If you're going to license 150 users and six locations today but think its possible you might need more licenses tomorrow, be sure to deal with the pricing of additional users and locations now. Once you're married to your software, you don't have much choice if your software developer's pricing proposals are exorbitant for more users or locations in the future.

You must also carefully define permitted users. If subsidiaries, independent contractors or others will need to work with the software, then get that into the license.

A Tip from the Trenches

Here is one tip from the trenches. I've seen this next part omitted many times and it creates problems.

Always be sure to anticipate the process that you'll inevitably go through when you move onto a different software product way down the road. What I'm suggesting is that your custom software development agreement and license should deal with its end process. For example, you want to be sure that nothing restricts your ability to convert data to a new format.

Conceivably, transitioning to a new product may mean that you'll need to give your developer's present or future competitor access to your data and software to assist you in a transition. This may violate user, trade secret and other restrictions in your license. This is a touchy and difficult area and one where many licenses are silent. No single perfect solution exists, but still you must address this thorny issue. Nothing is forever.

Modifications

Today's innovative software is next year's antique. You must never invest in software development without thoroughly exploring updates, modifications and fixes. This is not next year's issue. This is an important part of your initial contract.

Will your developer be marketing this or similar software to others? Will the developer have an ongoing program for updates and improvements?

If you're dealing with true custom-created software, you'll probably have to fund all future development. If that's the case, you should have some pricing parameters in your agreement. Leave this until later and the price will be higher. After all, you may have no alternative than to let this developer do the work.

If you're paying for custom-modifications to preexisting software, the developer may have enough of a market for updates that it will fund the further development of the software. Then, you need to obligate the developer to license the update to you. The price might be based on a most-favored customer price or some other arrangement.

A problem your development and license agreement must also anticipate is how to deal with custom modifications to an earlier version of the software. The problem is that your modifications may not just drop into the new version. In fact, they may not work there at all. If that happens, you may have to redevelop your modifications.

This isn't so bad if you, at least, have a choice to stay with the earlier version of the software. The scenario that you must anticipate is when the developer's support obligation is contingent on you always using the latest version of the software. I've seen an agreement where this problem wasn't anticipated. The client came to me looking for a solution to the endless cycle of updates to an off-the-shelf product that they paid the developer to modify for them. The updates were admittedly useful, but the client continued to have to pay for the custom work of adding its custom modifications to the new versions. The compromise solution was for the vendor to agree to support the old version at a higher than normal price. My client lost the benefit of future updates, but no longer had to pay exorbitant fees for recurring custom software development.

Describing the Development Project

From the lawyer's perspective, probably the single most difficult part of custom software development is defining what the software should do. It's much like a construction contract for a building that hasn't even been designed yet. You don't know what its going to look like and yet you're contracting for its creation.

What features will the software have? How will it accomplish its required tasks? What will its interface look like? These are just some of the many questions that need to be addressed.

One effective way to address these issues is to send perspective vendors a Request for Proposal (RFP). This gives you a chance to pick the brains of several vendors. Then, you can also take their response to the RFP and turn it into contract language. The vendors may not like that, but it's their own words.

You can anticipate a tug-of-war between the customer who wants to phrase the contract in terms of what it needs done and the vendor who wants the contract to refer to published specifications. Either way, detail is the key for the customer. You must do everything possible to insure that the vendor knows what you need and can deliver it.

One technique that I use is that I'll ask my client to give me a list of the absolute must-have features. I'll then give extra attention to those points. While it may be impossible to delineate everything that a yet to be developed product will do, your computer lawyer should concentrate on those key features.

Today I've only been able to give you an introduction to the variety of issues that should be addressed by your custom software contracts. Should you get serious about contracting with a vendor to build or modify software for you, be sure to have your technology attorney involved in the contracting process.




Mark Grossman's "TechLaw" column appears in numerous publications. Mark Grossman has extensive experience as a speaker as well. If you would like him to speak before your group or corporate meeting, please call (305) 443-8180 for information.

You can find a TechLaw archive at: www.DeWittGrossman.com.

If you have any comments, please send them to MGrossman@DeWittGrossman.com.

Disclaimer: The advice given in the TechLaw column should not be considered legal advice. This newsletter only provides general educational information. You must never rely upon the advice given here. Your individual situation may not fit the generalizations discussed. Only your attorney can evaluate your individual situation and give you advice.

Except as provided below, you may feel free to forward, distribute and copy the TechLaw column if you distribute and copy it without any changes and you include all headers and other identifying information. You may not copy it to a Web site.