What’s the Point of a “Termination on Bankruptcy or Insolvency” Clause?

Posted on December 9, 2013 by admin

Almost every contract drafted today contains a clause allowing for a party to terminate the agreement if the other party files for bankruptcy, is forced into bankruptcy by a third party (involuntary bankruptcy), makes an assignment for the benefit of creditors, becomes or admits to being insolvent or generally unable to pay its debts when due, breaches a covenant related to financial condition, ceases to do business, etc. This type of clause is commonly known as an ipso facto clause. Ipso facto is Latin for “by the fact itself,” and means that the occurrence of something is a direct consequence and effect of the action in question. The action is the bankruptcy or insolvency of Party A, and the occurrence is the right to terminate by Party B. This clause is considered “boilerplate” in most contracts, and is rarely negotiated (or even discussed). However, attorneys and business persons alike should be very careful in relying on the right to terminate in this clause, as it’s generally unenforceable.

State law generally governs whether a contract is enforceable or non-enforceable. However, one very big exception to that rule is the federal law governing bankruptcies (Title 11 of the United States Code, known as the “Bankruptcy Code”). One of the primary goals of federal bankruptcy law is to allow a debtor to reorganize their business. In order to do that, the Bankruptcy Code overrides state enforcement of ipso facto clauses and invalidates them (in most cases) as a matter of federal law. Section 365(e)(1) of the Bankruptcy Code states that an “executory contract” (i.e., a contract where there’s still performance obligations outstanding) may not be terminated following commencement of bankruptcy solely because of a termination right based on the insolvency or financial condition of the debtor at any time before the closing of the bankruptcy. In other words, you generally can’t exercise an ipso facto clause under federal bankruptcy law once a bankruptcy starts, no matter what the contract says. (Another clause, Section 541(c), states that a property interest becomes property of the estate upon commencement of bankruptcy, meaning that the property interest can’t be terminated by an ipso facto clause.) Once bankruptcy starts and while it’s underway, only the trustee of the debtor can assume or reject an executory contract – it’s out of your hands.

Ipso facto clauses have remained in agreements through the years even though they’re no longer very useful, like a contract’s version of a human appendix. There’s actually a few good reasons to keep them around. It’s important to remember that the clause’s unenforceability under federal law is tied to the actual commencement of bankruptcy; if that never happens, the clause is still enforceable, or at least potentially usable as a saber that can be rattled. (Keep in mind that if you terminate under the clause and then bankruptcy is filed, the debtor may try to petition the court to reinstate the agreement and rescind the termination, similar to a “preference payment.”) There are also a couple of limited exceptions under Section 365(e)(2) of the Bankruptcy Code, such as where applicable law excuses the other party from accepting performance (whether or not the contract prohibits or restricts the assignment or delegation), and that party doesn’t consent to the assumption or assignment, e.g., the debtor is was commissioned to paint a mural based on his expertise – the building owner doesn’t have to accept the trustee’s paint job as a substitute. Finally, it’s always possible the Bankruptcy Code could be changed in the future to allow for the enforcement of ipso facto clauses under state law, perhaps through an expansion of the exceptions under Section 365(e)(2).

Representations, Warranties and Covenants

Posted on November 19, 2013 by admin

Many attorneys use representations, warranties and/or covenants as a single grouped concept, e.g., “represents, warrants and covenants” or “represents and warrants.” Some tend to view them as synonymous terms. However, they’re not meant to be interchangeable – each is separate and distinct from the other, has different temporal characteristics, and has different remedies. Understanding the differences between them and using them appropriately can be important to ensure that the right remedies attach to the right terms in an agreement. Using these terms properly also helps attorneys be as clear as possible in their agreements, which can be very important if non-attorneys are reading or reviewing them.

