TIBCO Processor and cloud licensing

The Processor is the oldest and still most widely encountered TIBCO Unit type. The Business Unit Terms define it as a licensing Unit type for the Software, based on the count of Virtual and/or Physical Processors as described in the TIBCO Processor Licensing Policy and/or the TIBCO Cloud Computing Environment Licensing Policy.^[3] Two policies therefore decide the number: one for virtualised and physical estates, one for public clouds. This article explains both and the vocabulary they depend on.

Vocabulary

The policies rely on definitions in the Business Unit Terms. A Physical Processor is the smallest physical electronic circuit capable of reading and executing computer programs and providing results as output, for example a CPU (socket), core or thread.^[3] A Virtual Processor is a simulation of a Physical Processor that is serially time-multiplexed across one or more Physical Processors.^[3] A Virtualized Environment is an operating system environment in which multiple Virtual Machines can run on a single physical machine or cluster, sharing its resources, and in which a Virtual Processor can run on only one Physical Processor at a time.^[3] Fixed Partitioning is a mechanism that confines the Software to a fixed isolated subset of the Physical Processors on a multi-processor machine, such as physical partitioning or fixed (hard) processor affinity.^[3]

Note that the definition of Physical Processor lists a CPU socket, a core or a thread as alternatives. The vendor’s text does not say which applies; the multi-threading rule below supplies the practical answer for threads.

Counting in virtualised and other environments

The Processor Licensing Policy, headed “Effective December 1, 2011”, states that certain Products are licensed by the Unit type Processor and describes how to count the Units in a Virtualized Environment and in all other environments.^[1]

Virtualized Environment

The count proceeds in three steps.^[1]

1. For each Virtual Machine running the Product, count Virtual Processors in whole numbers. The lowest unit is one, and any fraction rounds up.
2. If the number of Virtual Processors of a Virtual Machine can increase or decrease, count the maximum whole number that could ever be assigned to the Virtual Machine running the Product.
3. Add the Virtual Processors across all Virtual Machines in the entire Virtualized Environment that runs the Product.

The second step matters most for managed estates. A virtual machine that is configured to scale between 4 and 16 virtual processors counts as 16, even if the average is 6.

Other environments

Where the Product runs on physical machines, or where a Virtual Processor can run on more than one Physical Processor at a time, the policy counts Physical Processors.^[1] The partition boundary is set first. Where allocation is defined by Fixed Partitioning, the boundary includes all Physical Processors that could ever execute the Product. Where it is not, the boundary includes all Physical Processors on the physical machine. The counts per physical machine are then aggregated across the environment.^[1]

The policy text names only Fixed Partitioning (for example physical partitioning and fixed or hard processor affinity) as narrowing the partition boundary, so identifying the environment type is the first step in any recount.

Multi-threading and rounding

For all environments, if multi-threading is enabled for the underlying physical cores, the total count of Physical or Virtual Processors is multiplied by 0.5. If multi-threading is disabled, a multi-threaded core is treated as a single-threaded core. In a Virtualized Environment the 0.5 multiplier then does not apply, and in other environments the number of cores rather than threads is the number of Processor Units, again without the multiplier. Any fraction is rounded up to the next whole number.^[1]

A worked example, using only the policy’s rules: a physical server without Fixed Partitioning has two sockets of 8 cores each with multi-threading enabled, which the policy treats as 32 Physical Processors (threads). The multiplier gives 16 Processor Units. The same server with multi-threading disabled shows 16 cores, which count as 16 Processor Units. A virtual machine that can be assigned at most 6 vCPUs on hardware with multi-threading enabled counts 3 Processor Units. The examples are illustrative arithmetic, not vendor statements.

Public cloud: the CCEL Policy

The Cloud Computing Environment Licensing Policy (CCEL Policy), headed “V1” and “Effective December 1, 2021”, covers Processor Units when the Licensor Software is deployed in a Cloud Computing Environment. It states that customers who entered an Order with TIBCO between April 7, 2020 and December 1, 2021 remain under the previous CCEL Policy.^[2] Any other Unit types are counted one for one when moved from on premise to a Cloud Computing Environment.^[2]

