By Christof Beaupoil, President and Co-Founder of Aspera Technologies Inc.
When it comes to Oracle licensing, the universal question is: Why do they make it so hard? The answer is simple: Because they can.
IT experts agree about three things:
In other words, this is Oracle’s world and you’re just living in it. From complex and inconsistent licensing rules, to ongoing acquisition and integration of unrelated vendors, business as usual at Oracle can make achieving license compliance a moving target.
When you decide to invest in Oracle, the success of your efforts truly depends on how prepared you are for the pitfalls. From the get-go, Oracle emphasizes upfront discounting rather than ongoing contractual flexibility. And once you’ve negotiated your agreement, maintenance fees tend to be steep, increase annually, and are notoriously difficult to negotiate down. In fact, more revenue is earned from maintenance fees and audits than from selling software licenses. And speaking of audits, customers are often red-flagged for audits based on otherwise “friendly” conversations with Oracle reps and surveys about purchasing habits.
Oracle offers two types of agreements: an Enterprise License Agreement (ELA) or an Unlimited License Agreement (ULA). Both have pros and cons, and both are equally daunting. The ELA defines license price based on your company’s revenue or number of employees, and an increase in revenue or staff will result in additional license fees. An ELA is a difficult agreement to negotiate and manage as your enterprise expands and contracts over time. A ULA, on the other hand, allows you to install as much as you want for one negotiated fee; however, this agreement is only “unlimited” for the specific products itemized in the agreement–so excellent internal communication is mandatory for avoiding unintentional, unlicensed installations. Furthermore when a ULA expires and is not renewed, a true-up must be conducted where the number of installs beyond the starting baseline is considered the “new” number of licenses you own, and therefore for which you must pay ongoing maintenance. So, the license agreement you have in hand today is likely not the one you negotiated two years ago.
In terms of licensing, Oracle’s products are not licensed by installation, but rather are tied to complex metrics, most commonly Named User Plus and Processor Based. These metrics consider how software is deployed across the number of users, as well as the type, manufacturer, and number of CPUs. Furthermore, “users” can include not only employees but also contractors, business partners, and devices. Named User Plus, or NUP, measures unique users that receive or create data from Oracle software, regardless of if the user is actively using the application. Many organizations shy away from the NUP metric because tracking users is so difficult. Processor Based Metrics consider all processors where Oracle products are running and/or installed, and are based on the core factor. The challenge is in knowing which one to apply because processors—regardless of manufacturer—have different core factors.
In terms of software, while Oracle does differentiate between “installed” and “running”, it is difficult to prove that packages are only installed and not used. In the case of Oracle Database, for example, it automatically installs with “management packs.” Therefore each installed pack needs to be licensed, unless you can prove the impossible: that the install was never used. To create the potential for more confusion, Oracle’s Honor System makes it all too easy to use packs and turn on features not covered by a current license, and associated applications using Oracle functionality actually effect the licensing requirement. Additionally, Oracle’s ongoing acquisition and integration of other vendors’ software increase the risk of non-compliance while driving up support fees. Organizations must constantly keep track of their usage so that administrators can preemptively uninstall unnecessary or unlicensed packs and/or configure features to “off.”
Having an effective, successful SAM program in the Oracle environment depends on an informed, organized approach. The first critical step is the discovery phase. Oracle software is highly secured and protected (i.e. through firewalls) so an advanced discovery tool (often agent-less) is required to gather all of the required data. The tool must gather data from multiple platforms, recognizing low level hardware details and physical and virtual mapping, and then feed the resulting data into a SAM tool.
Oracle is notorious for changing licensing rules without notice, and these unexpected changes often result in high financial risks due to expensive changes in the IT landscape. So your SAM tool must have a built-in catalog of licensing terms and entitlements and flexible architecture that can accommodate the seamless addition of ever-changing licensing rules, as well as automate metric calculations to determine the effective license demand. Finally, your SAM tool should be able to consider Oracle’s method of licensing the same product with two different metrics, and compare the license demand for each metric to identify optimized cost reduction strategies.
In short, your SAM tool must be able to keep in strategic lock-step with Oracle’s moving target.
Knowledge is power.