Representations are statements of past or present fact or circumstance. It’s a contractual statement that a fact or circumstance is presently true, and/or has been true in the past. An example of a representation is “the execution of this Agreement does not conflict with any obligation to which the party is currently bound.” This is a present statement of fact — signing the agreement by that party will not result in a breach of another agreement. Representations are generally included in an agreement to induce a party to enter into an agreement in the first place (without representations as to certain present circumstances and/or past facts, the other party wouldn’t execute the agreement), and are either true or not at the time the representation is made. This is why breach of a representations gives rise to a remedy that breach of warranty or covenant does not – breach of a representation may give rise to a right by the non-breaching party to void the entire agreement, under such theories as fraudulent misrepresentation or fraudulent inducement to contract. The non-breaching party may be able to recover “rescission” damages to put it in the position it was in prior to execution of the agreement (e.g., repayment of fees paid). The damages available for breach of a representation is an important reason why using “represents and warrants” or “represents, warrants and covenants” too liberally can lead to unintended consequences.

Warranties are statements of current and future condition. It’s a contractual statement that a condition is, and/or will be, true for a period of time (often the term of the agreement). An example of a warranty is “the software licensed hereunder conforms in all material respect to its documentation.” This is a statement of current and future condition – the software licensed in the agreement are in conformance to the software documentation. The statement may be true at the time the warranty is made, but may be breached during the course of the agreement (e.g., if a maintenance release breaks something). In the event of a breach of warranty, the non-breaching party may be entitled to damages resulting from the breach, and in many cases a contract will provide for specific remedies in connection with a breach of warranty (e.g., commercially reasonable efforts to repair). However, unlike a representation, a breach of warranty does not give rise to a right to void the contract.

Covenants are promises of future action or inaction. It’s a contractual statement that a party will do, or will not do, something during a period of time (often the term of the agreement). An example of a positive contractual covenant is “Party A shall issue a press release announcing the relationship within 30 calendar days of the Effective Date”; an example of a negative covenant is “Party A shall not issue a press release or make any public statement regarding the terms of the Agreement during the term of this Agreement.” The action or inaction will occur in the future, not at the time the covenant is made. In the event of a breach of a covenant, in addition to damages for breach of contract, if the covenant is material enough it could excuse the future performance of the non-breaching party (e.g., the breach of covenant frustrates the purpose of the agreement such that continued performance no longer matters). Further, unlike the breach of a representation or warranty, the breach of a covenant may give rise to injunctive relief.

Feedback on feedback clauses

Posted on October 30, 2013 by admin

A feedback clause generally gives a party a right and license to use ideas, comments, suggestions or similar feedback provided by the other party. Companies that offer products and services like these clauses because they allow the company way to learn information that can help them continue to improve their offerings. The standard argument in support of this type of clause is that it’s important to a product or service provider to ensure that simply discussing products in development with a client does not jeopardize their ability to use information they learn during that discussion. While that’s not unreasonable, there are a few different flavors of feedback clauses – the taste depends on which side of the fence you’re on.

As noted above, a typical feedback clause gives a party defines “Feedback” (e.g., any ideas, comments, suggestions or similar feedback provided by one party to the other); indicates that the provision of feedback is completely voluntary; and provides some grant of rights to the receiving party to use feedback. Think of this as the “base.” There are things you can “mix into” the base to change or enhance it, including a feedback trumps confidentiality provision, a feedback ownership provision, and/or a feedback warranty provision. If you’re on the receiving end of feedback, these mix-ins may be worth considering adding into a base clause. If you are on the disclosing end, these may be real causes for concern. (If you’d like a copy of my standard mix-in clauses, send me an email.)

Feedback trumps confidentiality. This mix-in states that any feedback provided, even if designated as confidential by the disclosing party, does not create any confidentiality obligation for the receiving party absent a separate written agreement, and the receiving party is free to use it the feedback without obligation or limitation. To the recipient, this ensures that any feedback can be freely used if provided by a recipient, regardless of confidentiality obligations under the Agreement. To the discloser, this can result in a “back door” around confidentiality.

Feedback ownership. This mix-in states that the disclosing party agrees to transfer all right, title and interest in and to feedback to the receiving Party. To the recipient, this ensures that they do not have to worry about creating derivative works of materials owned by a third party by using feedback. To the discloser, this can result in an inadvertent surrender of its own rights to any of its underlying proprietary information disclosed as feedback to a third party.

Feedback warranty. This mix-in is a warranty that the feedback does not infringe third party IP rights, is not subject to open source licensing obligations, and does not require payment of third party licensing fees. To the recipient, this can give some important protections if the recipient uses the feedback. To the discloser, this creates contractual representations for providing feedback, for which contractual damages may rise if the discloser breaches the warranty.

