Thursday, September 04, 2014

Microsoft Next Generation Licensing Agreement (NGVL and MPSA)

A light buzz is going around the Microsoft licensing world about the NGVL (Microsoft Next Generation Volume Licensing) and a new agreement called MPSA (Microsoft Product and Services Agreement). I mention both terms because many of the resellers I've talked to have often known that NGVL was available but thought the MPSA wasn't or vice versa.  This confusion should rapidly diminish but for now, find that it helps for clarification.

The NGVL and MPSA has been available for some time and the beauty of it has been that unlike the Microsoft Select Plus Agreement it allows for online subscriptions.  The bad part was that it didn't allow for Software Assurance purchases.

As of September 2, 2014 Microsoft now allows for purchases of Software Assurance under the MPSA.

It has been a long time since Microsoft has really created a new licensing agreement (the Microsoft Select Plus was in my opinion more of a re-write of the Microsoft Select Agreement) and frankly their offerings have changed substantially during that time so the old agreements were having to be "massaged" to work with current offerings.

Basically the MPSA has many pluses, but the contract language also leaves me very uncomfortable around certain areas - so if you're looking to update your Microsoft agreements take a good look at this agreement but be sure to read the contract carefully and negotiate terms you can actually live with.

The MPSA is designed to cover all products you buy from Microsoft; perpetual licenses, software assurance, subscriptions and services.  That's great and can really provide you with streamlined management but the problem is whenever you lump disparate products together the contract language can get messy.

For example, if you think of your classic "services agreement" and compare that to your "software licensing agreement" there are many things you will accept for packaged software (such as warranty) that doesn't fit what you would require from your consulting services agreement.  However; in this contract they are the same (but they did provide a way around it...you just have to make sure you're aware of it and follow through on it when you're executing the work orders).

Audit clauses have also been updated - this is a subtle change that has happened over the years in the Microsoft Master (Business or Services) Agreement taking out the wording that required them to use a major auditing firm in performing an audit...in my opinion this lays the ground for them to be able to use any Microsoft Partner to perform audits, I don't necessarily feel that change is advantageous to companies.

I'll be going into further details in a later posting but wanted to give an initial "heads up" for anyone thinking of either signing an MPSA or who's in the middle of determining their Microsoft licensing strategy and were unaware that there is a new player on the field that might offer them substantial benefits.

As always, if you are looking at your Microsoft licensing strategy or are considering signing a new agreement with Microsoft (or are being audited under an existing one) it's a good time to get some expert help from an independent third party. I live and breathe Microsoft licensing (I know...but what can I say - we love puzzles!) and am happy to help - contact me to find out how we can help you.

Thursday, July 17, 2014

Renewing Microsoft Software Assurance - Know the Implications


Upgrade rights are included but so are updated rule requirements

 A frequently misunderstood area of Microsoft licensing is knowing what rules apply when you are utilizing downgrade rights (the right to install an earlier version of the product under a newer license).
The version purchased determines the use rights regardless of what version is installed.

However; this gets a little more confusing for companies who maintain Software Assurance on their products.  For example if a customer bought a license for Microsoft SQL Server Enterprise in July of 2011 with Software Assurance (we’ll assume 3 full years of Software Assurance) they would have bought the rights to Microsoft SQL Server 2008R2 Enterprise (either per server or per processor) and enjoyed upgrade rights to later versions of that product. If they choose to run 2008R2 (or an older edition), then the 2008R2 rules would apply. If they choose to upgrade to 2012 then the 2012 rules would apply.

In July 2014 that customer will need to decide if they are going to renew Software Assurance.  As soon as they renew Software Assurance they are in essence refreshing the license version of all products with Software Assurance to the current edition.  Therefore, they would no longer get to leverage the rules from 2008R2 they would now have to follow the rules for Microsoft SQL Server 2014.

There are both advantages and disadvantages for customers but the important thing for customers to remember is that renewing Software Assurance has a licensing impact which should be considered so that you are not accidentally put in a position of being non-compliant.

Just one more thing to consider in your due diligence when determining what products to renew Software Assurance on at your next renewal.  Let us know if we can help!

Monday, January 07, 2013

Software Audits - Be Afraid...Be Very Afraid!

