Why does anyone need a license to software? A software recipient needs a license because software is text—a set of instructions for a computer—and the law gives the copyright holder certain monopoly rights over text. To exercise any of those monopoly rights, the recipient needs a license. But the right to use software is NOT one of those monopoly rights. So if you grant a use license, you’re really granting a license to one or more of the actual monopoly rights, and whoever’s reading the license will have to guess which ones.

Are you surprised to hear that “use” isn’t a monopoly right of copyright holders? Think of a self-help book. That’s a set of instructions in written text, just like software. Do you need a license to “use” a self-help book: to read it and follow the author’s instructions on finding your soul-mate, investing like Warren Buffet, or reorganizing your closet? Of course not. You’d need a license to copy the book, distribute copies, etc., but not to use it. The same goes for software.

The law gives the copyright holder a monopoly on the rights (1) to reproduce software (or any work of authorship), (2) to modify it (to “create derivative works”), and (3) to distribute it. It also grants a monopoly on the rights (4) to publicly perform a work of authorship and (5) to publicly display it, though those relate mostly to visual arts and don’t often come up in software deals. So a software license—a copyright license—grants one or more of those rights. A clear license lists the rights granted: “Provider hereby grants Recipient the right to reproduce and distribute the Software.” But what if the license just says, “Provider hereby grants Recipient the right to use the Software”? You can’t tell which monopoly rights the recipient gets.

As a result, a license to use software is an unclear license. To figure out what it means, you’ve got to look at the context. If it’s clear the recipient needs to reproduce the software to use it, and doesn’t need any of the other copyright monopoly rights, then a use license just grants the right to reproduce. But what if “use” of the software in question in requires that the recipient reproduce and modify it in some cases, while in others the recipient only needs to reproduce? Which does the license grant? What if some uses of the software require distribution to third parties—in a client-server setting, for instance, where third parties hold the client app? A license that merely grants the right to use won’t tell the parties what they need to know. And clarity is the whole point of a written contract or license.

If you’re the software recipient (licensee), don’t rely on the right to use. List the copyright monopoly rights you need. Make sure the license grants you the right to reproduce and distribute and modify the software if you need all three—or some subset of those if you don’t. Then, if you’ve already listed the necessary rights, you can throw in the right to use too. It won’t mean much, but it does no harm if you don’t rely on it.

If you’re the software provider (licensor), don’t grant the right to use—at least not without some explanation—because you can’t be sure what you’ve given. Instead, grant the copyright monopoly rights your recipient needs and withhold the rights it doesn’t. If the recipient needs only the right to reproduce the software, grant the right to reproduce and specify that the recipient may not distribute, modify, publicly perform, or publicly display the software. Or give the right to reproduce and modify, if that’s necessary, while specifying that the others aren’t included. Then, if your recipient insists, you can also throw in the right to use the software. It won’t mean much, but it’ll do you no harm if you’ve been clear about the copyright monopoly rights not granted.

That said, don’t hesitate to add terms about how the recipient can “use” software. A clear contract might grant the right to reproduce software, deny the other monopoly rights of copyright holders, and provide that the recipient may not “use the software to process more than 7,000 transactions per day.” There, you’re not relying on “use” as a grant of monopoly rights. You’ve got a clear grant of rights, using clear language from the copyright statute. You’re just narrowing those rights, using the verb “to use.”

—————-

—————-

Notes:

• The Tech Contracts Handbook addresses software license rights in Chapter I.C.1.
• For the monopoly rights of Copyright holders, see the Copyright statute, 17 USC § 106.

© 2012 by David W. Tollen. All rights reserved.

As you can see, the rule focuses on risk, not wrongdoing. The indemnitor doesn’t grant the indemnity because it’s done something wrong or because it might in the future. Whether or not the indemnitor ever does anything wrong, its activities create a risk of lawsuits against the other party. The indemnity shifts that risk from the other party to the indemnitor.

The rule explains the IP indemnities you see in so many tech agreements. By providing technology, the vendor creates a risk of suits against the customer, where a third party claims the customer has infringed a patent or copyright by using the technology. These suits happen a lot, and they’re expensive, so the risk imposes a real burden on the customer. It doesn’t matter whether the technology actually does infringe third party IP rights or whether the vendor ever does anything wrong. IP suits involve a risk created by the vendor’s activities, and it’s the vendor who’s in the best position to reduce that risk, by running patent searches, hiring engineers who won’t pirate software, etc. So the indemnity shifts the lawsuit risk from the customer to the vendor.