Here is my own base feedback clause where I represent MyCo (I flip this around and add in mix-ins on a case-by-case basis if warranted). It requires designation of feedback as such, and protects confidential information if inadvertently provided with feedback:

“The Parties acknowledge that MyCo may from time to time provide YourCo with ideas, comments, suggestions, or other feedback on the features or functionality of YourCo’s product offerings which is designated by the disclosing party as “Feedback” in writing on any written feedback, or contemporaneously with disclosure if disclosed orally (collectively, “Feedback”). The Parties agree and acknowledge that any Feedback is provided voluntarily by MyCo. In the event MyCo provides YourCo with Feedback, MyCo hereby grants to YourCo a perpetual, royalty-free, worldwide right to use such Feedback for the limited purpose of improving and creating derivative works of YourCo’s Products (notwithstanding the foregoing, the foregoing right shall not apply or extend to any portion of Feedback provided by MyCo which is MyCo’s Confidential Information, MyCo Technology or MyCo Materials), and the obligations of confidentiality set forth in this Agreement shall supersede and have priority over any Feedback usage rights.”

Finally, one of the most important things you can do regarding feedback is educate your business teams on what to watch out for when sharing feedback with a contractual partner – as in many areas, sound business practices can go a long way towards ensuring reliance on the legal language never becomes a necessity.

How effective is your contract’s Effective Date?

Posted on October 22, 2013 by admin

It’s usually one of the first things in an agreement – the Effective Date. The Effective Date is sometimes defined as a specific date, e.g., “This Agreement, effective as of October 21, 2013 (the ‘Effective Date’)…” In other cases, a contract becomes effective once signed by both parties. In that situation, most attorneys contractually define the Effective Date of an agreement as “the date last written below”, put a “Dated” line in the signature block, and don’t think twice about it. It’s worth a second look. The Effective Date can be critical to a company for a number of reasons, incuding revenue recognition and performance of contractual obligations tied to it.

In an era where exchanging signature copies or signature pages via PDF (or more rarely these days, fax) followed by an exchange of signed originals is more common, using “the date last written below” to define the Effective Date can have unintended consequences. In many cases, once the parties have exchanged signed copies by PDF, performance begins and they leave it to the contract administrators to follow up with originals if requested by one or both parties. But when the originals are signed by the parties, they can create a new Effective Date for the agreement. This is because of the integration clause in the agreement boilerplate – an argument can be made that the newly signed original version of the agreement supersedes the previously signed PDF version of the agreement, creating a new Effective Date.

For example, suppose you have an agreement where the initial term runs for 1 year from the Effective Date, subject to automatic renewal for subsequent 1-year terms unless a party provides notice of non-renewal at least 30 calendar days prior to the end of the term. Suppose the date of last execution by PDF was January 1, 2014, and the date of last execution of the originals was January 9, 2014. Party A is hoping for a renewal as the minimums under the Agreement double in year 2, but Party B sends notice of nonrenewal on December 4, 2014. Party A claims that the notice is invalid as improperly given, since it was received less than 30 days prior to December 31, 2014 (the end of the initial term). However, Party B claims that Party A is relying on the wrong Effective Date, and matinains that the correct Effective Date is January 9 (the date last written on the originals), and thus notice of non-renewal was properly given.

A few years ago, I made two changes to my contract templates to eliminate the possibility of this problem. First, I redefined the Effective Date as “the date on which this Agreement first becomes fully executed by all Parties hereto.” Second, I added two date lines to the signature block – “Date PDF or Facsimile Signed” and “Date Original Signed.” This approach ensures that even if originals are exchanged after PDFs, the date on which the agreement first became fully executed will be the Effective Date, and the signature block in the agreement will show clearly when a PDF or fax version was signed versus when an original was signed. This makes it easier for not only attorneys to determine the correct Effective Date of an agreement, but for contract administrators, business owners, and others to ensure that they are recognizing revenue, and tracking and measuring performance, under the Agreement from the correct Effective Date. By implementing a more robust definition of the Effective Date in an agreement, parties can ensure that what is often considered a standard term doesn’t become a point of contention later on.

Risk Management 101

