The conventional wisdom always seemed to be that agreeing not to hire your business partners’ employees could be an antitrust problem, but that it was OK to agree not to solicit them. That still seems to be permitted — albeit with significant restrictions and new recordkeeping- and reporting requirements — by the proposed five-year consent decree in the case the Justice Department brought against Adobe, Apple, Google, Intel, Intuit, and Pixar.

Section V of the agreed proposed final judgment allows “no direct solicitation” provisions for the following types of agreement — if they • have a stated sunset date, • are “narrowly tailored to affect only employees who are anticipated to be directly involved in the agreement,” and • identify the affected employees with reasonable specificity:

1. employment- and severance agreements for one’s own employees;
2. as reasonably necessary for mergers and acquisitions, investments, divestitures, and related due diligence;
3. reasonably necessary for contracts with consultants or recipients of consulting services, auditors, outsourcing vendors, recruiting agencies or providers of temporary employees or contract workers;
4. reasonably necessary for the settlement or compromise of legal disputes; or
5. reasonably necessary for (i) contracts with resellers or OEMs; (ii) contracts with providers or recipients of services other than those enumerated above; or (iii) the function of a legitimate collaboration agreement, such as joint development, technology integration, joint ventures, joint projects (including teaming arrangements), and the shared use of facilities.

Links:

• [Proposed] Final Judgment
• DOJ press release
• Apple, Google, Intel, other tech firms admit secret agreements to not poach employees, Silicon Valley MercuryNews.com

Feed enhanced by Better Feed from Ozh

PRECUT ™ NDA Downloads

• Two-way NDA form (free fillable PDF)
• Curator’s Notes for the NDA form (free PDF)
• Word document containing all PRECUT NDA clauses, plus numerous other NDA provisions that can be copied to a custom addendum (free RTF file)
• Confidentiality provisions adddendum — just the confidentiality provisions from the PRECUT NDA, for possible use with other agreements (free PDF)

Commentary

The PRECUT ™ Nondisclosure Agreement is a free, balanced, multi-purpose, customizable NDA, in the form of a fill-in PDF.

While of course no contract form can be one-size-fits-all, for many purposes the PRECUT NDA should be pretty much ready to sign as-is.

The Curator’s Notes contain extensive commentary, as well as many additional clauses that can be used to create a custom addendum.

Ask your lawyer whether you could save time and money by using the PRECUT NDA as the foundation for your next nondisclosure agreement.

This is the first of what I hope will be a series of ready-to-sign contract forms available under a Creative Commons license.

Comments and other feedback are welcome, especially suggestions for other types of contract that you’d like to see developed.

[ADDED 2011-04-02] Please take a look at my e-book for the Kindle or in PDF, “Signing a Business Contract? A Quick Checklist for Greater Peace of Mind,” with pointers to help you avoid inadvertently giving away the store or even landing in jail.

See also: (list is automatically generated)

• PRECUT free, balanced, curated technology contracts
• Confidentiality agreement (NDA) short-form starter draft and annotated long form
• PRECUT confidentiality provisions addendum is up

Feed enhanced by Better Feed from Ozh

If you’re an employee of a company, and you sign a company contract as just “John Doe,” you might end up being held personally liable for the company’s obligations. (If you’re the owner of the company as a sole proprietor, or the general partner of a partnership, you probably will be personally liable in any case.)

A better way to sign a company contract is to have the signature block:

• clearly indicate that it’s the company, not you personally, that is agreeing to the contract, and that you’re simply signing on its behalf; and
• stating your title.

The wrong way to sign a company contract

A better way

Further reading

• Protecting the Deal Professional from Personal Liability for Contract-Related Claims, by Glen D. West, of the Weil Gotshal firm.

See also: (list is automatically generated)

• Note-taking in meetings and phone calls: Three easy habits your lawyer will love you for
• Signing a business contract? Be sure your company title is in your signature line
• Clients seem to like Webcam video conferences, with on-line document sharing, better than traditional on-site meetings

Feed enhanced by Better Feed from Ozh

