MBA's Legal Issues in Mortgage Technology Conference November 30 – December 2, 2005 Contracts and...

MBA's Legal Issues in Mortgage Technology Conference November 30 – December 2, 2005 MBA's Legal Issues in Mortgage Technology Conference November 30 – December 2, 2005

Contracts and Information Technology

Protecting Your IP Assets and Business Through Software Licenses

Jeffrey P. Marston

Second legal challenge: entering into the best possible contracts with IT vendors.


Jeffrey P. Marston

Introduction:

First legal challenge: protecting your company's own intellectual property rights (through software licenses and other agreements with third parties, Web site "clickware" agreements, and employee certifications).

2. Such technology (other than hardware) usually is either: (i) owned and developed by the mortgage company itself, or (ii) licensed from IT vendors, typically through contracts called software licenses.

1. Mortgage companies can't run without information technology.

3. Even though such software licenses are the lifeblood of a typical mortgage company's business, such contracts (when compared to other contracts of critical importance to the company) have received relatively little attention from senior management and lawyers.


Jeffrey P. Marston

2. Restricting the rights of third parties (such as other business partners and borrowers) by Web site disclaimers and "clickware" agreements; and

3. Protecting the company from the misappropriation of intellectual property by current and former employees (and others with access to company trade secrets and other proprietary or confidential information).

To be covered (briefly) in connection with the first legal challenge: Protecting the company's own intellectual property rights:

1. Restricting the rights of third parties by contract provisions (including employment agreements and agreements with independent contractors and consultants), as well as software licenses;

Equally important (but not discussed here): pay attention to company's patents, trademarks, and trade secrets!


Jeffrey P. Marston

1. Restricting the rights of third parties by contract provisions: any B- to-B contract (as well as certain agreements with consumers, such as unique mortgage calculation engines) involving or using any proprietary software or other valuable intellectual property rights should contain a clause such as the following:

Customer acknowledges and agrees that the Software is the sole and exclusive property of the Company, and constitutes valuable trade secrets belonging to the Company. By entering into this Agreement, Customer does not become the owner of the Software, or gain any rights with respect to the Software other than the rights expressly set forth in this Agreement. The Company reserves the right to seek injunctive and all other legal remedies available should the Software be used in a manner contrary to the uses permitted under this Agreement.

The goal of such language is to avoid any argument that the user or licensee is gaining any intellectual property rights, other than those that are narrowly circumscribed in the software license.


Jeffrey P. Marston

THIS AGREEMENT IS A CONTRACT BETWEEN YOU AND THE COMPANY. BY INDICATING YOUR ACCEPTANCE BELOW, YOU ACCEPT ALL THE TERMS AND CONDITIONS OF THIS AGREEMENT AND WILL BE PERMITTED TO ACCESS AND DOWNLOAD THE SOFTWARE DESCRIBED ABOVE. IF YOU DO NOT ACCEPT THE TERMS AND CONDITIONS OF THIS AGREEMENT, INDICATE BELOW THAT YOU DO NOT AGREE AND YOU WILL NOT BE PERMITTED ACCESS AND DOWNLOADING.

2. Restricting the rights of third parties by Website disclaimers and "clickware" agreements: before allowing the use or downloading of any Web-based software, consider requiring affirmative acceptance by the user through the use of a provision such as the following:

Unlike "shrinkwrap" agreements, which have been found by many courts to be unenforceable, in the recent past, most courts have found "clickware" agreements to be enforceable because of the user's affirmative act of acceptance. Modern trend: it is not decisive that a consumer actually read the provisions; instead, the consumer must: (i) be provided with the contract; (ii) have an opportunity to read it before accepting or rejecting it; and (iii) take some affirmative step indicating his or her assent to the contract.

https://www.softwarekey.com/products/2_custlogin.asp?P=7576&T=1191&A=2468631&PrCode=&D=&U=&E=&S=&Q=T%3D1191%26U%3D%26C%3D%26&Pw=&Quantity=1

http://www.softwarekey.com/products/custom/2468631/order.asp?T=1191&U=&C=&


Jeffrey P. Marston