Posted on October 11, 2013 by admin

Risk management is, whether actively or passively, an ongoing process at all levels of an organization, one that can lead a company down the path to prosperity or ruin. Any time someone asks, out loud or to themselves, “What if…,” “That could mean…,” “That might cause…,” “Have we considered…,”, or the like, they’re engaging in risk management. Attorneys, whether in-house or in private practice, practice risk management in their daily activities – the core of our job is to facilitate our client’s business objectives while managing legal risk (attorneys are often viewed as the “de facto” risk management group within an organization). Moreover, effectively managing risks can be a lot more difficult in practice than it sounds in theory. Fostering a culture throughout an organization that embraces, rather than shies away from, risk management (understanding what potential risks are, being able to identify them, knowing who should make risk management decisions, and making reasoned decisions) is critical to the success of any company.

At its core, “risk management” in the business and legal context can be defined as “the process of identifying, analyzing, and determining how to handle risks that may result from a proposed course of action or inaction.” In other words, it’s the process of weighing both the positive and negative consequences from any particular course of action in making business and legal decisions. I use the following in my business discussions to summarize the importance of good risk management practices: “It’s much easier to stop a snowball from rolling the wrong way while it’s still at the top of the hill.”

There are four core parts of risk management – (1) understanding what “risks” need to be managed, (2) identifying manageable risks during day-to-day business activities, (3) determining who makes risk management decisions, and (4) making risk management decisions. I’ll save a detailed analysis of each for a broader article, but provide an overview and some basic guidance here.

Understanding the risk. Risk management isn’t “avoiding all risk” – risk is an important part of business. (There is an old AIG slogan – “the greatest risk is not taking one.”) The trick is to manage risk to a level acceptable to the company. Every company has a different tolerance for risk – e.g., start-ups may be willing to take more risk than a well-established company. Understanding what risks must be managed and an appropriate risk tolerance level is something that senior management (with the advice and guidance of internal or external attorneys) must determine, and must re-evaluate over time as the company grows and changes. The main types of risks that companies face on a day-to-day basis are (1) revenue risks (getting the business versus lost opportunity); (2) precedent-setting risks (the slippery slope); (3) legal risks; and (4) operational risks (writing checks the company can’t cash).

Identifying the risk. If you remember anything after reading this, let it be this – you can’t make a risk management decision if you can’t identify and escalate the risk that needs to be managed. Many companies are equipped to manage a risk, but don’t have good processes or training on how to spot them in the first place. Company personnel – whether attorneys, sales team members, business owners, or any other employee, contractor, or advisor – must learn to spot risks associated with a proposed or ongoing course of action or inaction and escalate them internally (e.g., to their manager, to a designated risk management officer or team, etc.). Managers should be responsible for educating their teams on spotting and escalating risks, and this should be a core component of any corporate-wide risk management training.

Approving the risk. Once a risk has been identified, the next step is to determine the right approver of a risk management decision. One of the hardest aspects of an effective risk management culture is getting someone to make a risk management decision, which is why effective risk management approval structure is essential. Everyone is willing to take credit for a good risk management decision – no one wants to take the blame if the risk exposure actually happens. If people fear they’ll be “thrown under the bus” for bad risk management decisions (whether that person is the presenter or the approver), establishing a robust risk management culture is not going to succeed. Companies should consider assigning roles for approval of certain risks, discouraging/punishing individuals who do not follow the proper approval process, keeping good records of risk management approvals, and ensuring that individuals who make informed, well-analyzed risk management decisions aren’t thrown under the bus if the risk exposure ultimately occurs. (If proper risk management practices are followed, the realization of a risk exposure should not result in a “witch hunt” to find someone to blame, but should result in a re-analysis of the risk management decision to see if other “hindsight” data points would have affected the risk management decision and determine if changes to the risk profile of the company and/or risk management practices are appropriate.)