Chances are that at some point in your career, a lawyer — yours, or someone else’s — will want to review notes you took at a meeting or during a phone conversation. So thinking ahead to that possibility, whenever you take notes, you should routinely do as many of the fol­low­ing things as you can remember, especially the first three things, to increase the odds that a later reviewer will get an ac­cur­ate picture of the event. It will help you stay out of un­de­served trouble and save money on legal fees

1. Indicate who said what you’re writing down.  Unless you want to risk having someone else’s statements mistakenly attributed to you, indicate in your notes just who has said what.  EXAMPLE:  Suppose that John Doe says in a meeting that your company’s off­shore oil-well drilling project can skip certain safety checks. Re­mem­ber­ing the BP drilling disaster in the Gulf of Mexico, you don’t want anyone to think you were the guy who sug­ges­ted this. So your notes might say, for example, "JD: Let’s skip safety checks,"; if you omitted John Doe’s initials, it wouldn’t be clear that you weren’t the one who made his suggestion.
2. On every page, write the meeting date and time, the subject, and the page number. The rea­son: Your lawyer will probably want to build a chronology of events; you can help her put the meeting in­to the proper context by “timestamping” your notes. This will also reduce the risk that an unfriendly party might try to quote your notes out of context.
3. If a lawyer is participating, indicate this.  That will help your lawyer sep­ar­ate out documents that might be protected by the attorney-client privilege. EXAMPLE:  “Partici­pants:  John Doe (CEO); Ron Roe (ABC Consulting, Inc.); Jane Joe (general counsel).”
4. Start with a clean sheet of paper.  When copies of documents are provided to opposing counsel, in a lawsuit or other investigation, it’s better if a given page of notes doesn’t have un­re­la­ted in­for­ma­tion on it.  This goes for people who take notes in bound paper note­books too: It’s best to start notes for each meeting or phone call on a new page, even though this means you’ll use up your note­books more quickly.
5. Write in pen for easier photocopying and/or scanning, and also because pencil notes might make a reviewer (for example, as an opposing counsel) wonder whether you might have erased anything, and perhaps falsely ac­cuse you of having done so.
6. Write “CONFIDENTIAL” at the top of each page of confidential notes. That will help preserve any applicable trade-secret rights; it will also help your lawyer segregate such notes for possible special handling in the lawsuit or other investigation.
7. List the participants. Listing the participants serves as a key to the initials you’ll be using, as discussed in item 1 above.  It can also refresh your recollection if you ever have to testify about the meet­ing. If some people are participating in an in-person meeting by phone, indicate that. Indicate each participant’s role if isn’t ob­vi­ous or well-known – remember, you might know who someone is, but a later reader likely won’t.  EXAMPLE:  “Partici­pants:  John Doe (CEO); Ron Roe (ABC Consulting, Inc.); Chris Coe (marketing).”
8. Indicate the time someone joins or leaves the meeting, es­pe­ci­al­ly if it’s you (so that you’re not later accused of having still been there if something bad happened after you left).
9. Write down the stop time of the meeting. This usually isn’t a big deal, but it’s nice to have for completeness.

See also: (list is automatically generated)

• Clients seem to like Webcam video conferences, with on-line document sharing, better than traditional on-site meetings
• How to sign a company contract without incurring personal liability
• An oral understanding might not get you off the hook for a written contractual obligation

Feed enhanced by Better Feed from Ozh

In one of those smack-your-forehead moments, I realized that there’s an obvious fifth ques­tion to be added to yesterday’s list of four ques­tions that should be asked at every business meeting (which as a re­sult would now have the acronym GPPPA):

