Introduction
This book will help you negotiate, draft, and understand information technology contracts. Specifically, it will help you with software
licenses and other soft ware transfers, as well as technology ser vices
agreements. It addresses contracts between businesses, as well as
business-to-consumer and business-to-government contracts. It also
addresses both Internet-related and offline contracts.
This book is for both lawyers and nonlawyers. The text doesn’t
use any technical jargon—any “legalese,” “engineerese,” or “programmerese.” It’s written in simple English, like a good contract.
You can use this book as a training manual or a reference guide
or both. If you’re training, read this book cover to cover. It provides
an overview of the key technology contracting concepts.
If you’re after a reference guide, you can pick and choose the
chapters to read. When you’re negotiating a contract, or reading or
writing one, look up the various clauses to learn what they mean and
what’s at stake. You’ll find sample language in each chapter, which
you can incorporate into your own contracts. Plus, if you visit this
book’s website,1 you can copy the longer sample clauses and paste
them into your document. You can also use this book’s table of contents as an issue spotter: as a checklist of clauses to consider.
Finally, you can use this book as a source of full-length contract
forms. Appendix 1 provides a printed contract form, and this book’s
website offers that form and several others in electronic format.
See Appendix 1 for a list of the contracts available. Or see the website itself.
This book can’t replace a lawyer—or a colleague with more information technology (IT) experience, if you are a lawyer. But it can
help you understand your lawyer—or colleague. And whether you
1. www.TechContractsHandbook.com.
xi
xii
Introduction
have legal help or not, the better you understand your contracts, the
more effective you’ll be.
I’m a technology lawyer, and this book grew out of a seminar I
teach, for both attorneys and nonattorneys. At the end of the program, students often asked where they could learn more—if there
was a good book on soft ware and IT ser vices contracts. Most of the
books I knew were massive tomes on intellectual property or contract law. They’re written for lawyers only, and their more practical lessons are spread across hundreds or thousands of pages. I’ve
learned much of my trade on the job, rather than from a book. I’ve
served as a technology lawyer with a global firm, as general counsel
for a publicly traded software company, and as vice president of
business development for an Internet start-up. I now practice through
my own technology-focused law firm in San Francisco and the Silicon Valley. The material for my seminar came from the contracts
I’ve negotiated and written in those positions. I’d never seen a really
user-friendly outline of the issues. So I wrote this book.
•
•
•
•
The rest of this introduction provides more detail about the types of
contracts this book covers. It also offers three lessons about contracting in general. Finally, it explains the structure of a contract and
of this book, and it offers a few explanations that will help you get the
most out of your reading.
Subject Matter
This book covers (1) soft ware licenses and other soft ware contracts,
(2) information technology ser vices contracts, and (3) combination
contracts, which include both software and ser vices. The text calls
the parties to all these agreements the “provider” and the “recipient.”
Soft ware contracts include end user licenses, distribution contracts, assignments, and work-for-hire agreements. In all these deals,
the provider transfers intellectual property (IP) rights to the recipient. The IP rights in question usually come from copyright law,
though other forms of intellectual property sometimes play a role.2
The rights transferred might be limited, like the right to copy or dis2. For a broader explanation of IP and its role in soft ware contracts, see Appendix 2.
Introduction xiii
tribute soft ware. Or the recipient might receive all IP rights and become the soft ware’s new owner.
Ser vices contracts call on the provider to help the recipient,
rather than to provide soft ware or IP. The provider is going to do
something. In the information technology industry, that “something” generally has to do with soft ware and computers. IT ser vices
include network management, technology maintenance, tech support, system integration, website development, and integrated circuit design, as well as Internet connectivity and soft ware as a ser vice.
Finally, in a combination contract, the provider agrees to provide both soft ware and ser vices. Computer programming contracts,
for instance, usually call on the provider to write software, a ser vice,
and to transfer IP rights in that soft ware. Technology integration
agreements often work the same way: the provider licenses or sells
software to the recipient and also provides a ser vice by integrating
several applications into a computer system. A combination contract
works like two contracts in one. It needs terms appropriate for both
soft ware and ser vices.
Soft ware and IT ser vices may be delivered via the Internet or via
other means. So most of the clauses discussed in this book work for
Internet-related agreements and for agreements that have nothing to
do with the Internet. However, the Internet and e-commerce raise
some unique contracting issues. This book addresses those issues in
Appendices 4 and 5.
The provider of software or ser vices is usually a business, but the
recipient may be a business or a consumer. The recipient may also be
a government agency, and this book should help you understand
most government IT contracts. The following text does not, however,
address government contracting rules, like the federal acquisition
regulations (FARs) or the procurement regulations of any state. Some
of those rules dictate the language to be inserted in government contracts. This book may not address the exact language required by the
rule, but it should help you understand much of the government’s
language.3 (And of course, where the government doesn’t insist on its
own language, you can use the following sample clauses.)
3. Some government contracting rules require clauses that aren’t specifically related to technology, like “buy American” provisions and clauses on confl icts of interest
or use of recycled paper. This book doesn’t address those clauses.
xiv Introduction
Three Lessons about Contracting
1. Good Fences Make Good Neighbors
Why do we sign contracts? It’s not because we want to win a lawsuit
later. It’s not because we don’t trust each other. It’s not even because
we’re afraid lawyers will stir up trouble if they’re not kept busy.
We sign contracts because good fences make good neighbors.
The best way to avoid arguments in a business relationship is
to write down the parties’ expectations ahead of time. That list
becomes a boundary marker—like a fence between neighboring
yards—explaining who’s responsible for what. If the parties disagree,
they can look at the list for guidance.
In other words, contracts prevent disputes—at least, good ones
do. They prevent lawsuits.
Even if the parties never look back at the contract once it’s
signed, it’s still probably played a vital role. When people put their
business expectations on paper, they often find those expectations
don’t match. Just the act of negotiating a written4 contract will uncover many mismatched expectations. The parties can address them
before starting work.
Yes, it is true that we sometimes fight over contracts in lawsuits.
And yes, in interpreting a contract, we often talk about what a judge
would say it means. But that’s only because courts have the ultimate
say if the parties can’t agree. Job No. 1 for the contract is to keep the
parties out of court.
2. There Is No Such Thing as “Legalese”
or “Technicalese”
You may feel uncomfortable with contracts because of the unfamiliar language they use. Don’t be intimidated. You can understand
most contracts.
There really is no such thing as legalese. American contracts are
written in English (or Spanish or Vietnamese or whatever language
4. Many contracts can be oral rather than written, but some can’t. And oral contracts have serious disadvantages. Without a clear recording of the terms, the parties
have to rely on memories, so the contract won’t serve as much of a road map. And oral
contracts usually cover only high-level issues, leaving doubt about whether the parties
actually agree on vital details.
Introduction
the parties speak). But contracts do sometimes use special shorthand—terms lawyers have developed to save time. And some IT
contracts use “technology shorthand.” Finally, contracts sometimes
use formal, stilted language with long run-on sentences. Don’t let
shorthand or stilted language bother you.
If you run into an unfamiliar term in a contract—unfamiliar
shorthand—don’t worry. Look it up. If it’s legal shorthand, you can
probably find the definition in a standard dictionary, or online, or in
Black’s Law Dictionary,5 found in many libraries. Or, better yet, ask a
lawyer. Treat technology terms the same way. Look them up in a dictionary or technical manual or online. Or ask someone with the right
expertise.
Once you understand a term, feel free to use it in your own contracts. But you should also feel free not to use it. Shorthand is optional. If you do use shorthand, be sure the contract defines each
technical term. Definitions can vary for IT terms like “RGB” and
“bot,”6 so the contract needs an agreed definition, unless there really
can’t be any doubt. (See The Structure of a Contract and of This Book,
page xvi, for more on defined terms.) Legal terms, on the other hand,
often have widely accepted definitions, so you usually don’t need to
define them in the contract.
As for long sentences, just take a deep breath and read slowly.
The same goes for formal language. There really is no reason to use
terms like “heretofore” and “ipso facto.” That sort of language often
appears in form contracts from the olden days, when formal writing
was more popular. It does crop up in modern contracts—often because someone wants to show off a big vocabulary. Be suitably impressed. Then take out your dictionary if necessary and figure out
what each sentence says. And avoid terms like that in your own
writing.
3. Leverage Is Everything; “Fairness”
Is Nothing
A lot of people who negotiate contracts get tied up in knots over
what is fair. They feel outraged if they’re “forced” to sign an “unfair”
5. From the West Publishing Company.
6. RGB: red-green-blue, a term used for computer screen technology. Bot: a software program that mimics human behavior in that it’s automated (short for robot).
xv
xvi Introduction
contract. That’s a bad way to look at contracts. You’ll do better if you
think about leverage, not fairness.
In general, no one has to sign a contract. So if you do agree to
terms you dislike, terms that seem “unfair,” you probably are getting
something worthwhile. Obviously, you’re not getting as much as you
wanted, but you wouldn’t have agreed if the exchange weren’t better
than nothing—better than not doing business at all. So long as no
one’s pointing a gun at your head (or otherwise forcing you through
illegal “duress”), whatever terms you accept are probably fair.7
So if considerations of fairness aren’t decisive, how do the parties resolve differences of opinion during negotiations? What guides
the arguing and negotiating, and the eventual compromise or knuckling under that leads to a contract? It’s leverage.
If you need the deal more than the other party, you will probably
give more. And vice versa. It’s that simple. Don’t get upset about it,
and when you’re in the power position, don’t take advantage of it too
much. You never know when positions will reverse.
The Structure of a Contract
and of This Book
Soft ware and ser vices contract terms fall into three groups: transactional clauses, general clauses, and supporting clauses. This book is
organized the same way.
The transactional clauses express the deal’s central terms. There,
the provider grants a license or other rights to soft ware, or promises to provide services—or both. The recipient, on the other hand,
promises to pay. This book addresses transactional clauses in Part I.
The general clauses account for most of the rest of the contract.
They cover everything not addressed in the transactional clauses
or the supporting clauses. This book addresses general clauses in
Part II.
Supporting clauses cover the theoretically noncontroversial mechanics of a deal: terms on independent contractor status, contract
construction, choice of law, etc. Information technology profession7. OK, that’s not entirely true, at least as far as the law is concerned. There are
some terms courts won’t enforce because they’re “opposed to public policy” or “unconscionable.”
Introduction xvii
als call many of these clauses “boilerplate” and place them at the end
of a contract. This book addresses supporting clauses in Part III.
Most contracts start with two sets of supporting clauses: the introduction and recitals and the definitions.8 From there on, you
should organize your clauses the way they’re listed: transactional
clauses, then general clauses, then the remaining supporting clauses.
That makes agreements easy to understand. Unfortunately though,
you’ll probably find contracts with the clauses jumbled together, in
no particular order.
Using This Book
The following five brief notes and explanations will help you get the
most out of this book.
First, “one size fits all” rarely works for contracts. Good contracts are customized. So look at this book as a source of general lessons to be applied thoughtfully to each deal. Your deal probably
raises unique issues. “We don’t have an office near Albuquerque, so
ser vices there will be delayed.” “We can’t promise the soft ware will
interface with your payroll system because we’ve never tested it.”
“Our CFO gets hives if we pay more than twenty percent in advance.”
This book offers building blocks for a contract addressing issues like
those, but the customizations are up to you.
Bear that in mind as you review the example clauses. This book
is full of sample contract language, mostly in separate clause boxes.
If you put one of those clauses into your contract, you will probably
need to tweak it.
Second, this book addresses U.S. law. That means it may not be
useful for foreign contracts. Within the United States, the fift y states
have similar contract laws, and federal law governs some of the issues discussed here. But state laws do vary. Some lessons here apply
better to one state than another. That’s one of the reasons you should
consider help from an experienced lawyer.
Third, like most contracts, the examples in this book use defined terms. When a contract creates a concept and uses it more than
once, it usually defines it. For instance, a contract might list the provider’s ser vices in Section 2, then mention them over and over in
8. See Chapters III.A and III.B.
xviii Introduction
other sections. Rather than listing the ser vices repeatedly, the contract defines the list as the “Ser vices.” Whenever the contract refers
to the “Ser vices” with a capital S, it means the whole list. This book’s
sample clauses work the same way: capitalized words that aren’t
proper names represent defined terms—e.g., “Soft ware,” “Effective
Date,” “Statement of Work,” this “Agreement.” (Some contracts mark
defi ned terms with all caps instead—e.g., the “SERVICES.”) The
same goes for sets of initials in all caps, like “NDA” (for nondisclosure agreement). In this book, the sample clause often won’t supply
the definition. That’s because, in a real contract, that term would be
defined in another section. Obviously, in your contracts, you should
provide the definitions somewhere. For more on defined terms, see
Chapter III.B.
Fourth, almost all the sample clauses use the defined terms
“Provider” and “Recipient.” As noted, the text refers to the contracting parties the same way. Don’t be confused if contracts you’ve seen
use other names. “Provider” stands in for “Licensor,” “Transferor,”
“Vendor,” “Seller,” and “Consultant,” among others. And “Recipient” stands in for “Licensee,” “Transferee,” “Customer,” “Buyer,”
and “Client.” This book favors “Provider” and “Recipient” because
they’re generic. But the text does occasionally use names like “Distributor” where necessary to avoid confusion.
Fift h and finally, this book includes the world’s shortest glossary
(at the end). It explains nine terms and phrases you’ll see repeatedly
in the text: calendar year, calendar month, calendar quarter, including without limitation, machine-based service, mask works, object
code, source code, and without limiting the generality of the foregoing.