Drafting Contracts

9 March

• Common issues on asset purchase agreement assignments
  • When you're really buying all the assets of the business (subject to specific exclusions), you don't have to come up with a schedule that itemizes everything. Just say "everything currently used in operating the business" or some such; maybe an "including but not limited to" clause.
  • The assignment's structure for the purchase price was intended to show that sometimes lawyers get things described to them in an excessively complex way. That is, you could just say "$500,000." Minus the excluded assets. Sometimes it's good for the client to see things put simply: it helps them appreciate what's going on.
  • When adjusting the purchase price to take into the account the assets not to be purchased, don't just say "the value" of the assets not to be purchased. You need to say how the value will be determined (i.e., appraisal process: each hire an appraiser and average the resunts, or some such). "Book value" is probably easiest in this case: the number at which the asset is reflected in the seller's financial statements. This isn't always satisfactory (it's basically cost-depreciation, except for real estate, which stays at the purchase price), but at least you can readily come up with it, and nobody will fight about it.
  • In real life, the seller would insist on some conditions for what assets get excluded. Some language to the effect that the buyer can only exclude things that they could reasonably conclude were unsalable or unusable.
  • The promissory note: both parties would probably always want the terms of that note to be hashed out in advance (i.e., is it interest-bearing, at what rate, any default or acceleration provisions, etc.).
  • Some folks created a definition for excluded assets; that was a good idea. But a few went on to describe the right to exclude them, and the time for doing it, etc.: that's really putting a substantive provision in the definition. Don't do that-- people won't know where to find it.
  • Typically the IRS will respect an allocation of the purchase price in an asset purchase agreement, because the parties' tax interests are at odds, so it's probably a wash as far as they're concerned.
  • A number of people had 1-entry outline lists. There's no need to make a 1-item list.
• Handout 1: Addendum to software license agreement
• Handout 2: Software development contracts and licensing agreements
• Handout 3: Amendments, Consents, and Waivers
• Handout 4: Master software license and services agreements
• Software licenses: we've all been licensees. Here, we're going to talk about custom licenses, not shrink-wrap ones. They are heavily negotiated: who can use? how many seats? what are the specs? etc.

  Typically, the technical and business people at the client have decided that they need some new product to help them in their business, and they create and send out an RFP describing what they're looking to buy.

  Proposals typically contain detailed claims about capabilities and so on. After proposal reviews (and maybe presentations), the customer will select a vendor. At this point, the client's lawyer gets called in: usually after the RFP and the presentations. That's a shame, of course, but it's typical.

  So you get the license agreement from the proposer, and your client says "can we sign this?" Begin the dance.

  Sometimes the purchase will involve both hardware and software. This will be the software side of the deal, though, and that's generally what the client wants to focus on: what can it do for their business.

  She differentiates between "system software" and "application software." Software is usually licensed, not sold (so the owner retains whatever trade secrets there are). Some licenses are exclusive, others non-exclusive.

• What kinds of issues do conventional agreements often present to the customer?
  • "We can't amend it:" even the form itself is hard to alter. It's a printed document, and unwieldy. And the sales people always say they can't deviate from this form.
  • Who the authorized users of the software are going to be. Shrink-wrap agreements are usually pretty restrictive here, but a negotiated agreement can be much more flexible: subsidiaries, parent companies, affiliates, contractors, etc.
  • Warranty protection. Generally all warranties are disclaimed (see UCC Art. II for language). Generally customers will at least ask for a warranty of title. Maybe merchantability and fitness for a particular purpose. Possibly a warranty that it will operate in accordance with specifications in the proposal. Maybe a warranty that it's compatible with some specific hardware, or that it doesn't infringe upon patents, copyrights, trademarks, or trade secrets of a third party, and we'll be held harmless if the software is ever found to infringe.
  • Term of the license: perpetual, annual, etc.? Support and maintenance also.
  • Delivery and acceptance of the software. Dates are often contentious: the customer wants there to be an incentive (liquidated damages, cancellation rights) for the vendor to perform on time. But acceptance is even more critical: acceptance of the software usually triggers the start of the warranty period, shifts risk of loss, starts support, triggers the payment of fees. Being able to withold acceptance is the only way that the customer can be sure that it is getting what it wants: once they accept, they've lost all bargaining power. So we want acceptance to be defined as when the customer indicates in writing that the software operates correctly within the standards of the proposal. Acceptance criteria should be as specific as possible: functional descriptions, performance benchmarks, etc.
  • Payment of license fees. Customers like staggered payments of license fees (part on signing of the agreement, and parts at project milestones, but with some significant portion witheld untill acceptance).
  • Maintenance, upgrades, support, future options, etc. Response-times for incidents, etc.
  • Source code escrow. Licensee typically doesn't need source, but it's required for updates, etc., and the vendor might go away. Be sure to specify what events trigger the disgorgement of the source code from the escrow holder.
  • Security of data (esp. for Internet apps). See Handout #2, p. 3.
• We're going to create an addendum to an agreement to try and change its terms. We will assume that we've been offered a printed-form license agreement. It can't just be cut-and-pasted, but we're just going to add some clauses at the end.
• See Chapter 7 in the course book (the first 3-4 pages on amendments and consents). There's also Handout 3. ¶ 4 is hereby deleted and the following ¶ is substituted in lieu thereof. That sort of thing.
• We have till end of day on Friday (5:00).
• Handout 5: Less vs Fewer.