IBM Floating and Token-Based Licensing: Maximising Shared Licence Models

IBM Licence Model Fundamentals

IBM's software catalogue uses several distinct licensing metrics, and understanding the differences is essential for cost control. The most common IBM licence models fall into three broad categories: processor-based metrics (PVU and VPC), user-based metrics (Authorised User, Concurrent User), and token-based metrics (IBM Licence Token). Floating and token-based models both share a defining characteristic: the licence entitlement is a pool consumed dynamically rather than a fixed assignment to a specific person or server.

IBM introduced its token-based licensing model to provide flexibility for organisations that need to run multiple IBM products but where simultaneous usage of all products by all users at all times is unrealistic. Rather than purchasing separate entitlement for each product for every potential user, token licensing allows a pool of credits to be consumed across products in proportion to actual usage. This makes token licensing attractive for environments with diverse IBM software portfolios and non-uniform usage patterns.

Floating Licences Explained

A floating licence, also called a concurrent-user licence, allows a pool of licences to be shared among a larger population of potential users. IBM implements floating licensing through the IBM Licence Key Server (LKS), which allocates a licence "check-out" when a user launches the application and returns it to the pool when they close it. If all licences in the pool are checked out, additional users receive a denial until a licence becomes available.

Floating licences are suited to software where the number of simultaneous users is predictably lower than the total potential user population. A tool used by 200 staff but with a realistic peak concurrency of 40 users can be licensed for 40–50 concurrent licences rather than 200 named-user licences — delivering savings of 60 to 75 percent for that product. The critical variable is peak concurrency: floating licences that are sized too tightly result in user denials that damage productivity and create pressure to over-purchase. Usage data from the licence server's check-in/check-out logs is essential for correct pool sizing.

Token-Based Licensing Explained

IBM's token licensing system uses a virtual currency — licence tokens — that are consumed in defined quantities when different IBM products are used. Each IBM product in the token programme has a published token value, reflecting how many tokens are consumed per user per session or per measurement period. A product consuming five tokens per concurrent user will draw from the same token pool as a product consuming 10 tokens per concurrent user, with the pool depleted proportionally based on actual product usage mix.

Token licences are managed through IBM's Rational Licence Key Server (RLKS) for Rational products or through equivalent IBM licence management infrastructure for other product families. The token pool is monitored centrally, and usage reports can be extracted to validate actual consumption against entitlement. Unlike floating licences for a single product, token licences provide cross-product flexibility — organisations can shift usage between products in the token programme without purchasing separate entitlement for each.

When Floating and Token Licences Deliver Savings

Shared licence models deliver cost advantages in specific usage scenarios and are value-neutral or even more expensive in others. The fundamental test is the ratio of total users to peak concurrent users. If your total user population is three or more times your peak concurrent count, floating or token licensing will almost always be cheaper than named-user licensing. If total users and peak concurrent users are nearly equal — common in 24x7 operational environments where users are permanently logged in — floating licences offer little advantage and introduce licence server infrastructure overhead without cost benefit.

Scenarios Where Floating Works Well

Development and QA environments are the classic case for IBM floating licences. Developers using IBM Rational tools, IBM DataStage, or IBM InfoSphere suites typically work on individual projects with defined cycles. The peak concurrent usage of a 150-person development team will rarely exceed 60 to 80 at any given time, making a floating pool of 60 to 70 licences sufficient. Similarly, geographically distributed organisations operating across time zones can leverage the fact that peak concurrency in any region is lower than the global user count, making floating licences structurally efficient for the overall estate.

Analytics and reporting tools — IBM Cognos Analytics, IBM Planning Analytics, IBM SPSS — are well suited to floating licensing because business users access these tools episodically rather than continuously. Finance teams run reports at month-end; business analysts run models for specific projects; management users review dashboards periodically. The pattern of intensive short-duration usage with long idle periods between sessions is exactly the scenario where concurrent licences deliver their maximum efficiency advantage over named-user models.

Scenarios Where Token Licensing Provides Cross-Product Efficiency

Token licensing is most valuable when an organisation has a portfolio of IBM development or analytics tools with varied and overlapping user populations. If your development team uses IBM Rational DOORS for requirements management, IBM Rational Rhapsody for design modelling, and IBM Rational ClearCase for version control, but no individual developer uses all three tools simultaneously, a token pool can serve the entire portfolio more efficiently than separate per-product floating licences for each application.

The optimisation opportunity in token licensing lies in the usage mix. Because different IBM products have different token consumption rates, a pool sized for average consumption may be insufficient during periods when high-token-cost products are heavily used simultaneously. Usage log analysis across all token-consuming products is necessary to identify the actual peak token demand pattern and size the pool accordingly.