A customer might grant an indemnity too, where its activities create a lawsuit risk for the vendor. A customer involved in a dangerous business, for instance, might indemnify vendors whose staff risk injury. Imagine the customer manufactures dynamite, and an IT vendor sends staff to the customer’s factory to do some computer programming. If an accident at the plant injures a vendor employee, that employee will probably sue the vendor (among others). So the customer’s activities create a risk for the vendor—a risk the customer has the greatest ability to mitigate, through good safety policies. In that case, many vendors will request an indemnity from the customer covering personal injury suits by vendor employees. Again, it doesn’t matter whether the customer actually does something wrong to trigger an accident. What matters is that the risk arises out of the customer’s business—dynamite—not the vendor’s. The indemnity shifts the lawsuit risk from the vendor to the customer.

What about a risk arising out of both parties’ businesses, where either could be sued over the other’s actions? That case doesn’t fit the rule because it’s not one party creating a risk that the other will be sued. So an indemnity would be a poor fit and probably impossible to negotiate (though if you’re on the receiving end and you can get one, great!). The exception is a bad event much more likely to result from one party’s actions than the other’s. There, an indemnity might work. Let’s look at a data management contract where the customer holds consumers’ private data and hires the vendor to manage that data. A data leak will probably trigger consumer lawsuits against both parties. If the vendor only touches the data briefly, we know in advance that a leak will probably result from the customer’s activities, even though it could result from vendor’s actions. So the customer might indemnify the vendor. Or maybe the customer is huge and holds millions’ of consumers’ private data, while the vendor is a tiny start-up. The key risk arises from the customer’s sheer size, regardless of who causes a leak, so in a meaningful sense, it’s a risk mostly attributable to the customer. Again, the customer might indemnify the vendor (and the vendor might not be able to afford the deal any other way). On the other hand, imagine the vendor’s whole sales pitch revolves around protection of a particular type of data, and the customer relies almost entirely on the vendor to secure the data. In that case, a leak would probably result from the vendor’s actions, and the vendor is likely to indemnify the customer.

You should never use fault to determine who indemnifies whom. In other words, don’t draft an indemnity saying the party at fault for a bad event will indemnify the other. The point is for the indemnitor to defend the other party. And at the start of the lawsuit, when defense obligations kick in, no one knows who’s at fault. That’s not clear until the end of the case, when a court rules on fault. The indemnitor should be on the hook for a particular type of claim, regardless of who’s at fault—because the indemnitor creates the risk. If that places an unfair burden on the indemnitor, then the loss in question isn’t a good candidate for indemnity. (For more on the role of fault, or the lack thereof, see Mirror Indemnities Dont’ Work.)

If indemnity doesn’t fit or you just can’t agree on one, try a lighter contract remedy: a representation or warranty. In other words, if the promisor refuses an indemnity covering some bad event, it can still represent or warrant that the bad event hasn’t happened or won’t. If the rep or warranty turns out wrong, the promisor has breached the contract and probably owes damages. That’s generally not as powerful a remedy as the lawsuit defense you get in an indemnity, but it’s still got teeth. And that’s how most contractual obligations get enforced.

—————-

—————-

Notes:

• The Tech Contracts Handbook addresses indemnities in Chapter II.K.

© 2011 by David W. Tollen. All rights reserved.

MBNDXQV5DP6Z

In other words, insert something like the following into your agreement with a contractor or partner:
“Company has not agreed to and does not agree to treat as confidential any suggestion or idea provided by Contractor (any ‘Feedback’), and nothing in this Agreement or in the parties’ dealings arising out of or related to this Agreement will restrict Company’s right to use, profit from, disclose, publish, or otherwise exploit any Feedback, without compensation to Contractor.“

Of course, if the agreement includes confidentiality obligations, you should carve them out of the clause: “Feedback does not include Confidential Information, as defined in Section __ of this Agreement.”

This disclaimer has two advantages over the feedback license. First, it’s not based on a false premise: on the idea that the contractor owns the feedback and therefore can license it. So parties and courts shouldn’t have trouble interpreting it. Second, a disclaimer won’t create messy problems for the contractor. In a feedback license, the contractor licenses something to the company. It’s hard to say what, but the contractor will ever after have to worry about the rights it’s given up. What if it someday creates technology related to the feedback: has it lost the right to exploit the technology? With a disclaimer, the contractor isn’t giving up any rights. It’s just agreeing that the parties’ relationship doesn’t impose any restrictions on the company regarding the feedback.