Making the risk management decision. There are four things a company can with an identified risk – avoid it (don’t take the proposed course of action or inaction); mitigate it (implement new processes, obtain insurance, or take some other action to control the risk exposure) shift it (make another party responsible for the risk exposure, e.g., through a contractual indemnity and hold harmless); or accept it (proceed with the action or inaction knowing what might happen). Each of these is a completely valid risk management decision, and they can be used individually or in combination once the identified risk has been evaluated (i.e., both the benefits and risks of a particular course of action or inaction should be presented to the appropriate decision-maker). There are only two “bad” risk management choices – (1) accepting the risk because of a perceived need on the part of the business to “act quickly” and not take the necessary time to evaluate and manage the risk, and (2) accepting the risk because the risk was never identified in the first place.

Thoughts on software escrow

Posted on March 11, 2009 by admin

All too often a business person comes to me and says “we need to include escrow in that agreement we’re working on.” Sometimes it makes sense, sometimes it doesn’t. Sometimes it can be more trouble than it’s worth.

If your company licenses a piece of mission-critical software, it’s your job as the attorney (read: the risk manager) to ensure that the licensor continues to support and maintain the software (e.g., by releasing bug fixes and updates) for the term of your license. That’s typically done by adding terms to the license to ensure that they will make updates available to you either at no charge or a mutually agreed-upon charge (e.g., upgrade fees for feature releases and no charge for maintenance releases, bug fixes, new releases which correct security issues or are needed to comply with applicable law, etc.), or by executing a separate maintenance agreement for the software that gives you all updates for a monthly or yearly fee. You’ll also want to ensure that you are entitled to software support from the licensor (email, phone, in-person visits, user conferences in Bermuda, etc.).

That’s all well and good, but it rests on a very important assumption — (1) the company stays in business, and (2) the company doesn’t breach the agreement and you terminate (thereby terminating the license), either of which could leave your company hanging high and dry. The solution most often suggested? Software escrow. (There are other protections you can implement as well, such as ensuring you have a perpetual license and ensuring you have 365(n) language in your license agreement, but those are topics for another entry.)

Software escrow is, essentially, a form of insurance. A third party (such as Iron Mountain, called the “escrow agent”) will hold a copy of the source code for the software and other related materials “in escrow,” and release it to a party (such as the licensee of the software) if certain release conditions (usually called “release triggers”) are met. This way, if a release trigger occurs, you (the licensee) can go directly to the escrow agent and request a release of the escrowed materials, without necessarily involving the licensor. If the software is released from escrow, the licensee can use the source code to continue to update and support the software.

The simplest way to address escrow is to add an escrow provision directly into the license agreement. At a high level, the typical escrow provision (if you are the licensee) should contain the following at a minimum: (1) agreement on who the escrow agent is, (2) agreement on who will negotiate the agreement with the escrow agreement and pay for escrow services, (3) agreement on what materials will be escrowed, (4) agreeent on the release triggers, and (5) agreement on the licensee’s rights to escrowed materials upon release (make sure this is pretty broad if you’re the licensee).

I’ll note a couple of important considerations when drafting an escrow provision:

Materials to be escrowed. I’ve seen too often where an escrow provision says that the source code for the licensed application will be escrowed, and that’s it. That’s going to make escrow pretty useless, and result in your ops team yelling at you later on (and if an escrow release is needed, you can bet that it’ll be a “fire drill” situation so nerves will be on edge anyway, and they may be looking for someone to throw under the bus.) You want to ensure that the software in the escrow is updated regularly to ensure that the escrowed version is as close to the current release as possible (say, every quarter or six months); otherwise, you could be left with a significant out-of-date version of source code released from escrow. You also want to ensure that the software that’s escrowed is tested by the licensor (i.e., that they’ve taken the source code, compiled it, and have verified that it works). Most importantly, you want to ensure that the escrowed materials include detailed instructions on how to compile the software to make it usable, and what third party tools are needed to compile and use the source code. Otherwise, escrow is pretty useless. You should also ensure that any open source tools used in connection with the source code are included in the escrowed materials, to save your team the trouble of having to go find them.

Ensure you have access to licensor personnel for help. If there’s an escrow release, the best way to ensure you can work with the materials is to get help, ideally from the licensor’s own personnel. However, if your contract has a nonsolicitation or non-hire provsion, you could be prohibited from contracting with them. You should ensure your escrow provision allows you to engage the licensor’s personnel for assistance with use of the escrowed materials.