ILMT and Sub-Capacity Compliance for Shared Models

IBM License Metric Tool (ILMT) is the mandatory compliance tool for organisations claiming sub-capacity pricing on virtualised IBM software deployments. The relationship between ILMT and floating or token-based licences requires careful attention because the compliance rules interact in ways that are not always obvious.

ILMT is designed primarily to track processor-based licence metrics — PVU (Processor Value Units) and VPC (Virtual Processor Cores) — on virtualised infrastructure. For products licensed under PVU or VPC metrics, sub-capacity licensing is valid only if ILMT is correctly deployed on all virtual machines running IBM software, generating compliant usage reports at the required frequency. This requirement applies regardless of whether the overlying licence model is floating or named-user: if an IBM product using a floating user licence metric is deployed on virtualised infrastructure and that product also has a processor-based component under the same licence (which is common in IBM middleware), ILMT must be tracking the processor dimension of that deployment.

For products licensed under pure user-based or token metrics without a processor dimension, ILMT is not required for licence compliance tracking. However, many IBM products have dual licence metrics — a processor component and a user component — and organisations that assume ILMT is irrelevant because they are managing the user-based dimension of a licence can inadvertently create compliance exposure on the processor dimension.

The practical recommendation is straightforward: any IBM software deployment on virtualised infrastructure should be tracked by ILMT, regardless of the primary licence metric used to manage that deployment. ILMT's visibility into virtualised IBM software deployments provides a compliance safety net that is worth maintaining even when not strictly required by the specific licence metric in use.

PVU-to-VPC Transition Impact on Shared Models

IBM's transition from PVU to VPC metrics for Cloud Pak products affected the processor-dimension compliance requirements for many organisations managing these products under floating or token licensing arrangements. As IBM moved Cloud Pak products from PVU to VPC, the ILMT configuration required to track the processor dimension of those deployments changed: ILMT must now report VPC consumption rather than PVU consumption for products that have completed the transition.

Organisations that had correctly configured ILMT for PVU tracking before the Cloud Pak transition needed to update their ILMT configuration to capture VPC metrics when those products transitioned. This reconfiguration step was frequently missed, creating a silent compliance gap where ILMT continued reporting PVU data for products now licensed under VPC, leaving IBM's sub-capacity claim for those products unsupported by valid current reporting. ELA customers approaching renewal should verify that their ILMT configuration reflects current IBM metric requirements for all products in their portfolio, particularly those that have moved from PVU to VPC as part of Cloud Pak bundling.

Right-Sizing Shared Licence Pools: A Practical Approach

Correctly sizing a floating or token licence pool is a data-driven exercise. IBM's licence key servers — whether RLKS, LKS, or equivalent — generate detailed usage logs recording every check-out, check-in, and denial event. These logs contain the information necessary to determine the appropriate pool size with statistical confidence.

The optimal pool size is not the peak concurrent usage recorded in the logs. Peak usage events are often momentary anomalies — a team-wide training session, a go-live period, a month-end rush — that do not represent the steady-state requirement. The optimal pool size is the level at which denial events occur at an acceptable rate (typically less than two percent of access attempts) while keeping total licence cost below the named-user alternative. Sizing to the 95th percentile of concurrent usage in a rolling 90-day window is a commonly applied and commercially defensible methodology that balances user experience against licence cost.

Organisations without access to historical licence server logs — for example, those implementing floating licensing for the first time — can use a conservative starting point of 40 to 50 percent of total user count as the initial pool size, then adjust based on actual usage data after 30 to 60 days of deployment. IBM's standard guidance of sizing to 75 to 80 percent of total users is commercially conservative and typically results in over-licensing. The 40 to 50 percent starting point is more appropriate for occasional-use analytics or development tools, while 60 to 70 percent is more appropriate for operational tools with higher session frequency.

Common Compliance Mistakes with IBM Shared Models

Floating and token licence models introduce specific compliance risks that differ from named-user or processor-based models. The most common mistakes we observe in IBM software estate reviews involving shared licence models fall into three categories. First, licence server misconfiguration that allows more concurrent check-outs than the pool entitlement supports — typically caused by manual configuration errors when licences are added to the pool or when the server is migrated to new infrastructure. Periodic validation of licence server configuration against entitlement records should be a standard ITAM procedure. Second, incorrect ILMT configuration for products deployed on virtualised infrastructure where a processor dimension exists alongside the user-based metric, as described above. Third, failure to track actual concurrent usage against the licence pool entitlement, meaning compliance gaps go undetected until IBM's licence server audit capability exposes them during an audit. IBM's Software Compliance group has access to detailed licence server log data during audits — organisations that assume their licence server is self-policing without verification are taking a significant compliance risk.