To put it another way, a feedback license creates a set of vague and confusing contract rights that probably can’t be sorted out without litigation, if they ever matter. A disclaimer avoids the creation of contract rights. It ensures that everyone keeps the right we all enjoy to exploit whatever ideas we happen to hear (so long as we hear them legally).

—————-

—————-

Special thanks to Professor Eric Goldman of the Santa Clara University School of Law, whose pesky comments led me to write this post.

© 2011 by David W. Tollen. All rights reserved.

The good news is that you don’t have worry about ownership of feedback or other ideas. You don’t need a feedback license, and in fact, they don’t even make sense. In the United States (and most other countries), ideas belong to everyone—at least to everyone who hears them legally.

The confusion stems from a misunderstanding of intellectual property: from the belief that IP covers every product of the human brain. IP actually covers a very narrow set of brain products. To be considered intellectual property, an asset has to fit into one of the following four categories.

• Copyrights protect written expression. If your contractor or partner writes down an idea, he may have a copyright in the writing. In other words, he may have the right to keep you from copying his words. But he can’t keep you from reading those words and using the idea they describe. You can even write up the idea in your own words (provided your words are truly original).
• Trademarks protect brand names, slogans, logos, and other words and symbols that distinguish commercial offerings. Trademark rights belong to the person or company that uses the mark in commerce (among other requirements), not to the person who developed the idea for the mark.
• Trade secrets law actually can protect ideas, but only “stolen” ideas. The law forbids use of a business secret by someone who got the information without authorization or through a confidential relationship. If a contractor or partner tells you her idea, without an NDA, it’s obviously not a trade secret.
• Patents protect products and processes, not ideas. To get a patent, the would-be patent-holder has to invent a product or develop a process (and that’s only the first step). A mere idea for improving your product or service doesn’t qualify.

Of course, it’s always possible someone will invent a real product or process that improves your offering, then file a patent application, struggle through the Patent and Trademark Office, get a patent, and block you from using the invention. But that’s a risk you can’t avoid. And your partners and contractors aren’t any more likely to file that patent than anyone else—unless they have the advantage of secret information about your offering. In that case, you should consider a nondisclosure agreement, not a feedback license. An NDA will forbid filing a patent application based on your secrets.

In any case, a patent won’t (or shouldn’t) issue for an obvious improvement to your product or service: for something you could easily have thought up yourself. You don’t have to worry about your contractor saying, “Hey, why don’t you add a flange here?” and then running off to the PTO. That’s not patentable.

So you don’t need a feedback license. Nor should you rely on a feedback license to protect you. It’s hard to guess whether or how a court will enforce a broad, general license to ideas: to something the law doesn’t recognize as property. An NDA will protect you much better where you’ve got confidential information at stake. And if your deal really is about IP—your contractor’s doing R&D, for instance—you need something more extensive and more enforceable than a feedback license. For an R&D relationship, you should put together a development agreement with a detailed license or assignment clause, transferring IP rights.

