Transcript Document

Contracts and
Information
Technology
Protecting Your IP Assets and Business
Through Software Licenses
Jeffrey P. Marston
MBA's Legal Issues in Mortgage Technology Conference November 30 – December 2, 2005
Contracts and Information Technology
Introduction:
1. Mortgage companies can't run without information technology.
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.
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.
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).
Second legal challenge: entering into the best possible contracts
with IT vendors.
Jeffrey P. Marston
Contracts and Information Technology
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;
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).
Equally important (but not discussed here): pay attention to
company's patents, trademarks, and trade secrets!
Jeffrey P. Marston
Contracts and Information Technology
1. Restricting the rights of third parties by contract provisions: any Bto-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
Contracts and Information Technology
2. Restricting the rights of third parties by Website disclaimers and
"clickware" agreements: before allowing the use or downloading of any Webbased software, consider requiring affirmative acceptance by the user
through the use of a provision such as the following:
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.
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.
Jeffrey P. Marston
Contracts and Information Technology
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:
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.
Jeffrey P. Marston
Contracts and Information Technology
Overview topics to be covered in connection with the second legal
challenge: entering into the best possible contracts with IT
vendors:
1. Whether your IT contracts give your mortgage company the
flexibility to do what it wants to do.
2. How to determine if your vendors are committed to meeting your
needs or are just trying to sell you a product.
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.
5. Whether the so-called "boilerplate" provisions will reflect, or
undermine, your company's expectations.
Jeffrey P. Marston
Contracts and Information Technology
Such contracts generally memorialize or address four
common IT acquisition activities:
1. The licensing of computer software;
2. Engaging Website design and development consultants (as
opposed to growing them in-house);
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.
Jeffrey P. Marston
Contracts and Information Technology
The remainder of this presentation (due to time limitations) will focus
primarily on the first such kind of contract, the software license.
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:
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);
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.
Jeffrey P. Marston
Contracts and Information Technology
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
Contracts and Information Technology
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).
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.
Jeffrey P. Marston
Contracts and Information Technology
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
Contracts and Information Technology
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.
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.
Jeffrey P. Marston
Contracts and Information Technology
"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
Contracts and Information Technology
Other Issues Regarding Software Licenses:
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.
Jeffrey P. Marston
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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:
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.
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").
Jeffrey P. Marston
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
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
Contracts and Information Technology
L. Miscellaneous Provisions (continued):
· Will the software be used for government contract work?
· 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 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)?
Jeffrey P. Marston