Oracle LMS and GLAS Explained
Oracle Licence Management Services (LMS) is the internal Oracle division responsible for software licence compliance programmes. LMS initiates audit notifications, manages the data collection process, and produces the compliance findings that form the basis of Oracle's commercial claims. Oracle LMS operates separately from Oracle's sales organisation — though the two interact during settlement negotiations, often in ways that create commercial dynamics enterprise buyers can exploit.
GLAS — Global Licence Advisory Services — was the name given to Oracle's script-based data collection methodology, broadly used from approximately 2010 through the mid-2020s. The scripts themselves have been updated, rebranded, and are now more commonly referred to as Oracle LMS data collection scripts, Oracle licence review scripts, or simply Oracle collection scripts. For practical purposes, LMS and GLAS refer to the same operational programme: Oracle's use of scripts run in customer environments to collect deployment data.
"Running Oracle's scripts without independent review is like signing a contract without reading it. The scripts collect what Oracle needs to build its case — enterprises that review output before submission consistently achieve materially better outcomes."
The distinction that matters for audit defence is understanding who controls the methodology. Oracle's scripts are Oracle's tools, designed to collect data that supports Oracle's counting methodology. They are not neutral measurement instruments. Every enterprise that receives an Oracle audit data collection request should treat the scripts as the opening position in a negotiation about what the data says — not as a definitive measurement of licence compliance.
What the Scripts Collect
Oracle's data collection scripts are run by the enterprise (or by the third-party audit firm Oracle engages) against Oracle database servers and the hardware infrastructure on which they run. The scripts are SQL-based (querying Oracle database metadata) and shell-based (querying operating system and hardware configuration). The data collected falls into several categories.
| Data Category | What Oracle Collects | Audit Significance |
|---|---|---|
| Installed Oracle Products | All Oracle software components installed on the server, including database editions, middleware, and application server software | Determines which Oracle products require licensing; Oracle counts all installed products whether or not they are in active use |
| Database Options & Packs | All options and management packs that appear as active in the Oracle database registry, including Diagnostics Pack, Tuning Pack, Partitioning, Advanced Security, etc. | Options and packs are licensed separately from the database. Features appearing as "active" in the database registry are treated as licensed even if not intentionally deployed |
| Processor Configuration | Physical processor type, number of processor sockets, core count per socket, and processor family identifiers | Oracle applies processor core factor tables to calculate licence requirements. The processor family determines the core factor multiplier (0.5 for Intel, 0.75 for SPARC, 1.0 for others) |
| Virtualisation Environment | VMware vCenter configuration, virtual machine placement, VM-to-host mapping, vSphere version and features enabled | Oracle's virtualisation policy requires that all physical host processors are licensed if soft partitioning is used. This is the most frequently contested area of Oracle audit findings |
| User Counts | For Named User Plus licences: number of users with access to Oracle software, or the number of devices with access | Oracle requires minimum NUP counts (25 per processor for most products) and counts all users defined in the database, not just active users |
| OS and Hardware Details | Operating system version, hardware platform, server model and manufacturer data | Used to verify processor core factor table application and to identify whether Oracle VM or hard partitioning technologies are in use |
Methodology Risks and Common Overstatements
Oracle's audit findings systematically overstate licence requirements in several well-documented areas. Understanding these methodology risks before the scripts are run is essential — because challenging a finding after Oracle has built its commercial claim around it requires more effort than identifying and documenting the discrepancy before submission.
VMware Soft Partitioning
This is the single largest source of Oracle audit overstatement. Oracle's virtualisation policy states that VMware is "soft partitioning" — and therefore Oracle requires all physical processor cores on VMware hosts where Oracle software runs to be licensed, regardless of how many cores the virtual machine is allocated. Oracle's scripts identify which VMware cluster hosts Oracle VMs and calculates the full physical core count for all hosts in the cluster as the licensing requirement.
The challenge opportunity: Oracle's policy is a contractual term in newer Oracle licence agreements but may not be present in older agreements. Enterprises on older Oracle contracts may have a legitimate contractual argument that Oracle's VMware policy does not apply to their licence position. Additionally, Oracle's scripts rely on vCenter data to identify VM-to-host placement — and if that data contains inaccuracies, the physical host count Oracle calculates may be overstated. Review our guide to Oracle partitioning rules for VMware for the full technical and contractual analysis.
Options and Packs: Installed vs Intentional Use
Oracle's policy is that any option or management pack that appears as installed or active in the Oracle database metadata is "in use" and therefore requires a licence. This creates audit findings for features that were enabled by default during database installation, enabled as part of a Proof of Concept that was never removed, or enabled by Oracle Professional Services during an engagement. The challenge: Oracle's counting methodology does not differentiate between intentional and unintentional feature activation. Demonstrating that specific features were never operationally used — and removing them before audit data collection — is a legitimate response that reduces the finding.
Processor Core Factor Table Errors
Oracle applies different core factor multipliers to different processor families. Application errors in identifying the correct processor family (particularly for newer Intel generations not yet reflected in Oracle's published tables) create overstatements. Oracle's scripts rely on processor identifiers that must be correctly mapped to the core factor table — and in mixed-generation server environments, this mapping is sometimes incorrect. Independent verification of processor identification is a standard element of effective Oracle audit defence.
What to Do Before Running Oracle Scripts
The period between receiving Oracle's data collection request and running the scripts is the most valuable time in any Oracle audit engagement. Enterprises that use this period productively consistently achieve better outcomes than those that immediately comply.
Engage an independent Oracle licence specialist immediately. The specialist should review the scripts to confirm they are the current version, assess whether the data collection scope is within what your contract requires, and identify any known methodology issues that need to be documented before submission.
Run the scripts internally first. Before providing output to Oracle or the audit firm, run the scripts in your environment and review the output. Identify any database options or management packs that appear as active but were not intentionally deployed, and investigate whether deactivation is feasible and appropriate before the formal collection date.
Document your virtualisation environment independently. Prepare your own documentation of VM-to-host placement, physical host processor configurations, and VMware vSphere version and features, before Oracle's scripts run. This independent documentation is the basis for challenging any overstatement in Oracle's physical host count calculations.
Review your entitlement position against anticipated findings. Before you know what Oracle's scripts will show, map your current Oracle licence entitlements against the deployment landscape. Understanding where genuine gaps exist versus where Oracle's methodology will overstate the gap allows you to prepare the appropriate response to each element of the eventual finding.
Reviewing and Challenging the Output
Once Oracle's audit firm has produced a compliance report based on the script output, the review and challenge process begins. Oracle typically provides a draft findings report for the enterprise's review before finalising the claim — this is the critical window for technical challenge.
Effective technical challenges require: a line-by-line review of each compliance gap finding with reference to the specific script data that generated it; independent verification of the processor identification and core factor application; documentation of any options or packs that appear as active but were never intentionally deployed; and a VMware topology review that maps Oracle's physical host count calculations against actual VM placement records. See our companion article on Oracle audit defence and our article on how to respond to an Oracle audit letter for the procedural framework.
The Oracle Negotiation Playbook includes a detailed treatment of LMS script methodology, the most common overstatement patterns, and the challenge documentation format that produces the best response from Oracle LMS's technical team.
Using Methodology Disputes as Negotiation Leverage
Methodology disputes are not just technical corrections — they are commercial leverage. Oracle's LMS team and sales organisation operate under different incentive structures. LMS wants to close the audit finding quickly; Oracle sales wants to protect the customer relationship and secure the renewal. When you introduce a substantive technical challenge to the methodology, you shift the conversation from "how much do you owe?" to "what does your contract actually require?" — and that shift consistently produces better commercial outcomes.
The most effective settlement conversations combine a documented technical challenge (reducing the finding on legitimate grounds) with a commercial proposal (converting the audit resolution into a longer-term commercial agreement at terms more favourable than Oracle's standard position). Our specialists have executed this combined strategy across dozens of Oracle engagements. The Oracle ULA negotiation guide and Oracle renewal strategy articles provide the commercial framework for converting audit pressure into strategic negotiating advantage.