[Since writing this post, I've posted an additional suggestion regarding feedback clauses.]

Can you lose your right to an idea? Yes, but only by signing an NDA or some other type of contract that says you won’t use it. If you don’t sign away your rights to an idea, it’s yours—and everyone else’s.

—————-

—————-

Notes:

• The Tech Contracts Handbook addresses feedback licenses in footnote 1 of Appendix 2, and IP in general in Appendix 2.

© 2011 by David W. Tollen. All rights reserved.

Almost everyone uses MS Word (there’s a monopoly for you), so I’m going to address Microsoft’s redlining system. In the newer versions of Word for the PC, you redline via the “Compare” button on the Review tab. In older versions and in Word for the Mac, you hit “Merge Documents” on the Tools menu. In older Word, it’s sometimes hard to figure out which doc the software will treat as the original and which as the revised version. Just look carefully and make sure the terms of the newer version appear as additions and deletions on top of the older one.

Here are six rules for good redlining:

1. Get to Know Your Redlining Software. If you’re not intimately familiar with the redlining feature of your version of Word, play with it. Run test redlines and study them. That’s worth more than a month of law school, and it costs less.

2. Don’t Create a Redline on Top of a Redline. Redlining works best when it’s two-dimensional: when you’re comparing two versions of a contract. Comparing three versions—comparing the current version to the last one and the one before that—will create a document too complicated to review. Yes, you might try and simplify a “triple redline” by assigning different colors to different versions, but that rarely leads to a legible comparison. Plus, you don’t gain much by comparing three versions. In most contract negotiations, nothing matters but the difference between the last version and the current one. So when you’re drafting, don’t use the “Track Changes” feature to add your redlined changes on top of the other party’s redline, creating a comparison of three docs. (See point 5 below re Track Changes.) Work on a clean copy of the other party’s last version. Or use the other party’s redline but go through and accept the changes you like and reject the ones you don’t, using “Accept” and “Reject” buttons in Word (near the Merge Documents or Compare button). By the time you’re done accepting, rejecting, and otherwise revising, you should have a clean copy with the language you want and nothing from older versions. Then run a redline comparing that to a clean copy of the other party’s last version.

3. Don’t Read Triple Redlines. Along the same lines as point 2 above, don’t get yourself confused trying to read a triple redline: a redline that compares three versions. Instead, run your own redline, comparing the clean copy of the other party’s revised version against your own last version. Or if the other party didn’t send you a clean copy, just hit “Accept all Changes” (near the Merge Documents or Compare button) to create a clean version of the other party’s work. Then run a redline, comparing that to your last version. (I sometimes circumvent the whole problem by sending my redline as a PDF, alongside a clean copy in Word. That way, the other party can’t edit the redline—can’t create a triple redline—and has to work off the clean copy.)

4. If You Have Doubts about the Accuracy of the Other Party’s Redline, Run Your Own. You’d be surprised how often the other party sends me a redline that doesn’t match the other party’s clean copy. For instance, my proposed indemnity clause gets deleted from both the clean copy and the redline, but the deletion isn’t struck through in the redline. The language is simply missing, so if I’m just reviewing underlined additions and struck-through deletions—which is the whole time-saving point of a redline—I won’t notice the change. In almost every case, the problem results from carelessness rather than dirty tricks, but that won’t help you if you sign the wrong terms. You can avoid the problem by running your own redline: comparing your last version to a clean copy of the other party’s new one. And again, if you don’t have a clean copy of the other party’s new version, hit “Accept all Changes” to create one.

5. Don’t Rely on “Track Changes.” MS Word’s “Track Changes” feature redlines as you revise a document. Track Changes works fine for limited revisions drafted quickly, like in a single sitting. But it doesn’t create a clean version of the contract, and it can get screwed up if you’re reworking the same language over and over. In general, I recommend that you avoid Track Changes. Instead, create a clean new version of the contract and then run a redline against the old version.

6. Change as Little as Possible. A redline draws the other party’s attention to every change you make. So the less you change, the more reasonable you’ll seem—and the less work you’ll impose on the other party. If you want your negotiation to move along quickly, don’t change anything that doesn’t really matter. Some grammatical errors impact meaning, but many don’t. The same goes for run-on sentences, poor construction, passive language, and all the other boogeymen haunting the legal world. Avoid them in your own drafting, but don’t fix them unless they impact the contract’s meaning in a way that hurts you. We’re creating a business tool here, not a work of art. The fringe benefit is that a light redline will make the other party happy, and happy negotiators tend to be flexible.

The confusion, of course, stems from the central role of “software” in software as a service. You can cut through the confusion by asking what the customer will do with the software. If the customer puts a copy of a software application on a computer—downloads it, installs it from a disk, etc.—the deal calls for a license. Copyright law gives the software’s owner a monopoly over the right to copy it (to “reproduce” it), so the customer needs a copyright license to make a copy and put it on a computer. But in a SaaS deal, the customer doesn’t put software on a computer, or copy it at all. The software sits on the vendor’s computer and the customer merely accesses it via the Internet. With no copies, copyright plays no role in the transaction, so the customer doesn’t need a copyright license. Rather, the customer needs a simple promise: “During the term of this Agreement, Vendor will provide the System to Customer.”

In other words, the customer gets a service in a SaaS deal, not software. The vendor just uses software to provide the service. The vendor operates like an Internet service provider (ISP). Earthlink and Comcast and other ISP’s use millions of dollars of software to give their customers Internet access. But they don’t give their customers copies of that software. Rather, they provide a subscription to the service made possible by that software.

The distinction has implications for several clauses in a SaaS agreement:

• The Main Transactional Clause: The customer should get a subscription, not a software license. The customer gets a right “to receive the Service” or “to use the System” so long as the subscription lasts. Of course, you can describe the vendor’s offering as “a license to the Service,” and lots of companies do. But that suggests some kind of copyright license, and it’s hard to predict what a court will do with it if the parties get into litigation. You’ll write clearer contracts—and keep things clearer in your own head—if you avoid licensing language. (See the notes below for sample SaaS transactional clauses.)

• Maintenance: You don’t need it! In a maintenance clause, the vendor agrees to fix problems with installed software and to send updates and upgrades, so the customer’s copy doesn’t fall behind those of other customers. In a SaaS deal, the customer doesn’t have a copy. The vendor keeps the software, and the vendor’s promise to provide it as a service already involves maintaining it, by definition. (But see below re SLA’s.) Plus, the customer has no copy to fall behind other customers’ copies and so no need for updates and upgrades. When the vendor updates the software on its computers, all customers benefit (in almost all cases).

• SLA: You should consider a service level agreement (SLA) for a SaaS contract. Most SLA’s address time-frames for fixing errors or minimum performance standards—speed, latency, etc.—or both. (See the notes below for sample SLA’s.)

• IP Indemnities: SaaS customers generally don’t risk suits about copyright infringement, including open source suits, because they’re not copying any software. So they usually don’t need indemnities against copyright suits. Of course, the flip-side is that vendors don’t face much risk if they grant copyright indemnities. Patent indemnities, however, can play a key role in SaaS contracts because the customer could get dragged into a patent suit, even without copying the software. Some vendors grant patent indemnities only, others grant broad IP indemnities, and still others grant no indemnity at all. (See the notes below for sample indemnity clauses.)

• Data Management & Security: Data management and security play a more important role in SaaS deals than in most software licenses. The customer’s sensitive data generally sits on the vendor’s computers, along with the software, rather than on the customer’s computers. That’s why many SaaS contracts include a data clause, addressing the vendor’s obligations for managing data and for keeping it secure. (Be sure not to use an NDA for data security! See my recent post on NDA’s vs. data security clauses. And see the notes below for sample data clauses.)

Of course, your deal may involve both SaaS and installed software. A SaaS vendor may provide its main offering online but also give customers a software application to install on their computers—something that helps the computer use data from the online service, for instance. Don’t let that confuse you. What you need there is a small software license agreement wrapped into the larger services contract. The license and its supporting terms should address the installed application only, not the software the vendor keeps on its own computers and uses to run the service.

—————-

—————-

Notes & Resources:

• For sample clauses, see the following resources on the Tech Contracts Chalkboard Contract Forms & Resources page: (a)  “Online Terms of Service, Software as a Service” downloadable form, particularly the transactional clause in Subsection 2(a); (b) “Indemnity” downloadable form; (c) and “Data Management & Security” downloadable form.
• The Tech Contracts Handbook addresses: (a) SaaS transactional clauses in Chapter I.F; (b) SLA’s in Chapter II.B; (c) indemnity in Chapter II.K; and (d) data management and security in Chapter II.I.

© 2011 by David W. Tollen. All rights reserved.

Like NDA’s, data security clauses generally prohibit intentional disclosure of sensitive information. But the similarities end there, and in fact three key differences create a chasm between the two:

1. Confidential Information vs. Electronic Data: A typical NDA or nondisclosure clause protects only a limited body of information. The “Confidential Information” definition might cover documents marked “confidential,” for instance, or defined types of information, like customer lists or source code. That makes sense for business secrets. But in a database holding mountains of information, you can’t separate the sensitive data from the rest. It’s not grouped into sensitive and non-sensitive documents. So the recipient has to protect everything: the whole database. That’s why information security clauses address broad swaths of data–like “all Company’s information in electronic form”–rather than well-defined “Confidential Information.” Also NDA’s generally exclude certain information from the “Confidential Information” definition. They don’t protect information already in the recipient’s hands at the start of the relationship, information received from third parties without an NDA, or information already exposed to the public. Again, that makes sense for business secrets, but it doesn’t work for private data. If you’re sitting on consumer social security numbers, you’ve got to protect them no matter where you got them and no matter what anyone else has done with them. That’s why data security clauses have no such exclusions.

2. Focus on Nondisclosure vs. Focus on Security: NDA’s and confidentiality clauses focus on nondisclosure. An NDA says, first and foremost: don’t (intentionally) disclose the information to third parties. It says nothing about efforts to prevent accidental disclosure or theft, except possibly, “Recipient will protect the Confidential Information with the same degree of care it uses to protect is own information of similar nature, but no less than reasonable care.” Data security clauses, on the other hand, focus on security. They require protections like encryption, locked cabinets, and passwords, and sometimes employee background checks, SAS-70 (or SSAE-16) audits, and reporting of leaks. Data security clauses also tend to require compliance with company privacy policies and with government regulations, like FTC, HIPPA, and GLBA rules.*

3. Duration of Obligations: Most tech-related NDA’s and nondisclosure clauses expire. After eighteen months or three years or whatever, the recipient can stop worrying about keeping the Confidential Information quiet. That’s because most business secrets lose their value over time in the IT world. But private data remains sensitive–not to mention legally protected–indefinitely. Plus, you often don’t know what’s on a corporate database, so even if you don’t think it includes private information, you may not now when it’ll lose its sensitive status. That’s why data security clauses generally have no end-dates (though in many cases the recipient can eventually reduce the burden by returning the data and deleting all copies).

Of course, you can address all of these issues by revising your NDA or nondisclosure clause: by adding data security provisions and removing inappropriate NDA provisions. But that’s a lot of work. Why not just start with a form that fits your needs? Also, by carving up your NDA, you’ll ruin it for its intended purpose: protection of business secrets. In many deals, you need to protect both business secrets and electronic data, and as we’ve seen, they call for different measures. One of the parties gets the other’s customer lists and source code, for instance, as well as access to its databases. In those deals, you need both clauses. You’ll draft clearer and more effective contracts if each clause serves its intended and separate purpose.

You may find it difficult to locate data security clauses because they’re newer and they vary more. Search on terms like “data security,” “information security,” and “privacy protection” in your favorite contracts database. And have a look at the “Data Management and Security” clause at the Tech Contracts Chalkboard contracts forms page–as well as at the data security chapter in The Tech Contracts Handbook.

—————-

—————-

Notes:

• The Tech Contracts Handbook addresses NDA’s in Chapter II.H and data security clauses in Chapter II.I.
• FTC, HIPPA, and GLBA stand for Federal Trade Commission, Health Information Portability and Accountability Act, and Gramm-Leach-Bliley Act, respectively.

© 2011 by David W. Tollen. All rights reserved.

The Delaware State Capitol, where they keep the General Corporations Law fresh and flexible.

Delaware’s nickname is “the First State” because it was the first to ratify the U.S. Constitution, in 1787. But the name could just as well apply to Delaware’s role in the corporate world. More than half of America’s publicly traded corporations are incorporated there, and so are countless privately held companies from all over the country. Many of these companies do no business in Delaware. They incorporate there because they like the flexibility of the state’s General Corporations Law. It gives businesspeople lots of options related to corporate structure and shareholder relationships, and it doesn’t impose a lot of minority rights or “good conduct” rules. Companies also like Delaware’s corporations court: the Court of Chancery. Since Delaware snatched the corporate law number-one spot from New Jersey early in the 20th Century, the Court of Chancery has been the nation’s most active corporations court. So it’s got a lot of institutional experience and a well-developed set of common law rules on corporate governance and shareholder battles.

In other words, Delaware is great for corporate law: for the rules governing company structure and shareholder rights. But those laws don’t govern IT transactions. Tech deals are commercial contracts, often with a healthy dose of intellectual property thrown in. So they’re governed by state contract law and federal IP law. Delaware has no special advantage in those areas.

If you insist on forum shopping in your IT deals–on trying to find the “best” courts and laws–you should consider California. The Golden State (or maybe the Silicon State) does the most IT-related business and so has the most tech-savvy courts and laws, just as Delaware has the most corporate-savvy courts and laws. (Note my bias as a California lawyer.) But I don’t recommend forum shopping. Among other issues, choosing courts and laws with no connection to your deal may invalidate your choice. If no party is based in Delaware or California or whatever state you choose, and no work related to the deal happens there, many courts will ignore your choice. So by getting tricky with your choice of law and courts, you’ve lost the chance to decide.

What, then, should you do about choice of law and courts? First of all, you should choose the same state for both in most deals. That way, if you ever go to court, your judge and litigators will be addressing the laws they know best. As for which state, I recommend the one with the closest connection to the deal. If you’re building computer systems in Georgia–or installing software there or whatever–choose Georgia law and courts. If your deal involves work in multiple states, choose one of them: ideally the one where the most work will get done. That state’s laws will be the most familiar to the businesspeople and lawyers involved in the deal, and its courts will be the closest to witnesses and evidence. You should only consider a different state if one of the parties is based elsewhere, or both are. (And I do mean based. For IT deals, it rarely matters where anyone’s incorporated.) A base of operations in Texas might mean the staff knows Texas law best, and in case of litigation, most evidence and witnesses can be found there. Plus, some companies insist on their home turf, and there’s nothing wrong with that (though the other party doesn’t necessarily have to agree).

In other words, your choice of law and courts clause should follow the same rule as the rest of your contract: keep it simple.

—————-

—————-

Notes:

• The Tech Contracts Handbook addresses choice of law and jurisdiction in Chapter III.E.
• The Delaware Department of State, Division of Corporations, puts out a good explanation for the dominance of Delaware corporate law, called Why Corporations Choose Delaware, by Lewis J. Black, Jr.

© 2011 by David W. Tollen. All rights reserved.

Not if the indemnity clause actually gets called into action. Let’s say the feared lawsuit happens: a third party plaintiff sues one of our parties or both. Which of our parties has to defend the other? The mirror indemnity clause says whoever’s at fault defends. But we don’t know who’s at fault, if anyone, because the suit just started. The court won’t decide fault until the end, if ever. And it’s not like we can look at the plaintiff’s complaint to tell us who’s at fault. Whether the plaintiff accuses both of our parties or only one, both will almost certainly deny any wrongdoing. (Surprisingly few defendants or potential defendants fall to their knees and confess.) So what happens? Each party demands that the other defend it per the indemnity clause, and instead of cooperating against the plaintiff, they probably end up suing each other.

In other words, it doesn’t work for each party to indemnify the other for the same type of suit, with fault determining who actually bears the burden. At least, it doesn’t work if the indemnity clause includes a defense obligation, which is typical in IT deals. Defense obligations kick in at the start of a lawsuit, but you don’t know who’s at fault until near the end, when the court rules.

In most IT deals, defense is the central plank of the indemnity clause. One party wants the other to hire lawyers and defend it against X, Y, or Z type of lawsuit. A distributor wants its manufacturer to defend it against product liability suits. A customer wants its vendor to defend it against patent suits about the vendor’s products. An IT vendor wants its customer to defend it against data leak suits by the customer’s users. Etcetera. In each case, the parties agree in advance that indemnifying party will take the costs, uncertainty, and other burdens off the other party’s shoulders. Well, that doesn’t work–you don’t remove the uncertainty–unless the indemnitor agrees to defend the suit whether or not it denies fault.

No one has to accept that obligation, though it may be a cost of doing business with the other party: take it or leave it. If a contracting party accepts the burden, it’s usually because the type of suit in question feels like a natural cost of its own business, but not of the other party’s business. Companies that license IP, for instance, often agree to defend IP suits about their products whether or not they’re liable–whether or not they’re at fault–because IP is their business, not their customer’s. And manufacturers agree to defend product liability suits against their distributors–regardless of fault–because product safety is the manufacturer’s business, not the distributor’s.

A mirror indemnity defeats the point. Instead of creating certainty by determining in advance who defends a suit, a mirror indemnity says either party might have to defend, depending on who’s at fault. That almost guarantees that neither party will defend the other because neither will accept fault.

A mirror indemnity could work if you leave defense obligations out. Then the parties could wait until the end of the suit to see who the court blames for the loss in question (if anyone), and that party can pay any judgments and maybe even reimburse the other’s defense costs. Of course, when you’re drafting that sort of clause, you have to figure out what happens if the case settles before a court rules on fault.

But that won’t work if defense is the number-one goal of the indemnity, as in most IT deals. So in most IT contracts, mirror indemnities don’t work.

—————-

—————-

Notes:

• The Tech Contracts Handbook addresses indemnities in Chapter II.K.

© 2011 by David W. Tollen. All rights reserved.