Preface
Here at License Consulting we eat, dream and talk licensing 24/7. And we don’t hesitate to tell the world about all this ‘hard to find’ information. Truth is that none of our clients want to know all the thousands of details we know anyway. Their business is keeping their operation (and related IT systems) running. But, some deeper understanding about sofware license compliancy may be useful to anyone involved in the compliancy process of a company. And this basically always comes down to a few steps. It can be applied to EVERY software licensing contract and EVERY software vendor that I have encountered in the past 13 years that i’m in this business. Microsoft, SAP, IBM, Borland, Adobe, Symantec, Oracle, EMC et cetera. That’s why there might be a quite large audience for this kind of material, which is why this article is in English instead of Dutch. If you are one of the lucky purchasing managers who has unvoluntarily been appointed as internal software license compliance manager: This is your lucky day. Knock yourself out.
License Compliancy Handbook for Dummies
‘Compliancy’ is the name of the game! Yet… How to determine if one is compliant or not? Most of the aspects involved to determine this are simple (yet separate) facts, and can be determined by yourself. You only need to know what you’re looking for. By combining each set of information you’ll make a good start in finding find out if you are compliant or not. Take a good look at each step and not only read by try to understand why you should look at these principles:
1. FACT: Actual Software Deployment
You will need to know (somehow!) what software you have running. HOW you find that out doesn’t really matter: It can be done manually, by using sniffer software that uses an agent or whatever. In the case of Microsoft you’ll probably be looking for word.exe and so on. In the case of Oracle you’ll probably ask your Database Administrator. If you have thin clients you’ll take a look at a Citrix server or use a 3rd party tool that collects this information. The means are not really relevant, and there can be many. Only the result, your finding, is relevant. And they are a fact on their own: It’s not related to your license purchasing history, your IT budget or anything else. It’s a simple fact that you’ve found out. The truth. Will you be able to say: ‘I’ll bet my paycheck that this information is true and complete’? Good. Because that’s how you should approach this.
2. FACT: Actual Software Use
Now that you’ve found out what kind of software you have out there, there’s an important (yet sometimes optional) step to be made: And that is to find out if (and how) this software is being used. Note that this step won’t be taken if you’re audited by a software vendor…they’ll usually charge you for the unlicensed deployment of software, even if the software is not being used. Some vendors even back-date the support revenue that they’ve missed out on. But in this step there’s a big saving possible if you audit yourself pro-actively. Let’s say in the previous step you’ve found out that you’re having 115 installations of Microsoft Office 1003. But, results show that only 100 installations have been used by 100 users within the last 3 months. If you can save the cost of 15 (unused) installations by un-installing them, you’re going to save a lot of money. If your environment is a lot larger, there’s possibly a lot more to save. By quantifying the actual use of the Actual Software Deployment you’ve measured in the previous step you’ll find out a lot about potential savings. Especially for Oracle environments where savings can easily increase into 6 digit numbers. That is per year.
3. FACT: License Inventory and License Grant(s)
The next step is to take is finding another fact: It’s all written down in your contracts and/or license agreements. How many licenses are you entitled to use for each software, and for what language and/or version entitled? And (very often forgotten): What was being said about ‘Use’? Is this per Node, per Computer, per Developer, per Named User, per Device, per what else? And what does Node, Computer, Developer, Device etcetera mean? You must find this out. This states your right to use. And it’s always written down in your license agreement: Most of the times under the ‘User Definitions’ section. If you are not able to find all the documents, involve the software vendor and/or the partners that have been involved when you aquired the licenses. Check with your your finance department to find the invoices that are related to software. Try to find whatever you can find: It’s your own money (and ‘Right to Use’), so it’s worthwhile to look well.
Beware: In many situations people believe they know know what their contractual rights are. Or there is an ‘understanding‘ with their vendor’s Account Manager. If you do have such an understanding, it should be in your contract contract or it’s non-existing. Unlike a good red wine your ‘understandings‘ will not get better over time.
STOP!
Before continuing to the last (and the quickest yet most complex) step we urge you to take a look at the steps we’ve made just now. Thing is that when you start this in real life with step 3 and find out that you have 100 licenses, it’s very likely that you or someone else will interpret the actual use as 100. Or, round them up (or down) to 100. By doing so you’ll be lying to yourself, and you’ll be better off not to start this exercise in the first place. Anybody who approaces the steps in a different order than described here is very likely to be the victim of this self-fulfilling prophecy. Trust us, we’ve seen it many times before. To be objective: Don’t start with what you own (license grants). Always and only start collecting information about what you are really doing with software, not with how many licenses you are entitled to use. Be objective. Even better: Have the steps executed by different people or teams.
AND AGAIN: Step 1 and 2 have NOTHING to do with the information in step 3. Of course you’d like this information to match, but in fact they’re completely different in nature. One is contractual, the other is technical. Do you understand? And do you understand how important it is that you understand this? OK, let’s continue.
4. Compliancy
The last step is the compliancy question….that’s what this was all about in the first place. Now, if you’ve done the previous steps correct, this comes down to mathematics. If the use is 10, and the amount of licenses is 9, you’re only 1 license away from compliancy. In theory this is always the case, and in theory you can never go wrong. Unfortunately for you (or…fortunately for us, or we wouldn’t have a job to do) this is only applies in theory. Even if you are willing and able to do step 1-3 yourself:
FACT: You’ll need in-depth knowledge to be sure.
i. There’s many software vendors that offer you additional terms of use that are not included in your physical contract, but are made public elsewhere after you’ve signed the contract. You’ll really save money knowing this. Many things you’ll find in vendor websites. Great resources for example are the Microsoft Licensing website and the Oracle Software Investment Guide. But there’s a lot of other information around that you’ll need to do the math right.
ii. Many savings can be made by changing your infrastructure or amending your license methodology slightly. For example by re-locating your test environment to a different server. Or license a subset of a software bundle separately, depending on the break-even point.
iii. Using different operating systems or processors or even VMware) can increase productivity/scalability while saving many licenses: But you need to know if this is the case in your specific scenario.
iv. The future: How will your company change in the upcoming (forseen) years? How do you deal with versioning and provisioning? Are there any developments towards centralization or standardization? Depending on the situation this may greatly affect your way to solve any problems, or impact your purchasing strategy and licensing plan for the future.
If you know what your compliancy status is, there are many ways to resolve a situation where you have too few or too many licenses. It’s a 3D-Puzzle. In any case, just running out and buying additional licenses is always a bad idea.
Epilogue
The most important thing to do is knowing you’re looking for the right piece of information in step 1, 2 or 3. Otherwise you’ll always end up with an incorrect conclusion, as would we. We can only work with the information that you have made available to us, trusting that all the information is complete and accurate. This is why we greatly involve the clients to understand what information we need, and ask them to find it for us. This reduces the price of any consult, and increases the clients involvement and understanding for their specific situation. At the end of the day, step 1, 2 and 3 come down to ‘common sense’. The added value is in the interpretation when using all this information correctly.
If you’re a client, make sure you have a partner at your side who really knows what he’s talking about and understand what’s the true agenda of this partner. If that partner’s core business is selling network architectures or monitoring software (basically anything else but fulltime keeping up to date with the licensing industry) or simply says his business is selling volume contracts (and even does a compliancy consult ‘for free’): ask someone else who a) really knows that material and b) operates truely independent. It can make you save or spend a lot of money. And yes, once you know what information you should be looking for, you could do at least 75% of the job yourself and learn a lot in the process.