OK, so I know the title is a bit "doom and gloom" - but frankly I've seen too many companies over the years get seriously bitten during software audits because they didn't have a healthy respect for the risk when they first accepted the audit (and for the sake of this article...I'm calling it an audit any time you share your installation data with a publisher or anyone representing the publisher).

First, I do not recommend going through one alone. That would be like going to an IRS audit alone - there are far too many obscure rules that can come back to haunt you. Get professional help before it starts and keep that help around through completion...very few rules are "black and white" and you need an advocate on your side who fully understands the rules and can balance the publisher's interpretation of use.

Here are a couple of things to know before heading into an audit:
  1. Not all audits are the same - know when you have the right to refuse or limit and when you've already waived those rights.
  2. Make sure the scope is clearly defined - is it all subsidiaries, all geographies, etc.
  3. Require a project specific non-disclosure agreement (NDA) be in place with any third-party gaining access to your information and follow up at the end of the audit to require disposal of the records.
  4. Understand under what circumstances you'll be billed for the cost of the audit.
  5. Ensure that the audit is being conducted under the rules of your active agreement with the publisher and the pertinent product use rights for the products in use.
There are many more, but this is a start.  The ITAM Review has a number of useful articles on this topic that you should consider reading as well.

Pitfalls to be aware of to avoid audit problems:

The best possible situation is to avoid an audit altogether.  While this is becoming more and more difficult as publishers have realized that audits are a profitable activity that helps them meet revenue goals (most of the heads of software publisher compliance groups have revenue goals much the same as a sales group), there are steps you can take to reduce your chances of an audit.
  1. Regularly conduct your own audit. Know what you own, what and how you are using it. If contacted for an audit, be sure that your executive handling the conversation can speak knowingly and authoratatively on current usage by product and the timeliness of that data.  Software publishers don't want to throw their money away on an audit that is going to produce no licensing revenue. The more they feel that you already have things under control the less likely they are to require a full onsite audit.
  2. Watch your external access, make sure you are appropriately licensing clients, vendors and partners for their access to your computing resources.
    • If your customers are using your computing resources, make sure that you are covering that usage under the appropriate licensing agreement.  Most publishers have service provider agreements (Microsoft's SPLA or VMWare's VSPP program being two of the most common) allowing for you to host their products for use by others - there is a lot of gray area in determining when you need to license under these versus when you can use perpetual licenses so make sure you have a professional help you make this determination.
    • Licensing is typically entity specific. While everyone in my organization is licensed to use a Microsoft Windows 2012 server within my organization that licensing does not cover us for when we access a client's organization.
    • There are expensive ways of handling this and less expensive ways - having licensing advice when you're setting up access can help you avoid unnecessary costs.
  3. Minimize OEM and non-volume purchases. Frankly, publishers regularly mine their entitlements data on clients to determine inconsistencies for compliance issues.  If a publisher can't see a full picture of your purchases it can increase the chances of an audit.
  4. Keep your purchasing records. If you are still using the software (or it's successor if that successors licensing is based upon the original purchase), then you need to have ready access to your proof of purchase. Consider for example Attachmate the owners of some (current and) legacy emulation software.  They audit on a regular basis - can you demonstrate that you purchased the 50 copies of KEA or myEXTRA! that you still have running in your organization?  If not, the cost to buy new licenses can include interest based upon when the software was originally released.
  5. Pay attention to country of usage rules. Most publishers have some restriction on using software in a  country other than the one purchased.  Autodesk, VMWare and Microsoft (under the Open licensing program) all restrict usage across geographical boundaries.
  6. Understand transferability rules of licenses during mergers, acquisitions and divestitures. For example, Autodesk states that their licenses are typically not transferable and have the right to refuse a request for transfer, if they do accept the transfer they can require that subscription costs be added to the license.

Already in an audit:
Regardless of what stage the audit is in, get help.  Make sure you have someone working as your advocate that has experience in software audits, strong knowledge of the publishers current and historical agreements and product use rights and the frankness to give you an accurate picture of where you stand (this is not the time your management team wants anything sugar coated...they need to know the reality so they can prepare).

Double check everything the auditors present to you - math errors and mis-interpretation of product use rights and licensing terms are frighteningly common.