Contractor acknowledges the confidential and secret character of the Confidential Information and agrees that the Confidential Information is the sole, exclusive, and extremely valuable property of the Company. Accordingly, Contractor agrees (i) not to reproduce any of the Confidential Information without the Company's prior written consent; (ii) not to use the Confidential Information except in the performance of this Agreement, and (iii) not to divulge all or any part of the Confidential Information in any form to any third party, either during or after the term of this Agreement. Upon termination of this Agreement for any reason including expiration of term, Contractor agrees to cease using and to return to the Company all whole and partial copies and derivatives of the Confidential Information, whether in Contractor's possession or under Contractor's direct or indirect control.

3. Protecting the company from the misappropriation of intellectual property by current and former employees (and others with access to company trade secrets and other proprietary or confidential information): many mortgage companies require new employees to sign a certification indicating that they understand that any and all inventions, patents, and other intellectual property created or worked on by the employee during the course of his or her employment belongs exclusively to the company. Some companies require such a certification annually (and upon termination). Similar provisions are appropriate in employment agreements and consulting agreements; here is a (short-form) version of such a provision in a consulting agreement:


Jeffrey P. Marston

3. Whether your vendor's obligations will be enforceable.

4. Whether your mortgage company will have meaningful remedies if the vendor fails to meet its obligations.

1. Whether your IT contracts give your mortgage company the flexibility to do what it wants to do.

5. Whether the so-called "boilerplate" provisions will reflect, or undermine, your company's expectations.

Overview topics to be covered in connection with the second legal challenge: entering into the best possible contracts with IT vendors:

2. How to determine if your vendors are committed to meeting your needs or are just trying to sell you a product.


Jeffrey P. Marston

3. Buying and implementing computer hardware to use for running the software; and

4. Outsourcing IT functions, such as Website hosting, to an outside vendor.

1. The licensing of computer software;

Such contracts generally memorialize or address four common IT acquisition activities:

2. Engaging Website design and development consultants (as opposed to growing them in-house);


Jeffrey P. Marston

2. Whether the vendor's product will interface and integrate cleanly with other systems; and

3. Whether the vendor will provide adequate acceptance testing, training, support, and disaster recovery.

Of the four IT acquisition activities listed, the licensing of software is probably the most critical for most mortgage companies; it often involves "bet your company" decisions about such matters as:

The remainder of this presentation (due to time limitations) will focus primarily on the first such kind of contract, the software license.

1. The identity, capabilities, financial resources and track record of the software vendor, as well as whether regulatory approval may be required (e.g., "significant contracts" under Thrift Bulletin 82a);


Jeffrey P. Marston

Flexibility in software licenses, and avoiding contractual impediments: most negotiations begin with the vendor's "standard form contract," which is often presented as "non-negotiable." Almost without exception, such form is negotiable. Failure to negotiate may result in severe contractual impediments, such as (i) a confidentiality clause that prevents a mortgage company from giving a third party provider access to the vendor's product, thereby making the vendor the only source of training, installation, systems integration, operation and maintenance services; (ii) an assignment clause that could prevent the mortgage company from selling its business or assets without the vendor's consent, giving vendor the opportunity to demand additional payments; and (iii) a "scope of use" clause that allows a mortgage company to use technology only in its current business model, size, scope or technology configuration. In the constantly evolving and quickly changing mortgage marketplace, any of these factors can be seriously debilitating (and embarrassing to explain to the board why they are in the contract).


Jeffrey P. Marston

Similar problem regarding service vendors: often, they promise only to supply people with the right titles (such as "senior programmer" or "project manager"), rather than the appropriate skill sets, experience, and training.

Providing product, rather than meeting needs: Vendor's standard form, if it promises anything, usually will only promise that the product meets the vendor's specifications for the applicable product or service. Such specifications are often very brief and vague, making it very difficult subsequently to claim that the product or service fails to comply with such specifications. Often, the vendor will not even provide the mortgage company with a copy of the product's specifications unless the mortgage company demands it. It is critically important, therefore, to "contract for needs," rather than "contract for product." This requires businesses to define their needs clearly and completely in writing (which is a difficult and time-consuming process, but one that often is the difference between a project's success or failure).


Jeffrey P. Marston

Vagueness; Lack of Clarity: A mortgage company can only enforce a vendor's contractual obligations if the company can prove that such obligations (i) were part of the software license, and (ii) were breached. Vendors are talented in making a contract provision uselessly vague: for example, consider the use of the word "reasonable" in the following clause: "the vendor will cooperate with the mortgage company's reasonable requests for support." The addition of "reasonable" converts what might be a clear obligation that a judge can interpret without a trial to a fact question for a jury (making the litigation far more expensive).


