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.

Mergers & Acquisitions - Software Licensing in the Due Diligence Process

It's been said that 2010 is the year of M&A (LOL...again, there have been many years in the past that have also held that moniker) and having just seen a posting on LinkedIn on this topic reminded me that it's probably time to blog about it again (check out my earlier posting on this topic for additional information).



There are lots of things to be considered, but I'm going to focus on the company doing the acquiring for this posting - if you need other scenarios check out our whitepaper on the topic.



There are typically two scenarios in acquiring: (1) you don't acquire any of the IT assets, or (2) you acquire all the assets of the company, including IT assets. The first scenario is simple as you know walking in that you have to provide these assets yourself. The second scenario is where the waters get muddy.



If acquiring all of the assets, the assumption is typically made that all the software installed at time of acquisition is (a) properly licensed and (b) the license will transfer to the acquiring company. Unfortunately, these are both naive assumptions and too frequently incorrect.



In the ideal situation, IT would have the opportunity to receive the licensing statement (including copies of contracts and proof of licensing) for the company being acquired in advance so it could be factored into the valuation of the company (remember software is frequently the 2nd or 3rd largest line item in the IT budget and represents significant expense).



However; reality is that acquisitions are typically completed without IT's involvement or even if IT is involved they are very limited in the information that can be shared in advance of the completion of the deal.



So, how can IT help the company avoid acquiring someone else's licensing headache? Through education and quick follow up.



A couple of basic steps:

1) Get the issue on the table in advance of M&A activity. During M&A you're going to have a hard time getting the attention of the proper parties so preempt the situation.

2) Get some allies on the topic - legal counsel, CFO, compliance officer and purchasing officer are all key allies. Obviously this means senior level IT to senior level operations discussions.

3) Create a high level IT due diligence checklist of what IT truly needs to (a) help avoid large unnecessary costs and (b) ease integration post acquisition.

4) With the aid of your allies, get the IT due diligence checklist added to the overall company due diligence checklist. Be prepared for push back and be able to quantify through hard dollar and compliance risks the reason behind each item.

5) Post acqusition, work fast. Not only do you have a mandate to get the company integrated but you also need to ensure that if there are any licensing costs associated with acquisition that you're able to identify those for proper accounting in the financial statements as part of the acquisition cost.



Get help - understanding the licensing terms for each major publisher and the transferability of those licenses can be a daunting task. Now is the time to focus on integrating your two companies, have an expert handle the acqusition licensing issues for you.



Any other suggestions? Post them!

Mergers & Aquisitions - the importance of software licensing

I got a call the other day from a former co-worker. It appears that her new company had recently spun off from it's parent and in preparing for their software upgrade they got an ugly surprise...their former parent had never bought the software they contractually "transfered" to my friend's company. About $400,000 worth of software needed to be bought.

Knowing for sure about software licensing during Mergers and Acquisitions or any other type of change of control activity is extremely important.

Divestitures

When a company splits off from a parent company there is a lot to be figured out, including who gets the software.

If the company has only purchased OEM software then the software rights transfer with the machine – however; documentation is key. The onus of ownership remains with the company using the software.

If the company purchased retail software, will this be transferred to the new company? If so, physical transfer of the licensing agreements and records needs to occur as well. It would also be wise for the new company to insist on financial records showing the initial purchase.

If the company purchased under volume agreements (non-contractual), then the publisher needs to be notified of the transfer (transfer fees may be involved) and appropriate documentation needs to be retained by both companies.

If the company purchased software through a contractual agreement then there are additional considerations. Is the contractual agreement also covering any of the former parent’s software as well? In most cases it would be. Does the contract allow for separation or transfer of licenses? Is there a license transfer fee or notifications? Will either company still be of appropriate size to qualify for the contract?


Acquisitions

The last thing a company wants to do is acquire someone else’s software licensing nightmares. Ensuring that you receive full documentation of what you are paying for when you acquire the company and its software assets is key.

Additionally, a company that is acquiring another company generally has its own software assets already under various forms of contracts (or through acquisition a company might finally be of a size to qualify for a contractual volume agreement). Maintaining separate agreements or being able to wrap multiple agreements together is one of the items to be considered. Additionally, some contracts have language in them requiring a company to wrap acquisitions into an existing contract. It is important that a company be aware of any such requirements upfront so there are no costly surprises.

It's also important to know your rights. It's not unusual for software publishers to limit what rights can be transfered when a company is bought or sold.

If you need to know more, contact us through our website at www.cynthiafarren.com