• Goals: What are we trying to achieve in this project or relationship, and why? [In some circumstances, Toyota's Five Whys drill-down analysis might be helpful.]

I’ve updated the original posting accordingly.

See also: (list is automatically generated)

• G-PP-AA: Five questions to ask at every business meeting you ever attend

Feed enhanced by Better Feed from Ozh

[Updated 2010-08-19] It’s been my impression that many business-contract disputes could be avoided if the participants would just talk with each other regularly about five things. This makes me think that in almost any business meeting concerning a project or re­la­tion­ship, it’s a good idea to ask about those five things, with the acronym G-PP-AA:

1. Goals: What are we trying to achieve in this project or relationship, and why? [In some circumstances, Toyota's famous Five Whys drill-down analysis might be helpful.]

2. Progress: What have we accomplished so far in achieving the goal(s)?

3. Problems encountered or anticipated: What if anything has gone wrong,and why? What could go wrong in the future? [The Five Whys might be helpful here, too.]

4. Action plans for the future: What is going to be done, by whom, when, to continue progress, and/or to address problems?

5. Assumptions: What are we implicitly or explicitly assuming, that might not be true?

This is just Management-101 stuff, to be sure. But it’s often over­looked, especially when things get busy or stressed.

That’s why, when I’m helping to negotiate contracts for on-going projects or re­la­tion­ships, I like to ask for a provision for periodic status-review con­fer­en­ces, with a reminder that these five G-PP-AA factors should be part of the agenda.

Here’s one version of such a contract provision, with extra para­graph­ing added for readability:

Notes:

• Some of this language isn’t strictly required, but is included to re­assure the parties that the provision isn’t going to be expensive or burdensome.  For example, under this language, if neither party ever asks for a status-review conference, none is required.  As another example, under clause 1, all conferences are by phone unless the parties agree otherwise.
• Clause 2 intentionally doesn’t require the G-PP-AA factors to be dis­cussed; the reminder of those factors should be helpful.
• Clause 4 provides for written minutes if requested. Meeting minutes can be especially important in documenting specific to-do as­sign­ments. Meet­ing minutes can can also help litigation counsel re­con­struct "what hap­pened, when, and why," if things go wrong.
• In clause 4, the term seasonably is taken from section 1-204 of the Uniform Commercial Code, which defines the term thusly: An action is taken "seasonably" when it is taken at or within the time agreed or if no time is agreed at or within a reasonable time.

See also: (list is automatically generated)

• A fifth question to ask at every business meeting you attend

Feed enhanced by Better Feed from Ozh

In making a sales pitch, it’s not uncommon for a software vendor to put together a non-working demo or mock-up of what the customer might see in the final, customized software imp­le­men­ta­tion.

Such demos can be great sales aids. But they can also give rise to fraud allegations if the customer later claims, "you never told us it was just a demo!"

Strange as it may sound, this does happen in real life; when tech proj­ects blow up, customers’ lawyers almost always look for op­por­tu­ni­ties to make fraud claims against the vendor. As Chris Kanar­a­cus reported in 2008 about the recently-settled Waste Man­age­ment, Inc., vs. SAP lawsuit:

"At that meeting, SAP AG executives and engineers represented that the software was a mature solution and conducted a dem­on­stra­tion consisting of what they represented was the actual SAP Waste and Recycling software," the complaint states.

The company later discovered [sic] that the software was a "mock-up version of that software intended to deceive Waste Management," according to the complaint.

SAP has admitted to this in "internal documents," the complaint states.

SAP also demonstrated the "fake software" at subsequent sales presentations, according to the complaint.

[Emphasis and extra paragraphing added.]

If you’re a vendor, you can easily give your lawyers ammunition to shoot down this particular type of fraud al­leg­a­tion: Clearly label every screen of your demo as such.

The label could read something like this, in a footer: Note: Some significant features shown in this demo are not currently implemented.

That kind of label could help dissuade the customer from making a fraud claim at all, or perhaps allow the vendor to move for summary judgment dismissing the claim without a trial.

Related posts

• Why the fraud claim is the lawyer’s weapon of choice in lawsuits over failed technology projects
• Why tech vendors should consider providing a written risk-factors disclosure sheet
• Vendors, consider a no-reliance clause for your sales contracts, to help forestall claims of fraudulent misrepresentation

Feed enhanced by Better Feed from Ozh

Last week I posted a call to negotiate limitations of liability, in complex contracts, on a risk-by-risk basis, and not as one-size-fits all.

Here’s another possibility to consider: Exclusions of consequential damages and damage-cap amounts don’t necessarily have to be carved in stone for all time. The parties could easily agree to vary them, either as time passed or as circumstances changed.

Consequential-damages example

Suppose that:

• A software vendor is negotiating an enterprise license agreement with a new customer for a mature software package.
• The customer has successfully completed a pilot project, but it hasn’t rolled out the software for enterprise-wide production use.
• Knowing how tricky a production roll-out can sometimes be, the customer is concerned about the vendor’s insistence on excluding all ‘consequential’ damages, whatever that really means.

The vendor might try offering to waive the consequential-damages exclusion during, say, the customer’s first three months of production use of the software, subject to an agreed dollar cap on the vendor’s aggregate liability for all damages — which might be a higher dollar amount than at other times, as discussed below. This approach could make the customer more comfortable that the vendor is ‘standing behind its software’ during the roll-out phase.

In theory, certainly, the vendor would be exposed to additional liability risk during those first three months. But the business risk might be eminently worth taking. Remember, we’re assuming that the software is mature, that is, most of its significant bugs have already been corrected. In that case, the vendor might be willing to take on that additional theoretical risk — which in any case would go away after three months — in order to help close the sale.

Damages-cap example

As another example, perhaps such a vendor could agree that the damages cap would be, say —

• 4X for any damages that arise during, say, the first three months of the relationship, or possibly until a stated milestone has been achieved;
• 3X during the nine months thereafter;
• 2X thereafter.

In the 4X / 3X / 2X language, X could be defined —

• as a stated fixed sum;
• as the amount of the customer’s aggregate spend under the contract in the past 12 months, 18 months, etc.;
• in any other convenient way.

* * *

The details in the above example aren’t important. The point is that sometimes ‘standard’ limitation-of-liability language is too broad to allow the parties to specify what they really need. Negotiators might have more success if they drilled down into the language — perhaps using the table approach discussed in the previously-cited post.

See also: (list is automatically generated)

• Negotiating contractual limitations of liability: Do it risk by risk, not one-size-fits-all

Feed enhanced by Better Feed from Ozh

Some lawyers seem to think that “cease and desist” and “demand” letters should threaten a lawsuit if the other side doesn’t do what’s demanded. It’s been my experience, though, that nothing good ever comes from explicitly threatening to sue:

• Your letter will not cause the other side to suddenly see the light and agree with your position, especially if there’s any uncertainty at all about who’s right. If anything, a threatening letter will often have the opposite effect. (Letters full of bluster always make me think of the screeching-apes scene at the beginning of 2001: A Space Odyssey.)
• Alerted by your threat, the other side might beat you to the punch by suing you — in a court you might have wanted to avoid — for a declaratory judgment that they’re not liable, sort of like the swordsman scene in Raiders of the Lost Ark.
• If you don’t make good on your threat, the other side will conclude that you’re all bark and no bite, which likely will make it more difficult to settle on terms you like.

The better course, I’ve found, is to write the demand letter as a courteous, professional-sounding business letter:

• Briefly describe the problem, in a factual, non-argumentative way — with enough details to educate the other side’s lawyer (your real audience) and keep the other side from later claiming that your notice was insufficient.
• Ask that the other side’s lawyer contact you as soon as possible to discuss the matter.
• If your demand letter is about a breach of contract, emphasize (if true) that your client wants to preserve the business relationship.
• Don’t even hint that you might file a lawsuit.

This won’t guarantee a favorable settlement by any means. But neither will it needlessly get in the way of one.

Feed enhanced by Better Feed from Ozh

The open-source community burst into song yesterday after a jury decided an important contract case involving open-source software. The jury found that, when Novell Inc. sold the source code for the iconic Unix operating system to SCO Group Inc., it did not sell the copyright(s) in the code.

If the verdict stands, it will be a huge relief to the open-source community: SCO won’t be able to continue to pursue copyright-infringement suits against vendors of the equally-iconic Linux operating system, which SCO claimed infringed the Unix copyrights.

You might be scratching your head about this. In buying Unix, SCO acquired an intellectual-property asset of global significance. How on earth could they have signed a contract that didn’t convey ownership of the key intellectual-property rights, namely the copyrights and trademarks? Did their lawyers screw up, or what?

Fortunately, Silicon Valley lawyer George Grellas has posted an explanation that makes sense of it all, sort of — it seems the problem was money.

See also: (list is automatically generated)

• Contractor includes GPL code in deliverable – customer has to publish its own source code
• Source code escrows usually aren’t worth the bother

Feed enhanced by Better Feed from Ozh