Get complimentary access to the latest Gartner® SAM & FinOps Research report.


Contract is King

Repeat after me, “Contract is King".

Imagine yourself at one of those seminars with a very charismatic speaker asking the audience to say “Contract is King”. Now I want you to imagine yourself as one of those individuals in the audience and to repeat this out loud at least five to ten times until it is fully embedded in your mind. If there is one piece of advice I can give you when it comes to Oracle license compliance, this is it!

As an Oracle customer, you’re likely doing your best to manage multiple types of software license contracts: license (governing), commercial (order), and support. All three of these contracts are instrumental when it comes to the proper management of Oracle software entitlements. In addition, this is generally one of the most confusing aspects of Oracle software asset management; understanding your entitlements and their respective agreements. We’ll explore the reasons why this is so important in greater detail below.

First, the license agreement, also known as Oracle License & Services Agreement (OLSA), Software License & Services Agreement (SLSA), and Oracle Master Agreement (OMA), will act as the governing document from which a number of transactional purchases will be made. You can think of the relationship between license agreements to commercial agreements as a one-to-many relationship wherein a number of commercial agreements, or orders, will be made under a specific license agreement. Further, an organization may have multiple license agreements further complicating the administrative responsibility of tracking Oracle assets. Generally, the license agreements will contain specific clauses in reference to Oracle’s audit rights as well as the customer’s obligations to cooperate with the audit. If you, as an Oracle customer, don’t understand what the audit clause says, you’re putting yourself at a disadvantage from the start. Moreover, you’ll find that when Oracle sends a formal audit notification letter, there is generally no reference to what license agreements Oracle intends to audit. Well, if you don’t know what license agreements Oracle is intending to audit, how do you know what your obligations are to Oracle as part of the audit? Further, how can you mitigate risk to your organization while still complying with Oracle’s audit request? It is vitally important that when Oracle asserts its right to audit your use of Oracle programs, you only comply with the obligations set forth in the respective Oracle agreement(s) and nothing more. Of course, it should also go without saying that, in order to comply, you will need to request that Oracle provide a list of the agreements it wishes to audit to ensure you comply in accordance with the respective agreements. If Oracle is requesting an audit, don’t be shy about asking for information that will help you prepare for the audit.

Second, your commercial agreement, also known as the order document, provides certain terms and conditions under which Oracle has granted you the right to use the software. Such terms and conditions may limit your use rights. As an example, we’ll reference the “territory” section and/or clause commonly found in Oracle’s commercial agreements. Many customers fail to understand that the Oracle software licenses do not generally grant worldwide usage and may be restricted based on geographical territories and/or political boundaries. Companies and organizations that operate globally will need to analyze such restrictions and assess whether such restrictions will increase license compliance risk to ensure that use is not falling outside of the license grant as specified in the original commercial agreement. As hard as it is to believe, this is such a common oversight that even those organizations who are actively managing their Oracle software licenses will find themselves out of compliance because of this one single issue.

Third, I find that most organizations manage their Oracle license entitlements based upon their annual maintenance and support renewals thinking that only those licenses that are actively supported should be considered as a full listing of all license entitlements. To some extent, that is true, and I’ll cover more of that as we explore Oracle’s Matching Service Level policy (found here and here), however, it leaves out one very important fact; most license entitlements are granted as perpetual licenses meaning you own them in perpetuity. So if Oracle is only providing insight into a fraction of your license entitlements, you are missing out on a substantial number of licenses which you’ve invested in and are not taking into account.

Lastly, a number of additional topics such as Partitioning, Proprietary Hosting, and Disaster Recovery/Data Recovery become very difficult for Oracle customers to interpret as each agreement (license, commercial, and possibly support) may have separate terms and conditions which you need to be cognizant of. It is not uncommon for Oracle auditors to provide or reference customer-facing documents (CFDs) or policy documents which, while helpful, do not speak to the specific elements of a contract and may fall outside of your obligations. Overlooking one of these can result in significant confusion at best and unnecessary license compliance shortfalls and additional unfunded capital expenditures at worst.

Be diligent, be aware, and repeat after me; “Contract is King”. 

Let’s start a conversation.