The Business Unit Terms define a Cloud Computing Environment as a virtual, cloud-based networking solution managed or maintained by a third-party cloud service provider on behalf of the customer, including Cloud Machine Instances, and offered to the public for use and purchase.^[3] The CCEL Policy states that the Processor Licensing Policy does not apply to Cloud Computing Environments, with the exception of Bare Metal environments, which follow the Processor Licensing Policy.^[2]

Counting in a cloud

The calculation has three parts.^[2]

1. If the number of Instances or Virtual Machines can grow dynamically, the count includes the maximum number of machines running the Software that could ever run concurrently under the customer’s configuration. For nested virtual machines the count is of the nested machines running the Software.
2. For each such machine, the Virtual Processor count is the maximum number of vCPUs that the cloud machine type is capable of running, in whole numbers. If the machine is capable of multithreading, the figure is multiplied by 0.5, with a minimum of one per machine and fractions rounded up.
3. The Processor Units needed are the total of those Virtual Processors.

Two practical consequences follow. Auto-scaling groups are counted at their configured maximum rather than their typical size. And the count is driven by the machine type’s capability, not by the vCPUs actually consumed. The policy also reserves the vendor’s right to amend or rescind the calculation section if new technology adds abstraction layers that allow more processes on a Processor, but only if amendments cannot achieve the intended one-to-one relationship between physical Processors and Processors used in cloud environments.^[2]

Administrative License Fee

Where an agreement incorporates the CCEL Policy but contains no specific licence grant to deploy in a Cloud Computing Environment, the policy supplies one, subject to payment of the CCE Administrative License Fee and associated Maintenance.^[2] The fee is defined as thirty percent (30%) of the cumulative licence fees (Perpetual or Subscription) paid for the Software under the applicable agreement, plus an annual Maintenance fee calculated by multiplying the administrative fee by the Maintenance rate.^[4]

The fee and first-year Maintenance are due on or before the first deployment, and annual Maintenance falls due on each anniversary of that date. The policy adds that once the Software is deployed in a Cloud Computing Environment, even on a temporary basis, the fee and associated Maintenance are due.^[2] The grant does not add Units beyond those in the agreements or any associated deployment report.^[2] This means a proof-of-concept deployment on a public cloud can trigger the fee, so the cloud placement of test environments belongs in the compliance review.

Enterprise, Project and Unlimited licences

A customer with an active Enterprise, Project or Unlimited licence may move to a Cloud Computing Environment on payment of the fee and associated Maintenance. At the end of the term the customer uses the CCEL methodology to count Processors deployed in its cloud environments. Customers without such a licence may move under the policy’s other provisions.^[2] This interacts with the fixed deployed count at the end of an enterprise term (see TIBCO enterprise licences and deployment reporting).

Newer product pages

The 2025 TIBCO Platform licence-information page repeats a cloud rule in simpler form: as part of an active entitlement to the Products, the customer has the right to deploy the Software into a Cloud Computing Environment, provided it ensures the provider does not grant access to any other party, monitors the provider’s hosting, and answers for any provider violations.^[5] For TIBCO Platform that page replaces the Processor Unit type with component-level metrics such as Application Instance and Connection, and it uses Core and vCPU for some server components.^[5]

Where Processor still applies

The legacy row matters for older contracts. A Server Instance under the 2004-era EULA is a computer with one CPU unless the order says otherwise, which is a different test from the Processor Units of the 2011 policy.^[8] Which definition applies depends on the agreement the order incorporates.

Worked checklist

1. Establish whether the Product runs in a Virtualized Environment, on physical machines, on bare metal or in a public cloud.
2. For virtualised hosts, record the maximum vCPUs assignable per virtual machine and apply the 0.5 factor only if hardware multi-threading is enabled.
3. For physical hosts, determine whether Fixed Partitioning confines the Product; if not, count the whole machine.
4. For clouds, record the machine type’s maximum vCPUs and the maximum concurrent instance count of each scaling group.
5. Check whether the CCE Administrative License Fee has been paid for every cloud deployment, including temporary ones.
6. Compare the result with the quantities in the Order or in the last deployment report.