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.