One other very important thought here…you can’t escrow a service or environment. I’ve seen requests for software escrow for the codebase for a licensed ASP application or other software as a service used by a company. A standalone software application is one thing, but an outsourced environment is a whole another ball game. The source code is all well and good, but if you don’t have the ability to replicate the platform and environment in which it resides, the source code won’t be much help to you. If you’re really willing to go there (and it’s that mission-critical), ensure that the escrowed materials includes network diagrams, lists of third party software/hardware needed to replicate the environment, and all other materials your business and operations teams will need to make a significant go at replicating the environment in which the escrowed code will reside. You may also want to consider requiring the licensor to meet with your operations team to walk through how this would work, and provide documentation on this outside of escrow, so that your ops team can hit the ground running.

IP warranty, indemnity, or both?

Posted on March 4, 2009 by admin

Lots of agreements involving technology have both an express warranty of non-infringement, as well as a third party indemnity against non-infringement. For instance, if you’re licensing a piece of your company’s software to a third party, the third party might ask for both a warranty of non-infringement, as well as a third party indemnity obligation. Sounds innocuous enough, right? An easy give in the negotiation? Maybe not.

Think about what could happen if someone comes out of the woodwork and asserts an infringement claim against your client. They’ll most certainly tender the claim to you for indemnification. However, if you have an IP warranty as well, they could conceivably also assert a breach of warranty claim against you for breach of the non-infringement warranty. This could allow the other side to “double dip” on damages, seeking both indemnification and direct damages.

“Good information,” you say. “No more warranties, just indemnification.” Not necessarily. An IP warranty does something that the indemnity does not…for certain types of IP claims, it can give the recipient of the warranty an “innocent infringer” defense to a claim of infringement, as they would allege that their allegedly infringing behavior was in reliance on the warranty. So, what you can do is give the warranty (it should be a “to the best of its knowledge” warranty ideally), but specifically state that the sole and exclusive remedy for breach of the IP warranty is indemnification pursuant to the IP infringement indemnity elsewhere in the agreement. This gives your client the best of both worlds, while ensuring you’re protecting your client.

On the flip side, if you’re licensing software, you always want to request both an IP warranty and an IP indemnity, and if the other side gives you trouble, just explain why the warranty is needed in addition to an indemnity, and offer the exclusive remedy language to placate any “double dipping” concerns they may have.

Document protection in Word not so secure

Posted on February 12, 2009 by admin

Microsoft Word has this nifty feature called “Protect Document.” Basically, you can put in a password which prevents others who access the document from accepting or rejecting changes (but still allows them to make edits which show in redline). You can event set protection to allow only fillable fields to be edited, or to prevent someone from making any edits to a document entirely. (This protection is different from the password protection on opening a document.)

Many attorneys (and others) will lock a document, such as a nondisclosure agreement or a draft, with the “track changes” locked on. The idea is that by locking it, the drafter doesn’t have to go through the trouble of generating their own redline of changes sent back by the other side, which is often a good idea to ensure that no changes were “inadvertently” made but not marked in redline.

Microsoft’s dirty little secret, all the way back to the late 90’s when they released Word 97, is that the security mechanism for Word’s document protection is, well, bad. Really bad. In Word 2003 or earlier, you can get around it in 15 seconds by using Microsoft Script Editor to edit the script for the document and to remove the password entry, or even simpler, by saving a Word document in RTF (Rich Text Format), then closing it, reopening the RTF version, and saving it back into Word document format. Once you open the new Word version and click “Unprotect Document,” the password is gone and the document automatically unlocks. (You lose little if any formatting by converting it into RTF and back again.) You can do the same thing in Word 2007 by saving it from Word 97-2003 (.doc) format into Word 2007 (.docx) format, and then back again to Word 97-2003 format.

I use the Protect Document functionality to lock on “track changes” on almost every doc I send out. However, I’m sure to check to make sure that it comes back not only locked, but locked with the password I sent it out with. If you unlock it and it doesn’t have your password, it’s a sure bet that someone unlocked and then re-locked it.

So, if you rely on document protection in your Word documents, be warned…just because you always show your redlines when you prepare a revised version of an agreement, doesn’t mean everyone else will.

Notes from the Trenches

Articles, thoughts, tips, and tricks from an veteran in-house counsel

Category Archives: Legal