This article was downloaded by: [University of Bristol]

On: 27 January 2015, At: 20:03

Publisher: Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,
37-41 Mortimer Street, London W1T 3JH, UK

Journal of Information Systems Management

Publication details, including instructions for authors and subscription information:
http://www.tandfonline.com/loi/uism19

What You Need to Know About Software Contracts

Paul S. Hoffman
Published online: 30 May 2007.

To cite this article: Paul S. Hoffman (1985) What You Need to Know About Software Contracts, Journal of Information Systems
Management, 2:1, 3-6, DOI: 10.1080/07399018508967733

To link to this article: http://dx.doi.org/10.1080/07399018508967733

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) contained
in the publications on our platform. However, Taylor & Francis, our agents, and our licensors make no
representations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the
Content. Any opinions and views expressed in this publication are the opinions and views of the authors, and
are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and
should be independently verified with primary sources of information. Taylor and Francis shall not be liable for
any losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever
or howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use of
the Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematic
reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any
form to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://
www.tandfonline.com/page/terms-and-conditions
 What You Need to
Know About Software
Contracts
Downloaded by [University of Bristol] at 20:03 27 January 2015

Paul S. Hoffman

Because the software industry is undergoing an accelerated rate of development, contract

standardization is difficult, and contracts are frequently inconsistent. The MIS manager can
contend with these discrepancies by understanding the fundamental software contract
provisions and by protecting the rights of the organization while respecting the legitimate
concerns of the software vendor.

Long-range planning is an important part of
software purchases and a primary difference
between hardware and software contracts. With
hardware contracts, the equipment is pur-
chased, installed, and, shortly afterwards, pro-
vided standard maintenance service (when the
warranty expires). Software contracts, how-
ever, present special concerns, because a long-
term legal relationship is established between
the user and the vendor.
The basic problem encountered in these
contracts is defining the software (the operating
code and such support elements as training and
documentation) in terms that are understand-
able to the vendor and the buyer. Software ac-
ceptance and warranties are also concerns, be-
Paul S. Hoffman is a lawyer specializing in computer
business and software contracts. Croton-on-HudsonNY and
is the author of The Software Legal Book.
cause they frequently cause contract disputes.
Although most standard vendor agreementsA
contain restrictive terms, this language can be
revised to satisfy specific user requirements. For
example, the buyer may wish to continue using
external programming support, but the stan-
dard vendor contract stipulates that, to protect
the vendor's proprietary rights, the software
cannot be disclosed to any third party. If the
buyer can assure the vendor of reasonable pro-
tection, this provision can be rewritten to permit
disclosure of the software to the programming
service. This article addresses the following
questions concerning proprietary rights:
What future rights will the buyer request?
Who owns modifications?
May the buyer or a third party develop simi-
lar software?
May a third party h a v e access t o the
software?
Should source code be furnished?

Winter 1985 3
 Definition of Software
Defining software can be as simple as nam-
ing an industry-standard product or as complex
as developing a detailed original definition. The
user should review the vendor's functional defi-
nition of the software to ensure that all major
elements are included. The definition can be
added to the contract as an exhibit or can be
incorporated by reference to a descriptive docu-
ment. If software is poorly defined, the user can
request that the definition be prepared as a sep-
arate contract or as a milestone in a single
contract.
The contract should usually address ele-
ments other than the operating code as de-
Downloaded by [University of Bristol] at 20:03 27 January 2015
liverable~.For example, a provision could re-
quire that qualified vendor trainers provide two
days of on-site training for user operating per-
sonnel and that training be scheduled in ad-
vance by agreement. Training materials, the
number of manuals, and installation and con-
version support should also be treated as de-
liverable~.A price list for additional copies and
services should be attached.
Acceptance and Warranty
Considerations
Once a user accepts the software, final pay-
ment must be made and the warranty period
begins. For these reasons, software acceptance
requires careful and thorough testing. A recent
trend for some software is to extend the war-
ranty, thus ameliorating the adverse conse-
quences of hasty acceptance.
Acceptance Testing
For standard software, delivery can be con-
sidered as the buyer's acceptance. If software is
custom developed by the vendor, the buyer
must ensure that the software functions proper-
ly before making the final payment. The vendor
can install the software by running an existing
acceptance test or, if there is n o such test, by
developing one with the user.
Acceptance Test. A contract provision
requiring that the vendor and buyer develop an Use and Back-up Considerations
acceptance test implies that the parties may be
unable to determine mutually agreeable accep-
tance criteria. Because many users underesti- amount
mate the time and effort involved in designing rights restrictions on back-up use and copies are
effective benchmarking standards, the accep-
tance test may never be developed. In the
worst case, failure to agree on an acceptance
test may mean that the vendor alone decides
when the software is accepted.
Acceptance by Default. An alternative
approach to acceptance testing (or a supple-
ment to the acceptance test agreement) is ad
hoc acceptance by the user. The typical ad hoc
provision requires the vendor to inform the user
when the software is installed and operable.
The software is considered accepted 30 days
after the date of installation, unless the user has
notified the vendor in writing of unsatisfied
specifications. The provision should also stipu-
late the procedures for unacceptable software.
For example, the vendor can be granted an ad-
ditional 30 days after rejection to correct and
reinstall the software. The process then begins
again.
The buyer can test the software as much or
as little as necessary during the 30 days. To re-
duce disruption at the user site, a n acceptance
test can be run at the vendor location in the
presence of the user before installation.
Acceptance by Use. Another supple-
mentary provision is acceptance by use. Al-
though the user can test the software or per-
form parallel runs, live use constitutes
acceptance.
Warranties
Most standard vendor contracts exclude all
implied warranties (e.g . , those ensuring the
software can be used for a specific application).
Although the vendor may guarantee that the
software matches a functional or technical spec-
ification, the warranty is usually limited by a
remedy (e.g., tailoring the software to the spec-
ification). Legally, the warranty is the promise
and the remedy is the user's recourse for an un-
fulfilled warranty. Although the terminology
varies from contract to contract, a vendor gen-
erally only warrants that the software is free
from errors that significantly affect its use.
A typical software vendor directly relates the
of software use to the cost. Proprietary-
 Software Contracts

