Thursday, June 30, 2011

Software Licensing Agreements - Enterprises Be Careful of What You're Signing!

I work with companies of all sizes so I see a lot of trends based upon size. One disturbing trend I've been seeing lately applies predominantly to my Enterprise customers who rely on their Procurement department to negotiate all contracts.

Procurement is a key player in any negotiation, but I think it's risky to rely completely on them for finalizing a software licensing agreement.

What may look benign to a Procurement expert may easily send off red alert signals to a licensing expert. Within the past month alone I have seen supposedly well negotiated language cost three of my newer clients over $5 million combined to a single publisher. While we can frequently get these agreements re-negotiated we were brought in after the publisher already had been made aware of the situation and their eye on the paycheck...hard to get much of a budge then.

Here are some examples:
1) Microsoft Enrollment for Application Platform (EAP). Sure, this offers great discounts on SQL server as well as other products but be sure to read the fine print! This enrollment commits the company to licensing all of their SQL deployments (or other product that is enrolled) through the EAP. If you own legacy licenses and are running legacy versions but you didn't enroll those licenses into the EAP with Software Assurance you are essentially giving up your right to that license for the term of the EAP. Even new licenses that you buy but don't buy through the EAP are essentially useless.

2) Audit or true-up assistance program clauses. Check these over carefully to make sure that the scope of any outside assistance is clearly identified and restricted to the appropriate products, divisions and terms. Also make sure that it doesn't provide restrictions that the underlying agreement doesn't dictate (such as the requirement to purchase maintenance, etc).

3) Downgrade rights. Not all software automatically has downgrade rights. Attachmate products for example frequently do not permit downgrade rights unless you procure maintenance. If your technical organization needs to run older versions of the software make sure your agreement provides for you to procure additional licenses but still run the version that meets the needs of your organization.

4) Definition of the Enterprise, entity, affiliates, etc. Make sure this definition fits your organizations needs. Signing an agreement that defines your Enterprise as being all "Knowledge Workers" for example, isn't necessarily a good fit if you have a large percentage of users who do not use the technology being licensed (for example, licensing all your "Knowledge Workers" for the Microsoft Core CAL when you have a significant percentage that are on Novell and Notes with no Microsoft interaction except the Windows Server CAL). By definition you would have to procure licenses that would never be used and cost far more than the license you do need.

While many of these apply to organizations of all sizes, I find that the small/mid-size organizations that rely more heavily on their IT or licensing staff to negotiate the contracts often catch these before signing (but yes, Procurement plays an important part so there may be many other costly mistakes these non-Procurement folks are making).

My recommenation - Procurement, make sure the final review process includes your internal Licensing Expert (if you have one) or your IT team (if you don't have one). Also, give some solid consideration to having an external expert review it - the price tag is very reasonable and the risks are extremely high.