How is Oracle WebLogic licensed?
Oracle WebLogic is licensed by edition, most commonly on the Processor metric, which counts physical cores multiplied by the core factor from the core factor table, so the edition and the hardware together set your licensable number. The editions, Standard, Enterprise, and Suite, are tiered, and each includes a different feature set. Standard covers the base application server. Enterprise adds clustering and higher availability features. Suite adds further capability again. The edition you are entitled to is fixed in your ordering document, and your compliant position is defined by that entitlement, not by what the installed binaries happen to make available.
This matters because the WebLogic binaries often contain features that belong to a higher edition than the one you licensed, much as an Oracle Database installs options by default. Running a feature that belongs to Enterprise while licensed only for Standard is the middleware equivalent of an accidentally enabled database option. This topic links up to the Oracle license compliance guide, and it sits beside Forms and Reports licensing.
Why do features above your edition create exposure?
Features above your edition create exposure because the WebLogic install can expose capabilities that require a higher edition, and using one, even unintentionally, reads to an auditor as use beyond your entitlement priced at the higher edition. Clustering is the classic example. A team licensed for Standard that configures a WebLogic cluster for resilience may be using a feature that belongs to Enterprise, and a finding will price the whole deployment at the Enterprise edition. The exposure is not the intent, it is the configuration, which is why the feature configuration is reviewed against the licensed edition before an audit rather than after a finding.
| Edition | Typical scope | Watch point |
|---|---|---|
| Standard | Base application server | Clustering belongs to a higher edition |
| Enterprise | Clustering and availability features | Suite features priced higher again |
| Suite | Broadest feature set | Confirm what you actually use |
The defence is to map the features in use to the edition you licensed, and to confirm whether a higher edition feature is genuinely in production or merely present in the install. The same discipline of separating used from merely installed that protects a database options finding protects a middleware edition finding. For the migration economics when an edition gap is large, read migrating off WebLogic, the exit math.
Your WebLogic position is the edition you licensed, not the features the binaries expose. A feature above your edition that is in use is the middleware version of an accidentally enabled option.
How does virtualization affect WebLogic licensing?
Virtualization affects WebLogic licensing the same way it affects the database: where WebLogic runs on a hypervisor Oracle treats as soft partitioning, Oracle's policy position is that every physical core where the software could run must be licensed, which produces the cluster wide claim. A WebLogic deployment on a few virtual cores inside a large cluster can attract a finding sized to the whole cluster, not the cores actually in use. This is the single largest swing factor in a middleware finding, because it multiplies the core count by the size of the underlying estate rather than the size of the deployment.
The defence is the contract versus policy distinction. The cluster wide claim rests on Oracle's partitioning policy, and where that policy is not incorporated into your agreement, the claim has a weaker footing, because contract language beats policy. The core count is also tested against the core factor table for the processor type, since the same table that governs the database governs WebLogic on the Processor metric, and a wrong factor inflates the number. Where the partitioning treatment or the contract wording is unclear, the answer is contract dependent and is resolved before any concession. Script output that reports the deployment is reviewed first, because it can overcount across virtualization layers.
Our Oracle compliance workbook maps your WebLogic editions, features, and cores against your entitlement and the core factor table, and tests any cluster wide claim against your contract. Fixed Fee or Gainshare, with no risk to you.
What is the buyer move?
The buyer move is to map your WebLogic deployment to the licensed edition, confirm the cores against the core factor table, and test any cluster wide claim against whether your contract actually incorporates the partitioning policy. List the features in use and check each against your edition, separating genuine production use from features merely present in the install. Confirm the processor type and its factor so the core count is right. Where WebLogic runs virtualized, challenge a cluster wide finding that rests on policy your agreement never adopted, and treat ambiguous wording as contract dependent. Review any script output before it leaves your network. To map your middleware estate and find the inflated edition and cluster claims, download the workbook and work up to the Oracle license compliance guide.
FAQ
How is WebLogic licensed? By edition, most often on the Processor metric, which counts cores times the core factor. The edition sets which features are included.
What creates exposure? Running features above your edition, deploying on more cores than entitled, and clustering across virtualization Oracle treats as soft partitioning.
Does the database core factor apply? Yes. WebLogic on the Processor metric uses the same core factor table as the database, so the processor type and its factor decide the count.