not related t o the amount of use. Because the
scope of permitted use may not b e clearly
stated, the contract should be reviewed t o iden-
tify and match use restrictions to user require-
ments. Common contract restrictions limit soft-
ware use to o n e type of CPU, o n e site, internal
users only (i. e., services t o a third party are not
permitted), and/or the specified customer sub-
sidiary. Software generally can be neither used
at a service bureau nor assigned.
CPU Limitation. Although a standard
vendor contract can stipulate that only o n e type
of CPU can use the software, the user may
have several suitably configured CPUs at the
same site. If the software can run on more than
Downloaded by [University of Bristol] at 20:03 27 January 2015
the existing software, the ownership of software
developed after the contract is signed cannot be
a s easily determined.
Custom-Developed Software
If a contract involves custom software, the
vendor usually retains ownership. Software,
however, should be owned by the party best
able to market it. ,Users want to own the soft-
ware because they paid for it or because it pro-
vides the organization with a competitive mar-
ket e d g e . Simply p a y i n g for software
development does not necessarily imply that
the user owns the software; user ownership
must be specified in the contract.

o n e CPU, the user can agree to use o n e CPU

T h e ownership of custom software can be
at a time, thus limiting the software to o n e
granted as follows:
copy. A provision stating these requirements
The user owns the software.
should be included in the contract.
T h e software is jointly owned by the user
a n d v e n d o r , without accounting. This
Development Copies. If the software is
means that either party can use the software
modified, the user must ensure that develop-
at their discretion without consulting the
ment copies are not counted a s copies in use.
other party.
Programming managers should not change a
The user owns the software, but the vendor
live copy until the accuracy of the modifications
has an exclusive or nonexclusive right to
is verified. If the standard vendor contract does
market it and must pay a royalty to the user.
not permit multiple copies, the user should in-
c l u d e a provision stating that development cop-
ies of the software can be maintained for the Modifications b y the User
sole purpose of making and testing modifica-
tions a n d that the copies are not considered
If unspecified in the contract, modifications
by the user belong to the user, and those by the
copies in use.
.vendor belong to the vendor. Once the user
Internal Use Restrictions. If the stan- modifies the software, however, the vendor is
dard vendor agreement restricts the user to in- usually released from warranty or maintenance
ternal use, the buyer must identify any external obligations.
users (e.g., a subsidiary company) and then Provided vendor trade secrets are not dis-
take the license in the name of the parent com- closed, a user can sell its modifications (e.g., in
pany (rather than the subsidiary) or request a a patch) to anyone. If the modifications have a
provision for right of assignment. T h e right of high market value, the user can trade parket
assignment ensures that license agreements re- rights for vendor maintenance of the modified
main effective if an organization reorganizes. software.
An assignment provision is generally acceptable
to the vendor if the scope of permitted software
User- and Third Party-Developed
use is not significantly expanded.
Software
A user must decide whether it wants or
Proprietary Rights needs to develop software that is functionally
O n e of the most questionable areas in soft- similar to the vendor-provided software without
ware contracts is who will have what rights in obligation to the vendor. Trade-secret agree-
the future. Software ownership must be clari- ments complicate user ownership of software
fied in the original contract. Although the ven- developed later. Although the resolution of
dor undoubtedly wants to retain ownership of ownership often depends on the bargaining