Jeffrey P. Marston

Mortgage companies should, at a minimum, consider provisions that allow unrestricted damages for intellectual property infringement, death, bodily injury, damage to tangible personal property, and breaches of confidentiality obligations.

Remedies: If a mortgage company can establish that the vendor breached a contractual obligation, the court will provide a remedy. Vendor's standard form software licenses typically specify the following types of limitations on remedies: (i) a limit on direct damages (i.e., the out-of-pocket expenses incurred due to failure of the product to perform substantially in accordance with its specifications) – usually, vendors will try to limit this exposure to the amount of fees paid by the mortgage company (either over the life of the contract, or over some shorter specified period); and (ii) exclusions of lost profits, consequential damages, punitive damages, and all other damages that aren't direct damages. In the place of such damages, vendors often offer exclusive remedies for failure (usually the opportunity to replace or repair the defective product or service). The problem with these limitations: the mortgage company is deprived of fundamental promise of contract law – that the breaching party will make the injured party whole. The nature of the IT industry is such, however, that many vendors will not contract without the first two limitations.


Jeffrey P. Marston

"Boilerplate:" at the end of most standard form software licenses (and most other contracts) are some seemingly innocuous "boilerplate" terms that even many lawyers gloss over. These terms can actually be of critical importance, and the failure to pay them adequate attention can reverse or undermine some of a mortgage company's most critical assumptions. For example: (i) termination provisions may give the vendor the right to terminate the contract for the slightest transgression – this may provide a draconian remedy if the mortgage company's online business is built around the vendor's product (for example, vendors are sometimes able to terminate through self-help, such as by discontinuing use of a license key); (ii) payment provisions that make no allowance for good faith disputes; (iii) jurisdiction and venue clauses that give the vendor the home court advantage in any dispute (and make the mortgage company's lawsuit more expensive); and (iv) a right to subcontract that means the services may be provided by someone other than the carefully selected vendor.


Jeffrey P. Marston

A. The Trend Toward Value Pricing: License provisions that do not have revenue implications for software vendors have tended to become more even-handed over the last decade or so; for example, in addition to giving mortgage companies the right to make a backup copy of software, vendors now often grant a right to use a copy of the software for testing. Software vendors have, however, also devised new and creative ways to "value price" their software, in an attempt to create future revenue. Vendors see mortgage lenders as institutions that derive a great deal of value from software, and vendors want a share of that value as revenue; this explains the trend toward charging a license fee based on the number of loan transactions processed by the software. In a typical standard form licensing agreement, most of the language that limits a mortgage company's use of the software is attempting to set the stage for collecting more revenue from mortgage companies who make more use of the software. The software user should be aware of this trend, and should be sure that it understands the way that use of the software is priced, and ways in which the use of the software is (or may in the future be) restricted.

Other Issues Regarding Software Licenses:


Jeffrey P. Marston

B. Potential Pitfalls for the Mortgage Company: Mortgage companies should generally only have three basic obligations under a software license: (i) an obligation to pay the licensing fees; (ii) an obligation to use the software only as provided in the software license; and (iii) an obligation not to disclose any of the vendor's confidential information. Vendors, however, have ingeniously found other obligations to impose on mortgage companies, often (a) giving a "hair-trigger" right of termination for the slightest mistake; and (b) severely restricting use of the software, such that the user must pay more. For example, many software licenses specify that the software may only be used at a specific address. What happens if the mortgage company relocates? Vendors often discover such a fact in the process of providing support, and use this fact as an opportunity to declare a breach of contract (giving rise to a damages claim), or, perhaps more commonly, giving rise to a demand for a "transfer fee." Software licenses should be carefully reviewed for such traps for the unwary.


Jeffrey P. Marston

C. Grant of the License: this provides the basic right to use the software. It typically addresses the what, how, by whom, for what, where, and for how long, of the software license. Limits may be placed on the use of the software in the following ways (among others): (i) sites listed on a schedule; (ii) a specified Web site URL (Uniform Resource Locator); (iii) a particular application or business model; (iv) "internal use only" or "not for service bureau use" (terms that can have unexpected results when the software is used to run a Web site); (v) a single legal entity; (vi) multiple specified legal entities, or an "enterprise;" (vii) a specified number or type of authorized users, or simultaneous users (or servers, or specific computers); and (viii) named individuals. The grant of the license may also require the user to agree not to reverse engineer, reverse compile, decompile, or reverse assemble the software or any part thereof; these are provisions designed to prevent the user from obtaining the source code.


