This Week on The Web 2009-08-16

The things that happened around the web this week – maybe you already read about them, maybe you need to again:

• RT @gtiadvisors: RT @AdvertisingLaw: Blog Post: Content Protection and Copyright http://bit.ly/1Q0CX
• New blog post: Confidentiality Exclusions versus Disclosures http://bit.ly/4qYdND
• Tech workaround could allow MS-Word sales to continue: http://bit.ly/haM2S
• If you buy/sell software, get your free copy of the Software License Risk Matrix: http://bit.ly/14AJ0E
• . @insurancecvg on Coverage Disputes over Data Breaches: http://bit.ly/zaK87
• RT @ManVsDebt: frugal misery… when people try to apply cost-cutting tactics in areas that have a high personal value: http://bit.ly/rUDJ3
• I have available time for a new client if anyone is looking for ways to save money on IT procurement-related spend. Give me a buzz for info
• You don’t get what you deserve, you get what you negotiate (@activegarage): http://bit.ly/vW2KU
• RE: @park3 Thanks Jay. I’m still not sure that the distinction you point out really changes the analysis. Even in a… http://disq.us/1szo
• Who do you think is the best negotiator? 10% say William Shatner. Seriously? http://bit.ly/tP1SA
• RE: @park3 I don’t know that there is a rule. In fact, after years of thinking about it, the only rule is that there i… http://disq.us/1sxz
• Microsoft software clampdown nets 11 firms (via ZDNetUK): http://bit.ly/fVRFs
• RT @gtiadvisors @taxgirl: http://bit.ly/rPlPd < Why I recommend negotiation experts over corporate lawyers.
• RT @skydiver: http://bit.ly/JetPass – all you can fly in one month on jet blue – $599. < Sourcing folks should watch how this plays out.
• RT @gtiadvisors @colleencunningh @CoreyVickers @BettyFeng CFOs ignoring supply chain risks http://bit.ly/qtgK8 < I knew it… crap.
• RT @drjimanderson: Classic Sales Negotiation Tactic – I’ve Got to Talk to My Boss: http://bit.ly/wYU4j < Power tactic, learn to respond
• RT @harrymccracken: Texas Judge tells Microsoft to quit selling Word: http://bit.ly/ybXzR < This doesn’t affect current owner/users of Word
• When describing calculations in contracts – SHOW AN EXAMPLE, it might save your butt later! (@ontechcontracts): http://bit.ly/NXrsr
• New blog post: Jeff Gordon Quoted on SpendMatters Today http://bit.ly/zPTbo
• Simon Cowell’s lessons in salary negotiation http://bit.ly/1Es4p
• Thanks to Jason Busch (@spendmatters) for an opportunity to talk about M&A wrt licensing deals: http://bit.ly/ANzzA
• RT @fscavo RT @rwang0 Hearing about how hard it is to leave some #saaS vendors. Automatic renewal may not be the way to go! < Same here
• Follow the Five Fundamental Skills for Effective Negotiation and this won’t ever be an issue: http://bit.ly/oKM7J
• RT @ontechcontracts 3-step way to ID contract contingencies: http://bit.ly/N7Ldu < I was just talking about this. Good article!
• RT @fscavo: Stupid contract clauses that hinder business partner relationships http://is.gd/2aOYc Good post by @Figliuolo
• RT @WieseLawFirm: Thoughts on developing leverage and why it’s important in negotiations: http://is.gd/2aE28 < I call it Power in the FFSfEN
• Privacy policies just got interesting in ME (and applicable to everyone doing anything online): http://bit.ly/FFtYn (HT to Deena Burgess)

Advertisement

Jeff Gordon Quoted on SpendMatters Today

Today’s edition of SpendMatters discusses merger and acquisition issues as they relate to software licensing.  Jason Busch was kind enough to seek my opinion on the matter and through my long and winding response, he pulled out the best nuggets.

At the end of the day, the time to think about M&A-related stuff is when you’re entering into each relationship… not when the vendor announces they’re getting bought or sold.

License Resale

Vinnie Mirchandani at deal architect pointed out a Ray Wang article on the resale of unused licenses.  My thoughts are in the comments on Ray’s article.  But generally speaking, regardless of what Ray suggests, you can’t do it in the US (or the rest of the Berne Convention countries) under most licenses which have express prohibitions against it (you can almost always contract away your rights).

And, even if you could, your organization probably doesn’t have tracking enough to make it possible – just remember that if you overuse your permitted license count, chances are there’s another provision in your license that allows the vendor to charge you (perhaps at non-discounted pricing) for the overage.

What I DO like about Ray’s suggestion is that idea that you should try to negotiate for a recapture of maintenance fees on unused licenses.  If you can’t resell them, the least you can do is take an annual count and only pay maintenance on the ones you’re using.  There is, of course, trouble with this thought, too – as there are some vendors that used to allow this (the last one I remember was Autodesk).  But the trouble is that you can get into a situation where you only upgrade SOME of your licenses to the current version because not all of them are currently covered by maintenance and the upgrades provided under such program.

 

Assigning Software Licenses

Last week, we discussed Assignment, primarily as it relates to services-type work and the issues that come up in that particular arena. This time, we’ll add additional complexity by dealing with software license assignment.

[Note: the term “assignment” is used with respects to rights and the term “delegate” is used with respects to obligations. I will use the term “assign” or “assignment” through this post for both, but when drafting actual contract language, keep both terms in mind.]

Recall that assignment is the redirection of all or some contractual right(s). Template language in most agreements prevents unilateral assignment, usually requiring the permission of the non-acting party to complete the act. For services-type work, it’s fairly common for subcontractors to do bits and pieces of larger agreements… and prime contractors do have a tendency to disappear sometimes. But when you deal with software assignments, the game changes. A lot.

