Diffusing an Oracle audit – PT II
The advice in my first post of this three-part series on mounting an Oracle audit defense, pointed to taking audits seriously, not to force the pace, and to take care with how much you rely on your SAM solution (you do have one, don’t you?). In this second post, I take a deep dive into the nitty-gritty of the audit process – at the heart of which lies your agreement with the vendor.
Gotcha 6 – understand every word
The devil is in the details. A trite and perhaps overused expression, but when it comes to licensing contracts, details are crucial for SAM managers. Unfortunately, the significance of the small print is too often underestimated. While I was at Oracle, the vendor won a case against a large customer that hinged on a single word in the contract. The misunderstanding of what to count – individuals or FTEs – cost the customer US $25 million.
Gotcha 7 – Beware OF VARYING conditions for the same product
Over a period of about 15 years, the Processor license metric definition of Oracle’s most widely sold product line – databases – changed at least 10 times, and possibly more. Before the hardware industry invented multi-core processors, the license metric was referred to single-core processors. When multi-core became mainstream, Oracle re-wrote its definition: to consider every core as a processor. That’s how they contracted it.
Oracle came under pressure from customers who deemed the new pricing model unfair, due to the variation in computational power from one chip manufacturer to the next. So, eventually Oracle introduced the core factor, weighting different products with values according to their processing capabilities – assigning the likes of Sun UltraSPARC with a value of 0.25, Intel Xeon with 0.5, and everything else not specifically mentioned with a default 0.75.
Which was fine until IBM came along with substantially improved POWER7/POWER8 processors. Oracle changed the processor core factor for IBM POWER7, to be an even 1. Oracle (and other vendors) are always playing catch up with new technologies, tinkering with their business models to ensure that pricing adheres to the principle that you pay for the added value of software.
Gotcha 8 – Use the notice period
When you receive an audit letter, your initial reaction may be to get through the process as quickly as possible. I would advise you to use the full notice period set out in the contract. This is not avoiding the issue, but common sense – you need this time to get your ducks in a row.
But, how much time have you got? What, for example, does the following sentence mean: upon 45 days’ written notice, Oracle may audit your use of the software? Such loosely written terms provide room for interpretation. Oracle may push you to start an audit within two weeks, but 45 days is nine weeks for operations conducted on a 5-day basis.
Take advantage of the fact that an audit may not interfere with your normal business operations. Acknowledge the receipt of the letter and tell the auditors you’ll see them in 45 business days.
Gotcha 9 – DEMAND an NDA
The auditors will not offer an NDA, and if you ask for one, chances are they’ll tell you not to worry as a confidentiality clause is included in the license agreement. But these clauses tend to be highly generic, they don’t specify what data is going to be collected, where it’s going, and who gets access to it. In today’s world of data leaks, cybercrime, and new EU regulations (GDPR) full disclosure is a must.
Oracle ships the information it collects from an audit to Romania for analysis. And my point here is not that Romania is any less secure than say Switzerland, the US, or the UK. But ask yourself these questions: Is it legal, for you as a company, to share your data with an unknown entity outside the country where you are incorporated? Do you want your data to find its way to Oracle sales, so it can be leveraged for cross- and upsell opportunities? Are you obliged to maintain control over your data or is it okay for Oracle to decide who gets to see it and use it?
Gotcha 10 – Audit the auditors
Before an audit kicks off, the auditors compile a spreadsheet detailing all your entitlements: known as the License Inventory report. Oracle has moved the team who compile the License Inventory report from Romania to India – which may or may not have GDPR implications. The report is not absolute; it is merely a reflection of the information stored the systems at Oracle.
The report doesn’t, for example, show the different products/components included in a specific license or metric definitions as contractually agreed upon in the past. Typically, the report is not a complete and accurate view of your agreements, particularly when it comes to licensing bundles and software products from recent Oracle acquisitions. And that’s a lot of products – 400-500 over the past four years. Oracle has a strategy of integrating its acquisitions at breakneck speed – within a month. Data is simply pumped into the Oracle systems, without proper validation, data that subsequently shows up in the License Inventory report.
It is the responsibility of the auditors to check the report with your entitlement against the real paperwork – that is to say, your contract. My advice is that you too carry out this task.
In the third and final instalment of Oracle gotchas, I will take a look at the data. In the meantime, why not read Snow’s eBook: 5 Ways to Cut Spending on Oracle Databases.