Term Interrelationships

If you’ve been following along with us in the last month or so, you’ll have realized that the problem and complexity with software licensing isn’t the individual terms themselves, but rather the interrelated-ness and exchange that transpires when you want to cover yourself.

A change in one term, like assignment, might affect a change in the license grant (such as the license metric), which has an effect on the initial price… and probably the maintenance price too. Which creates anxiety on the part of the licensee (who has a constrained budget), and possibly on the licensor, too (especially if they have a limitation of liability clause that’s tied to the price paid and as the price goes up, so does their liability).

Net-net is that what happens next is a comedy of errors. Both sides’ increasing anxiety comes across as either trepidation/hesitance with respects to closing the deal, or anger as a result of increased pricing and risk. What almost never happens (and what would prevent this increased anxiety and anger response) is an honest disclosure of interests.

The truth with regards to software licensing, and all other contracts for that matter, is that it’s a gamble… a risk. Each side is doing everything they can to protect themselves from every conceivable angle. Three page software licenses from the early 90s are now 30 page behemoths – written to close every gap, every loophole, every eventuality. It’s just not possible. Risk is the only true eventuality and you can’t entirely escape it. The best you can do is to mitigate it, and be honest with yourself and the other side about those things that scare you the most.

If you work together, you’ll find a lot of common ground… and ways to balance risk with the possibility of reward.

Advertisement

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!

Keeping up with Maintenance Costs

I keep talking about contracts sitting in file cabinets and drawers and how you need to have some sort of contract management system to keep things organized. This isn’t, however, a tip just for the buyers/licensees… but rather it’s for everyone involved on either side of a transaction.

Take Maintenance costs, for example. Your average negotiated software license contains a provision for maintenance. Usually based on the initial cost of the licensed products themselves, to some percentage, this provision also usually allows the seller to increase the cost of providing maintenance over time, sometimes limited by a stated percentage. In the event of poor contract management processes, either or both sides can lose out (spending more or decreased revenues) if they don’t pay attention.

Let me use a simple example to illustrate. Say that in 2000, you licensed software for $100,000. Also, let’s presume that you agreed to maintenance costs of 20% of the price paid for the licensed software (ie: $20,000). So your first years’ bill will be $120,000. In 2001, the bill would only be $20,000, and presumably, the vendor would continue to invoice the licensee for $20,000 through this year (2007). Grand total? $100,000 in license and $20,000 * 7 ($140,000) in maintenance = $240,000.

Again, however, it’s never that simple. Maintenance costs increase as a result of inflation and other market forces. So back to the language we go, and let’s now add an escalator to allow the vendor the ability to increase their license fees by 5% per year (this percentage is completely contrived and does not represent the actual increase percentage of any particular vendor).

Now we have a different scenario. It’s still $100,000 for the license and $20,000 for the first year’s maintenance. But in 2001, the maintenance fee can go UP by 5% ($1,000), and it compounds each year by an additional 5% (rounding up to the nearest half dollar):

2001 – $21,000
2002 – $22,050 ($21,000 + 5%)
2003 – $23,152.50
2004 – $24,310
2005 – $25,525.50
2006 – $26,802
2007 – $28,140

Difference as a result of the 5% escalation? $30,980!

This may not seem like a huge amount… but what if the initial cost of the software was $1,000,000 as many can sometimes be? Or, what if the maintenance percentage is based on the “then-current list price” of the particular product (language which I wouldn’t recommend for licensees)?

And what if rather than 5% increases, the vendor is increasing it by 10% – contrary to the license fee? Do the people who pay the invoices in your organization have ready access to the agreements to confirm the agreed-upon amounts?

In all, it pays to be diligent – on both sides of the equation.