Assignments with respects to software manifest normally in ASP and SaaS relationships. As discussed in this blog before, a service provider relationship for software works by allowing the service provider to have some sort of right to host the software. In some cases, this is done with assignment language, allowing the licensee to grant a service provider the right to host the software on behalf of the licensee during the ASP relationship. With SaaS vendors, however, this right is part of the license itself, as the vendor is the service provider.

Assignments of all rights, however, get a bit more sticky. Software vendors price and license their products based on the perceived customer value that the software brings to that particular customer. The vendors, however, can’t know this value explicitly, so they guess and create a price they feel is reasonable and one that will be paid by the licensee. Again, as discussed previously, we’ve seen that licensing metrics are used as a way to calculate that value.

A customer who assigns all of their rights to another party can mess up this calculation, especially where site-based or enterprise-type licenses are involved. The problem can most easily be illustrated by imagining a licensee with 1000 employees in a single geographic location obtaining an “enterprise license” to a particular software product. They’re charged a fee, created by the vendor, based on the number of employees at the time of the initial license grant – and based on an estimate of how large the company will grow over time. This wasn’t usually a problem. Until companies began merging like wildfire.

Today, that same 1000 person company could be acquired by a 10,000 person company. If the assignment language isn’t written appropriately with this in mind, the software vendor may have unwittingly granted an enterprise license that is now for 11,000 people rather than 1,000. As a result, language in software licensing is now adjusted by software vendors to remove the ability to assign (and fewer enterprise licensing schemes are used, too).

But customers do sometimes need the relatively-automatic ability to assign a contract as a result of a merger, acquisition or other transfer of ownership of the organization. Most contract boilerplate language allows for this. Software vendors who are granting site or enterprise licenses, however, should continue to remember that this could lead to the example situation above. Therefore, take the time to perhaps create a “carve-out” whereby an assignment due to this type of transfer would convert the license to a set number of users… or to a very specific geographic location. This still allows for the assignment, but doesn’t open the software usage floodgates.

Assignment and Transferability

Assignment is the ability to redirect an agreement (or a portion of an agreement) to another party for some purpose. In many situations, it’s a way to allow a third party the ability to perform some subset of contractual responsibilities (ie: a subcontracted electrician or programmer). In the case of say, a credit card cardholder agreement, it allows the issuing bank to act in your shoes to receive money, sue, etc. In other words, it allows rights and responsibilities to be “assigned” to another party.

Transferability, on the other hand, is the complete hand-off of an agreement from one party to another.

Language on assignment and transfer typically prevents an agreement from either type of movement, as both parties usually want the original party to perform all of their obligations (otherwise, wouldn’t you go contract with someone else if this partner couldn’t do what you wanted?). But just as typically, language is also present that allows either assignment or transfer with permission from the side not seeking the action.

Assignment and/or Transfer isn’t necessarily a bad thing. As per the examples above, there might be a great reason for a subcontractor’s performance of the work. Specialty skills, speed and cost all play into the selection and use of subs. What’s important, therefore, is an understanding of how, if you’re NOT the one seeking the action, to protect yourself and maintain the contract you originally had.

First, remember that your initial language is key. If you unilaterally allow for assignment or transfer in the contract, you won’t have the ability to prevent it later. This is one instance where it’s better to have to ask permission later, as situations can change over time.

Second, assuming that you have to grant permission, remember that you do not have to actually grant it, even if asked. Sometimes extra language is inserted to make it appear that you do, phrased as “such consent not to be unreasonably withheld”. This makes it sound as if you need a really great reason to say “No.” But the truth is that any “reasonable” “No.” is good enough. So if you think that the party accepting the subcontracting work isn’t of good quality, that’s reasonable. If you want to keep the original party responsible because they’ve had difficulty completing tasks already, that’s reasonable. In all, virtually everything can be formed into a good, reasonable reason as to why you’re saying “no”.

Third, if you DO grant permission, please put it in writing. Create an amendment to the agreement to show exactly “what for” and why you’re granting permission. Detail the specific scope of the permission (X may use ZCorp subcontractor to perform the invoice and billing tasks for the duration of and as contemplated by the Agreement). Notice that I also included a time component (“for the duration”) as well. Be as specific as possible… and include a way to revoke the permission in the event that the subcontractor/assignee does not perform work in a satisfactory manner.

Fourth, some contract professionals argue that it’s wise to have an agreement with the third party directly for the performance of services. To be honest, I’m not sure how I feel about the topic. Sometimes it seems necessary, sometimes it seems like overkill. If you have a great agreement with the prime contractor, for example, simply state in the Assignment Amendment that the terms of the prime must be “flow-down” to the subcontractor, AND state that while the permission may be granted for the performance of those certain activities, that the prime will continue to be held liable for failure to meet any goals, responsibilities or objectives listed in the Agreement. This keeps the original party responsible for the performance of their subcontractors.

Complete transfers of an agreement, however, are a little different… as it’s a replacement of the original party with a completely new party (which eliminates much of the ability to hold the original party liable for future failures by the new party). This means that if you perform any sort of background check or other due diligence-type activities with new partners, you should perform the same type of check on the proposed newer partner, as well. In fact, many organizations outright resist transfers except as a result of merger, acquisition or complete divestiture.

Next week, we’ll turn the tables about 45 degrees and talk about transfer and assignment from the software licensing perspective – which brings a whole new twist to the impact of the language.

Update: A well-respected colleague, Ken Adams, author of A Manual of Style for Contract Drafting, wrote to let me know that he believes that the use of the term “transfer” is not necessary. Rather, using the term “assignment” and then clarifying which rights are being assigned (none, some or all) would be the more appropriate contract language to use. For obligations, instead of rights, the term “delegate” would be used rather than assign. Thanks Ken. I learn something new every day!