How to Contend with Oracle’s Many Licensing Policies
By Christopher Barnett
Scott & Scott LLP
It is common practice for software publishers to incorporate by reference various licensing rules and policies to govern the usage of the publishers’ software products. For example, Microsoft’s volume license agreements (such as MPSAs or Enterprise Agreements) incorporate Microsoft’s Product Terms, Online Services Terms and Service Level Agreement for Online Services (among other documents), with a specific references to those documents, indications of which versions of the documents will control during the term of the agreement, and the URL of the websites where current versions of the documents may be found. While Microsoft’s licensing terms occasionally can be somewhat ambiguous or difficult to apply, the documents incorporated by reference in its agreements are comprehensive and serve to reasonably define the parties’ respective rights, obligations and expectations regarding usage of Microsoft’s products and services.
Oracle takes a different approach, one that reasonably may be characterized as “hiding the ball” from its customers.
Oracle’s current, standard-form OMA and OMA Schedule P (governing software usage) does incorporate a number of documents by reference, including but not limited to:
(1) “Program Documentation,” defined as “the Program user manual and Program installation manuals,” available at: http://oracle.com/documentation
(2) Oracle technical support policies, also available at: http://oracle.com/contracts
(3) The Program-Related Service Offerings document, also available at: http://oracle.com/contracts
(4) Various program-specific documentation sets identified in the License Definitions and Rules section of Schedule P, also available at: http://oracle.com/contracts
(5) Oracle’s Processor Core Factor Table, also available at: http://oracle.com/contracts
(6) Oracle’s Application Licensing Table, also available at http://oracle.com/contracts
That list may seem fairly lengthy at first glance, but it is deficient in a number of respects, as follows:
Notably absent from the list is Oracle’s (infamous) Partitioning Policy, which currently is available here: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf .The Partitioning Policy also does not appear to be clearly identified at the http://oracle.com/contracts website that is referenced so frequently in the OMA.
The Partitioning Policy is a truly problematic document.
Schedule P includes the following definition:
“Processor: shall be defined as all processors where the Oracle Programs are installed and/or running.”
Schedule P then provides a number of program-specific rules for calculating the number of Processor licenses required for licensed servers. However, the basic definition above would appear to pertain to all of those use cases.
Oracle customers whose use of Oracle programs such as Database Enterprise Edition has been the subject of audit activity know all too well that Oracle’s License Management Services (LMS) compliance teams do not limit their reviews to a natural definition of what constitutes “installed and/or running.” Instead, LMS applies concepts described in the Partitioning Policy to vastly expand the scope of what most IT professionals would assume those words to mean. In particular, LMS uses the policy to support its contentions that only specific kinds of virtualization technologies (which notably do not include VMware) may be used to limit the number of licenses required in virtualized environments, and, absent strict adherence to those rules, that all physical processors on all physical hosts in a virtualization environment must be licensed to their full capacities for all Oracle products running anywhere in the environment.
Despite the fact that such a counter-intuitive and aggressive policy is nowhere expressly incorporated in the OMA, LMS typically insists on that interpretation, potentially upon pain of terminating a customer’s licenses or escalating to litigation.
While it is mentioned in Schedule P, the Application Licensing Table (ALT) is not really where Oracle says it is.
The ALT identifies and defines a number of licensing prerequisites and Oracle technologies that may be bundled with certain Oracle Applications (such as E-Business Suite). It is a critical document for understanding the scope of the licenses that companies purchase for those Applications.
However, when you browse to http://oracle.com/contracts, the ALT is not identified on the displayed page. Instead, the page contains links to a few policy documents, plus sub-pages where agreement-specific information may be found. Clicking on the link to the “Oracle Master Agreement” displays a page from which the ALT is conspicuously absent. To get to that document, it is necessary to click on the link for the Oracle “License and Service Agreement” (OLSA), which is a different kind of master agreement governing usage of Oracle products and services.
That kind of ambiguity regarding the location of incorporated terms may seem to be a minor issue. However, it nevertheless further complicates an already complicated licensing universe, and it also offers LMS yet another way to surprise Oracle’s customers with previously unidentified licensing requirements during audits.
Unlike Microsoft’s agreements, there also is no “version control” language in the OMA to identify which, specific ancillary documents have been incorporated into the agreement. That fact provides Oracle an excellent opportunity to change the terms upon little or no notice.
Oracle generally provides little or no meaningful guidance regarding how to avoid unexpected license exposure.
For example, in Microsoft’s Product Terms, each product typically includes a list of added-cost functionalities related to that product and the additive licenses that are required in order to support such usage. By contrast, there is nothing stated either in the OMA or in any readily accessible, ancillary documents that defines when a licensee of Oracle Database Enterprise Edition is required to purchase licensing for added-cost Database options, like Active Data Guard or Spatial and Graph. This is true even though those added-cost options are included with the default Database installation package and often require technical reconfigurations in order to avoid triggering a licensing obligation.
As a result, during an audit, LMS often will ask a targeted entity to run Oracle’s proprietary measurement tools to validate product usage, and the outputs of those tools will reflect usage of Database options or other, added-cost functionalities that target’s business teams never intended to use or knew that they were “using.”
All of the above confusion related to the basic structure and presentation of Oracle’s licensing rules again emphasizes the need for companies using Oracle products to consider engaging and periodically working with a knowledgeable, third-party Oracle licensing consultant. I consider those kinds of engagements to be a necessary cost of business for using Oracle’s products, and they need to be factored into financial models whenever companies considering making or maintaining significant investments in Oracle software.