Jeffrey P. Marston

D. Source Code: this is the "human readable" form of software. The source code for most programs used in mortgage banking is written in programming languages that are mostly English words, and source code normally includes comments, in English, explaining what the software is intended to do. Source code is translated into object code, or machine language (i.e., a series of 1s and 0s), using a program called a compiler. Object code is extremely difficult (but not impossible) for humans to understand, or to modify, without access to the corresponding source code. Vendors, therefore, are very protective of their source code.

A mortgage company does not generally need access to the source code unless the vendor is unable or unwilling to modify or maintain the software. If a mortgage company is entirely dependent on a particular software, and the company would be unable to replace such software quickly and easily, it may be prudent to obtain access to the source code (at least under certain circumstances, such as the vendor's bankruptcy). This is normally done in one of two ways: (i) a source code license (which tends to be much more expensive than an object code license), or (ii) a source code escrow arrangement. Under an escrow arrangement, the vendor typically deposits the source code with an independent third party escrow agent. The agent is usually bound under a three-party agreement that provides "release conditions." In some cases, regulated institutions are required to have such an escrow arrangement for certain critical types of software. Release conditions are heavily negotiated, as are verification and updating procedures (to verify that the escrowed source code is valid and current).


Jeffrey P. Marston

E. Delivery and Installation: A key issue sometimes overlooked (usually, by counsel to the mortgage company) in software licenses is when "delivery" and "installation" of the software will be deemed to have occurred. This issue can be significant when, for example, the license calls for installation of certain software on hundreds, or even thousands, of the mortgage company's computers, perhaps at multiple sites, and payment is due "upon delivery."

F. Training: Parties to a software license should also consider the training needs of the mortgage company. Assuming that training will be required, the mortgage company should attempt to specify in the contract by whom such training will be conducted (and when, how long, where, etc.). Other relevant questions include: What qualifications must the trainers have? Will such training consist merely of lectures, or will it be "hands-on?" How will the vendor be compensated for its training efforts (travel costs, materials, hourly rates of training personnel)?


Jeffrey P. Marston

G. Acceptance: Installation and testing of software is also often a crucial, yet sometimes overlooked, aspect of the deal between a software vendor and a mortgage company. Many software products can be easily installed by the mortgage company, particularly where the company has its own information/technology personnel or department. Other products, however, require extensive testing as part of the installation process. Consider, for example, the difference between a company that is upgrading from one version of a common desktop utility software to another on a single PC, and a company that is installing new software to run its mortgage servicing data processing. The former example involves a situation that is usually adequately handled by in-house computer personnel. The latter example, however, may involve a "bet your company" level of exposure, where critical mistakes may cripple the mortgage company's ability to conduct business, as well as create potentially enormous exposure to consumers, regulators, and investors (for missed payments, for example, to taxing authorities or insurers). In such a case, extensive installation and acceptance testing is essential. Before a mortgage company is obligated to pay the hefty price tag usually associated with such software, the company should be certain that the software conforms to the applicable specifications, and that it works for its intended purpose. Often, this may involve a lengthy testing period, sometimes requiring that data be "parallel processed," using the old system and the new, so that results can be compared. Licensees in such a situation will want the software license to contain substantial protections; among other provisions, the software license should provide that a significant portion of the price will be withheld until acceptance testing (sometimes also called "beta" testing) is successfully completed.


Jeffrey P. Marston

H. Price; Payment Provisions: As in any other contract for goods or services, the parties to a software license should focus carefully on pricing and payment issues. Depending on a variety of factors (such as, for example, the type of software involved; the significance to the vendor of the license fees under the contract; and whether there is an established market for the software, or whether the mortgage company will be the first to test the software), the mortgage company may want to consider asking the vendor to give the company "most favored customer" treatment. The parties should also consider when payment is due; this will often be tied to the progress of delivery, installation, and acceptance testing. A common payment structure involves the payment of a percentage (such as a third) of the overall price of the software upon execution of the contract, a second installment upon delivery (and/or installation), and the final installment upon the mortgage company's acceptance. Obviously, depending upon (among other factors) the bargaining power of the parties, the percentages (and the events requiring payment) will vary greatly. The parties to the software license should remember to specify whether insurance will be required, and, if so, who is responsible for paying for it.


Jeffrey P. Marston

I. Support and Maintenance: Often, the provisions concerning support and maintenance obligations of the vendor are not part of the software license agreement, but are set forth in a separate maintenance or operations agreement. Such provisions are also often intertwined with issues relating to warranty periods for the software (for example, the obligation to provide maintenance – for which the vendor typically gets paid – often begins at the end of the warranty period, during which the vendor, typically without payment, has an obligation under the software license to fix problems with the software).

It is important, when dealing with maintenance obligations, to distinguish between updates or improvements to the software (which enhance the software's ability to accomplish certain tasks), on the one hand, and changes or modifications designed to fix existing errors or bugs in the software, on the other hand. Usually, mortgage companies should only have to pay for the former.

With respect to error corrections, it may be desirable to specify the level and qualifications of support staff to be provided by the vendor. The license may specify that if the problem is "major" rather than "minor," a higher level of attention is warranted (or perhaps liquidated damages will apply if major problems can't be remedied within a specified time period). The license should also define what would constitute a "major" problem (for example, if the mortgage company's ability to process servicing information is adversely affected for more than ____ seconds, the problem might be classified as "major"). Such provisions are often contained in a "service level addendum" to the software license.


Jeffrey P. Marston

I. Support and Maintenance (continued): One way that maintenance problems are often addressed in software maintenance contracts (or service level addenda) is to use "phased escalation" (if person A at the vendor can't solve the problem, the licensee is entitled to contact person B, etc., on up through the development team and, ultimately, the president of the company). Sometimes the vendor's preferred method of penalizing itself for maintenance failures – which is to allow the vendor to withhold payments of future license and/or maintenance fees, until the problem is resolved, or to provide for the return of previously paid fees – will be insufficient from the mortgage company's perspective, particularly in situations where the mortgage company's livelihood is at stake. In such situations, the mortgage company should consider negotiating for liquidated damages if the problem isn't adequately resolved within a stated time period. The mortgage company should take care to avoid characterizing in the contract any such payments as "penalties," which may be unenforceable in the event of the vendor's bankruptcy (and probably in other situations, as well).


Jeffrey P. Marston

I. Support and Maintenance (continued): Maintenance agreements (and the software underlying license agreements) sometimes obligate the vendor to disclose problems identified by other licensees. This can be a very valuable provision to the mortgage company, particularly if the vendor will also agree to fix any problems so identified. In some cases, the licensees for a particular software product or products form a "user's group" and bargain collectively with the vendor concerning such things as the pricing and delivery of additions, corrections, or enhancements that are desired by the group at large. This is a fairly common occurrence in the mortgage industry. (Participation in such user's groups may raise legal issues, such as breach of confidentiality obligations and potential antitrust concerns, and should therefore be carefully reviewed by counsel.)

Finally, the mortgage company should try to pin down as precisely as possible the price of future maintenance services by the vendor. Usually, the mortgage company wants the cost of such services to remain fixed for as long a period as possible. The company may want to negotiate a cap on price increases that may arise after the fixed cost period (often, such a cap may be tied to a cost-of-living index). The vendor, on the other hand, typically wants as much flexibility on pricing as possible. If the vendor is willing to agree to cap future increases in costs, it is not unusual for the vendor to insist that price increases imposed by third parties (such as suppliers), or increases attributable to changes in the regulatory landscape, which increases are beyond the vendor's reasonable control, may be passed along to the mortgage company, without regard to any such cap. In such an event, the mortgage company should negotiate for the right to receive reasonable written evidence of any such third party price increases.


Jeffrey P. Marston

J. Warranties: Software vendors and licensees often do battle over performance warranties, which are the vendor's promises regarding the standards of performance that will apply to the software. Such warranties can be either express or implied.

(a) Express Warranties. It is common for a licensor's standard form contract to attempt to disclaim any express warranty, and provide that the software is being licensed "as is." A (short-form) example of such a disclaimer is the following:

This sort of language usually is found in the contracts (which are often "online" contracts) accompanying "shrinkwrapped" or "off the shelf" software. Such software generally doesn't require any special installation or testing, and vendors typically will only give warranties about the media (e.g., the disk that contains the software is free from defects). With respect to more complex or custom software, however, mortgage companies should strive to strike this language from the contract, and obtain some comfort from the vendor that the software will perform as expected (most likely standard: "substantially in accordance with its specifications").

The Software is provided to Licensee on an "as is" basis, and all warranties are excluded, including the warranties of merchantability and fitness for a particular purpose.


Jeffrey P. Marston

J. Warranties (continued): As to just how much comfort mortgage companies should reasonably expect, the answer is probably not very much. For example, most software vendors are unwilling to represent or warrant that the software is free from defects (virtually all complicated software has defects or "bugs" to some extent); many vendors may, however, be willing to state that the software is, to the best of their knowledge, free from defects. Vendors may also be willing to represent and warrant that the software will perform substantially in accordance with its specifications. It is important, therefore, that the mortgage company has studied such specifications, and determined that the documentation adequately describes the software product and what such product is supposed to accomplish. Here is a performance representation and warranty that is drafted from the mortgage company's perspective:

The Software: (i) performs in accordance with the Specifications and other written materials used in connection with such Software; (ii) is free of significant defects in programming, documentation, and operation; (iii) operates and runs in a reasonable and efficient manner; (iv) is in machine-readable form; (v) contains all current revisions of said Software; (vi) can be recreated from the associated source code; and (vii) includes all computer programs, materials, tapes, disks, know-how, object and source codes, and other written materials related to such Software.


Jeffrey P. Marston

J. Warranties (continued): Most vendors will expressly warrant that they have all the intellectual property rights necessary to license the software, and will usually offer protection to mortgage companies against infringement of intellectual property rights of others. As noted above, whether the vendor in fact owns the intellectual property it is attempting to license is an appropriate topic for mortgage companies to consider before the license is executed. Set forth below is an example of a representation and warranty that is fairly protective of the mortgage company's interests in this regard:

Vendor's development, use, sale, or exploitation of the Software or any part thereof does not violate or infringe upon the rights (whether statutory or common law) of any other Person, including without limitation intellectual property rights and rights relating to defamation, contractual rights, privacy or publicity, and Vendor has received no communication alleging such a violation or infringement. Vendor does not have any obligation to compensate any Person for the development, use, sale, or exploitation of the Software, nor has Vendor granted to any other Person any license, option, or other rights to develop, use, sell, or exploit in any manner the Software (whether requiring the payment of royalties or not).


Jeffrey P. Marston

J. Warranties (continued): (b) Implied Warranties. If a software license agreement is subject to the Uniform Commercial Code ("UCC"), the following two implied warranties, unless disclaimed, are automatically considered to be a part of the contract: (i) warranty of merchantability (UCC Section 2-314), and (ii) warranty of fitness for the licensee's particular purpose (UCC Section 2-315). The UCC expressly permits, however, the parties to a contract to disclaim these two implied warranties (UCC Section 2-316). Set forth below is a sample provision excluding the implied warranties:

THE WARRANTY SET FORTH ABOVE CONSTITUTES THE ONLY WARRANTY MADE BY THE LICENSOR WITH RESPECT TO THIS AGREEMENT. THE LICENSEE HEREBY WAIVES ALL OTHER WARRANTIES OR GUARANTEES OF THE LICENSOR, WHETHER EXPRESS OR IMPLIED, INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND ANY OTHER WARRANTY WITH RESPECT TO THE ACCURACY, QUALITY, OR FREEDOM FROM ERROR IN CONNECTION WITH THE OPERATION, USE, AND FUNCTION OF THE SOFTWARE.

To be effective, such a disclaimer must be "conspicuous." This usually means that it must be in all capital letters, and larger than 10 point type.


Jeffrey P. Marston

K. UCC and UCITA: UCC Article 2 on "Sales" (Sections 2-201 through 2-207) governs the sale of "goods." It is fairly well established that mass-marketed, "off-the-shelf," or "shrinkwrapped" software qualifies as "goods" under the UCC. What may surprise some, however, is that each of the following types of software licenses may be found to constitute "sales" for UCC purposes: (i) full payment of license fee at outset; (ii) periodic payments; (iii) short term license; and (iv) perpetual license. Thus, if the software products subject to these licenses are found to be "goods," the transaction will likely be governed by the UCC.

As noted above, pre-packaged software products are likely to be considered "goods" under the UCC. With respect to custom software (i.e., software that is developed for the use of a particular licensee), whether the UCC will govern is more a matter of interpretation; the answer may depend at least to some extent on whether the contract is primarily for: (i) an end product to be delivered to the user, or (ii) services. If, however, the software is bundled with hardware, the entire transaction may very well be viewed as a system purchase covered by the UCC (irrespective of whether the contract is primarily for goods or services).


Jeffrey P. Marston

K. UCC and UCITA (continued): As indicated above (in the discussion of implied warranties), whether the UCC applies to a particular transaction may be very significant in any interpretation of the warranties made and disclaimed under the contract. If a contract is subject to the UCC, of course, there may be a great deal of guidance provided by this law on other matters as well, including any issues involving contract formation in general, offer and acceptance, unconscionability of contract terms, etc.

It should be noted that a proposed revision of UCC Article 2, as it pertains to software (which revision was originally called Article 2B), was aborted, but ultimately resulted in the creation of another "uniform" law: the Uniform Computer Information Transactions Act ("UCITA"). UCITA, which received strong backing from Microsoft Corporation, America Online, and other software giants, was controversial from the outset, and was opposed by numerous consumer groups, as well as over half of the state attorneys general. Despite intensive lobbying efforts in many states, versions of UCITA have only been enacted in Maryland and Virginia. UCITA automatically imposes numerous and very significant changes on software licenses (only some of which may be overcome by specific contract language). If a software license is to be governed by Virginia or Maryland law (or, in the future, the law of any other state that enacts a version of UCITA), parties to the license should be aware of the many changes caused by UCITA. Because of the widespread opposition to the proposed law, the National Conference of Commissioners on Uniform State Laws (which originally developed the statute) decided in August of 2003 to stop promoting UCITA.


Jeffrey P. Marston

L. Miscellaneous Provisions. Other matters that should be covered by a software license (or at least considered in the drafting process) include the following (this list is in no particular order of importance, and is by no means exhaustive): Is this a one-time licensing arrangement or will there be future acquisitions from this particular vendor? (If so, the parties should perhaps consider whether or not the contract in question will serve as a template for future contracts.) Will the license granted under the contract be "corporate-wide" (i.e., universal for the particular licensee, such that any employee of the licensee will be entitled to use the software), site specific, or available only on the mortgage company's central processing unit (or will there be some other arrangement, perhaps relating to the number of end-users)? Will there be any other access restrictions (e.g., "may not disclose to third parties")? If there's a "site license," how will "site" be defined (by state, city, geographically contiguous buildings, etc.)?

· Some indication of how the software is used.

· An indication of right to assign and/or sublicense – whether the mortgage company can assign/sublicense as of right, or with consent, or with consent not unreasonably withheld – and any applicable notice period.

· Is the software currently in use? How many other users are there?


Jeffrey P. Marston

L. Miscellaneous Provisions (continued):

· Is a "no hire" clause appropriate (i.e., the vendor and the mortgage company may not hire each other's employees for the term of the contract)?

· Will the software be used for government contract work?

· Will there be modification or development work potentially involved with the software? Who will conduct such work – only the vendor, or the mortgage company as well? If the mortgage company will be involved, will it gain any intellectual property rights in the work product?

· Is there a favorable (or unfavorable) agreement currently in place with the vendor through the mortgage company's affiliate or parent company?

· Is there a previously signed letter of intent, confidentiality agreement, or other similar agreement relating to the software?

· Does the vendor restrict the copying of: (i) the software (even for backup purposes), or (ii) the documentation concerning the software? Many vendors will attempt to impose a prohibition on copying documentation, and then assess a marked-up price for additional copies of the documentation (thereby turning their copying machines into profit centers). Mortgage companies typically object to such a prohibition. The license should address the parties' respective rights in this regard. Does the contract have a governing law provision? (It should.) Have the parties considered alternative dispute resolution (mediation, arbitration)?

MBA's Legal Issues in Mortgage Technology Conference November 30 – December 2, 2005 Contracts and...

Documents

Transcript of MBA's Legal Issues in Mortgage Technology Conference November 30 – December 2, 2005 Contracts and...