Winter 1985 5
 strength of the parties, a possible solution is to
include a provision that ensures the contract
cannot be interpreted to prevent the user from
developing functionally similar software for itself
or a third party. Because questionable owner-
ship makes software unmarketable, this issue
must be settled in the original contract.
Disclosure to a Third Party
Many software contracts prohibit the user
from disclosing the software to a third party to
preserve the vendor's proprietary rights. As a
result, the software cannot be used by an exter-
nal auditor, software house, freelance program-
mer, or consultant. Because the vendor is inter-
Downloaded by [University of Bristol] at 20:03 27 January 2015
ested only in protecting its proprietary rights
and does not want to interfere with the buyer's
normal software use and development, the
vendor usually accepts a provision that allows
the user to disclose the software to a third party
if an agreement of confidentiality is signed.
Source Code
If source code is not furnished under the
contract, maintenance must be vendor provid-
ed. Many vendors believe that by retaining the
source code they are protecting the software
from modifications and theft. An organization,
however, must ensure that future maintenance
is always available, even if the user must per-
form the maintenance (in which case it must
have access to the source code).
If reluctant to release the source code, the
vendor may be willing to place it in escrow-a
third party holds the code and releases it t o the
user if, for example, the vendor declares bank-
ruptcy. This arrangement is inadequate for
code that is modified frequently by the vendor,
because the source code released from escrow
probably will not compile into the object code
currently run by the user. In addition, the user
tends t o focus its attention on the escrpw agent
rather than t h e vendor. This can b e self-
defeating when the user wants vendor person-
nel who worked on the code to continue main-
t e n a n c e after t h e vendor has gone o u t of
business.
Alternative measures for obtaining source
code include:
Using vendors that supply source code.
Establishing an in-house escrow and escrow
agent.
6 Winter 1985
Storing escrow source listings o n d i m (un-
copyable) fiche. (Some vendors are more
willing t o release a diff icult-to-transcribe list-
ing t h a n a readily copyable magnetic
medium .)
Regardless of the escrow arrangement, a user
should pay the escrow costs as well a s the cost
of producing and depositing copies and should
control how often new copies are placed in es-
crow. The user can then monitor code modifi-
cations and source escrow updates.
Although software contracts a r e seldom
identical, this article addresses the most com-
mon considerations and terms. Although legal
advice should be obtained from a professional,
the MIS manager is responsible for ascertaining
which aspects of the contract are most signifi-
cant t o the MIS function. For further insight into
software contract terms, acceptance testing and
warran ties, and proprietary rights, please con-
sult the bibliography.
Bibliography
Bender, D. Computer Law: Evidence and Procedure. New
York: Matthew Bender.
Bigelow, R.P. Computer Law and Tux Report. New York:
Warren, Gorham & bmont Inc.
Bigelow, R.P., ed. Computen t The Law, 3rd ed., Science &
Technology Section, American Bar Association. Chicago:
Commerce Clearing House Inc, 1981.
Bigelow, RP., and Nycom, S.H.Your Computer and The Law.
Englewood Cli& NJ: Prentice-Hall Inc, 1975.
Brandon, D.H., and Segelstein, S. Data Processing Contracts.
New York: Van Nostrand Reinhold, 1976.
Cohen, N.J., ed. Computer Law Reporter. Washington DC:
Computer Law Reporter Inc.
Harris, C.E.,ed, CN Report. Winter Park FL: International
Computer Negotiations Inc.
Hoffman, P.S. The SoJfware Legal Book. Madison NJ:
Camegie Press, 1982.
Goldscheider, R., and Arnold, T., ed. The Law and Business
of Licensing. New York: Clark Boardman Company Ltd.
Milgrim, R.M.Trade Secrets. New York: Matthew Bender.
Nimmer, M.B. Nimmer on Copyright. New York: Matthew
Bender.
Rutgers Computen and Technology Lnw Journal. Newark NJ:
Rutgers Law School.
Scott, M.D.,
ed. Computcr/Low Journal Los Angeles: Center
for Computer/Law.
Wise, A.N. Trade Secrets and Know-How Throughout The
World. New York: Clark Boardman Company Ltd.
b