IBM Floating and Token-Based Licensing
IBM offers flexible licensing models beyond named-user and CPU metrics – notably floating user licenses and token-based licensing.
This article targets CIOs, SAM managers, and IT procurement heads to demystify these shared licensing types.
Floating (concurrent) licensing allows multiple users to share a pool of licenses, which can reduce costs in environments with many occasional users.
Token-based licensing (used in certain IBM products like Rational and Maximo) provides a virtual currency of “tokens” that can be consumed by various software products, offering cross-product flexibility.
We explain how each model works, provide real-world examples (e.g., using 10 floating licenses for a team of 30 engineers) and lay out best practices to maximize value while staying compliant.
Read IBM Subscription Licensing: How It Works and When to Choose It.
Understanding IBM Floating (Concurrent User) Licensing
In a floating or concurrent user model, the software is not tied to a specific named user. Instead, a set number of licenses can be used simultaneously by anyone in the organization up to the limit at any given time.
IBM often implements floating licensing via a license server or software key mechanism that tracks current usage.
Key points include:
- License Pool: You purchase a certain number of floating licenses (say 10). This means up to 10 users can be actively using the software concurrently. An 11th user would be blocked from launching it until someone exits.
- User Flexibility: Any authorized person can use the software as long as the pool has a free slot. This is great for teams where not everyone needs the tool at the same time. For instance, if you have 40 analysts but typically only 10-15 use IBM SPSS Statistics at once, buying 15 floating licenses could cover the whole group’s needs.
- Implementation: IBM floating licenses usually require a license manager application (e.g., IBM License Key Server or Flexera FlexLM for IBM Rational products) installed on a server. Users’ software checks out a license from the server when launched and returns it when closed.
- Cost Efficiency: Floating licenses often cost more per license than a single named-user license (because of the flexibility they give). But you usually need far fewer of them than total users. The savings can be dramatic – e.g., instead of 40 named licenses for 40 users, maybe 15 concurrent licenses suffice, potentially halving the cost.
- Industries & Examples: Concurrent licensing is common in engineering and analytics tools. IBM SPSS, IBM Rational (now part of HCL in some cases), and older IBM Domino server CALs all have had concurrent user options. A concrete example: An engineering firm has 25 developers using IBM Rational Rose modeling tool. They determine only about 10 use it at any one time. By purchasing 10 floating licenses (and setting up IBM Rational License Key Server), they allow all 25 to have access while ensuring no more than 10 are active concurrently – significantly cutting costs vs. 25 fixed licenses.
IBM Token-Based Licensing Explained
Token-based licensing is another flexible model IBM provides for certain product families (notably IBM Rational, IBM Maximo Application Suite, and some Cloud Paks use a token concept).
In this model, instead of buying X licenses of each product, you buy a pool of license tokens.
These tokens are like credits that get consumed in different quantities by different software or features.
Key aspects:
- Single Currency for Multiple Products: A token pool can cover multiple tools. For example, IBM Rational software suite historically offered token packs that could be used across Rational Team Concert, Rational DOORS, Rational Rhapsody, etc. Each product action might “cost” a certain number of tokens.
- Token Consumption: IBM defines how many tokens each product uses per instance or per user. For instance, running IBM Rational Developer might consume 1 token per user, while using a higher-end IBM Rational application might consume 3 tokens per user concurrently. If you have 30 tokens, you could run 30 instances of a 1-token app, or 10 instances of a 3-token app, or any combination that uses up to 30 tokens at a time.
- Dynamic Allocation: This model shines in environments where usage of various tools fluctuates. One day, more users might use Product A, next day more of Product B – the token system dynamically allocates capacity. It prevents the scenario of having unused licenses of one product while another product is short on licenses.
- Refilling: Tokens are not “spent” permanently; they are more like concurrent licenses in credit form. When a user closes the application, those tokens return to the pool for others to use. Think of it as a floating license but generalized across multiple software titles.
- Cost Consideration: Pricing is typically based on the number of tokens. One token might be priced so that buying a token pool roughly equates to a certain mix of use. If you only ever use one product heavily, token licensing can be more expensive than a direct license for that product. But if you have many products with sporadic use, tokens add huge flexibility. For example, an organization might buy 100 tokens for the Maximo Application Suite, which allows them to use various Maximo modules (Asset Management, Monitor, Health, etc.) by consuming tokens for each module’s active users. This way, if Module A usage drops and Module B rises, they don’t need to buy new licenses – the token pool adjusts.
Real-World Example:
Consider IBM’s Engineering Lifecycle Management suite (Rational). Instead of 50 floating licenses for DOORS and 50 for Rhapsody, a company purchases, say, 80 tokens. Using IBM’s token table, they find DOORS uses 1 token per user session and Rhapsody uses 2 tokens per session (hypothetical values).
This means at most, 80 DOORS users or 40 Rhapsody users could work concurrently, or a mix (e.g., 40 DOORS + 20 Rhapsody using all tokens). If on some days DOORS usage is low, those tokens can cover more Rhapsody users, and vice versa. The overall license pool is efficiently utilized.
Benefits of Floating and Token Licenses
Both models aim to optimize license utilization and reduce waste, which can translate to significant cost savings and flexibility:
- Cost Savings: As noted, if not all users need a software simultaneously, floating licenses prevent paying for idle capacity. With tokens, you avoid purchasing separate fixed licenses for multiple products, some of which might sit unused at times.
- Flexibility: Floating licenses accommodate shifting usage within a team. Token licensing goes further, accommodating shifting usage across different applications. This is ideal for diversified software portfolios.
- Simplified Management (Tokens): Instead of tracking entitlements for five different products, you manage one token pool. This can simplify compliance tracking – though you must ensure the license monitoring tool is in place. IBM usually provides a token license server that counts token check-outs.
- Scalability: Need more simultaneous users occasionally? You can add more floating licenses or tokens to the pool, and everyone in the organization benefits. Conversely, if usage drops, you aren’t stuck with named licenses assigned to former employees – floating/token pools automatically adjust to active user counts.
- Enterprise License Agreements: IBM sometimes includes token pools in enterprise agreements to give customers more agility. For example, an enterprise might negotiate a certain token pool to be shared among various development and test tools, making it easier to distribute costs internally based on actual use.
Read IBM Non-Production Licensing (Dev/Test & Disaster Recovery): Strategies to Optimize Costs.
Challenges and Compliance Considerations
While powerful, these licensing models require proper management:
- License Server Uptime: If the license server that manages floating or token licenses goes down, users may be unable to start software. CIOs should ensure high availability for license servers (e.g., running redundant servers or backup license keys for emergencies) to avoid work stoppages.
- Tracking Usage: Floating and token models demand good tracking. Over-usage beyond purchased amounts typically isn’t possible in real-time (the software will deny access if no license/tokens are available). However, during audits, IBM will check that your purchased count of floating licenses or tokens is sufficient for your usage. Keep records of what you’ve purchased and monitor your peak usage. Most license server software will log denials – if you see frequent denials, that’s a sign you may need to buy more licenses or tokens.
- Geography and Network: Some IBM floating licenses are constrained by geography or network. For instance, a license file might be restricted to use within a country or a defined subnet. Ensure your floating license agreement matches your deployment (especially with global teams – you may need separate pools per region if restricted).
- Token Accounting: Understanding the token “conversion rates” for each product is vital. IBM provides tables that show how many tokens each product or module consumes. These can change with versions or IBM’s adjustments. Always refer to the latest token usage table so you’re not caught off guard (e.g., an upgrade might start consuming more tokens per user if features expanded).
- Higher Entry Cost: While cost-efficient in usage, the upfront cost of implementing token licensing can be high. IBM often sells token packs (e.g., min 100 tokens). Smaller organizations might find they don’t use enough breadth to justify tokens. Similarly, some floating licenses might require at least a certain number of seats. Always size appropriately – if only a few users need an application constantly, a named user license could be cheaper than a floating one at small scale.
- Compliance Audits: In an IBM audit, you’ll be asked to provide evidence of entitlements (proof of how many floating licenses or tokens purchased) and possibly usage logs. Be sure you retain proof of purchase and deployment records. Also, configure IBM’s audit tools (like ILMT or the IBM License Key Center reports) to cover these licensing models. ILMT, for instance, may track PVUs but for user-based metrics, the onus is on you to demonstrate control. For tokens, IBM’s own token license server report is usually used.
Best Practices for Maximizing Value
To get the most out of floating and token licensing models:
- Analyze Usage Patterns: Before deciding how many floating licenses or tokens to buy, study your user behavior. Use any available logs from existing usage or run a pilot. For example, over a month, find the peak concurrent usage of a software to size a floating license pool. If peak was 18 users once but normally it’s 10, you might buy 12-15 concurrent licenses and manage that occasional peak (maybe by scheduling users). Data-driven decisions prevent over-buying “just in case.”
- Grouping by Time Zones or Departments: If you have global teams, floating licenses can sometimes be shared across time zones (e.g., Europe and Americas might use licenses at different times of day). Ensure your licensing terms allow this and technically implement a follow-the-sun license server if possible. This can squeeze extra value from the same pool.
- Regularly Right-Size Token Pools: With token licensing, periodically review if your token pool is sufficient or excessive. IBM’s token reports can show the maximum tokens in use. If you consistently only use 50 out of 100 tokens, you might reduce the pool at renewal (if contract allows) or shift some tokens to other needs. Conversely, if you’re hitting 100 tokens often and getting denials for additional usage, plan to add tokens to avoid productivity loss.
- User Education: Educate users to release licenses when not actively using the software. For floating licenses, this could mean closing applications at end of day or when idle. Some IBM tools have idle timeout features – configure those so licenses automatically return to the pool after X hours of inactivity. Similarly with tokens, ensure users aren’t holding onto tokens unnecessarily (e.g., not running multiple instances on one person’s machine unless needed).
- License Borrowing Feature: IBM Rational and some other products allow “borrowing” a floating license for offline use (say an engineer going offsite with a laptop). While useful, this temporarily reduces the pool available to others and could lead to compliance issues if not tracked (because the license server counts it as in use until returned or expiry). Use borrowing sparingly and keep the borrow period short. Monitor borrowed licenses in the server admin console.
- Centralize License Management: Assign a license manager or SAM (Software Asset Management) role to oversee these pools. They should frequently check usage reports, ensure the license servers are updated (license files updated when you buy more), and coordinate with IBM or partners on any changes. A centralized approach avoids the chaos of different teams over-utilizing or fighting for licenses.
- Combine with Monitoring Tools: If you have IBM License Metric Tool (ILMT) for PVU tracking, note that ILMT doesn’t manage user-based licenses. However, SAM tools like Flexera or ServiceNow can often integrate license usage data (from the IBM license server logs) to give you a full picture. Investing in such tools can automate the monitoring of floating/token use and alert you when you near capacity.
Use Cases – When These Models Are Ideal
- Engineering/Technical Users: If you have engineers, developers, analysts, etc., who use heavy software sporadically, floating licenses make a lot of sense. For example, IBM’s engineering tools or analytics software across a large team.
- Multiple Software Suite: Organizations leveraging a suite of IBM products (like the Maximo Application Suite or Cloud Pak for Automation) might consider tokens if offered. This is ideal when the usage of each component varies – tokens will flow to the area of need.
- Consulting or Training Environments: Companies that have many part-time users or rotational use (like a consulting firm where different project teams use software at different times) benefit from concurrency. Similarly, an internal training environment for IBM software might have classes of users that only need the software during training sessions – a concurrent pool can accommodate different trainees over time rather than licenses per trainee.
- Cost-Constrained Departments: If a department can’t afford individual licenses for all tools its people need, proposing a shared model can stretch the budget. It’s a way of saying “we have 20 folks, but we can manage with 5 licenses because not everyone uses it simultaneously.” This often resonates with procurement to approve budget for 5 pricier concurrent licenses vs. refusing 20 separate ones.
Recommendations
For CIOs and license managers, here are strategic recommendations to get the most out of IBM floating and token licenses:
- Conduct a Usage Audit: Before implementing, audit current usage of relevant software. Identify peak concurrent needs and how many unique users exist. This will inform an optimal purchase quantity that balances cost and user satisfaction.
- Start with a Modest Pool: If unsure, err on the side of a slightly smaller pool initially – you can usually add licenses or tokens quickly if you underestimated. It’s better to start lean and monitor. An overly large pool from day one could waste budget.
- Negotiate Token Flexibility: When setting up a token agreement, negotiate the ability to reallocate or reuse tokens as needs change. Ensure the agreement covers all the products you intend to use. For example, make sure your token entitlements include any new modules IBM might release under that program, so you aren’t stuck needing separate licenses.
- Invest in Training on License Servers: Have at least two people in IT familiar with operating IBM’s license management tools. For continuity, ensure documentation exists for how to update license files (e.g., when adding more seats), how to interpret usage logs, and how to troubleshoot client connectivity.
- Segment License Pools if Needed: In some cases, it may make sense to have separate pools (license servers) for different groups or geographies, especially if you’ve allocated costs to departments. This prevents one group from monopolizing all licenses. It can also improve performance if a local license server is closer to users. Just be cautious not to fragment pools so much that you lose efficiency.
- Monitor and Communicate: Set up dashboards or regular reports on license utilization. Communicate with stakeholders – if you see a trend of licenses being maxed out by afternoons, warn users that they might occasionally face waits, and use that data to justify budget for expansion. Conversely, celebrate efficiency gains (e.g., “We achieved 80% utilization of our licenses this quarter, meaning we’ve minimized waste and saved $X compared to individual licensing”).
- Plan for Growth: As your user base grows, revisit whether the concurrent ratio still holds. 10 floating licenses for 30 users might work, but if users grow to 60, you likely need to increase the pool. The ratio of active users might change as teams become more dependent on the tools. Reevaluate annually or with any major staffing changes.
- Stay Compliant with Terms: Ensure your use of floating or tokens aligns with IBM’s rules. For instance, some token licenses might have restrictions on non-production use or require certain base licenses. Always read the fine print. If unclear, pose hypothetical usage scenarios to IBM and get their approval in writing to avoid audit surprises.
- Leverage IBM Programs: IBM sometimes has programs or promotions, like conversion of older floating licenses to tokens or vice versa. Stay in touch with your IBM account rep or licensing partner to take advantage of these if they align with your strategy.
- Consider Third-Party Expertise: Engaging IBM licensing experts or consultancies (like IBM license compliance specialists) can help optimize these models. They might identify an opportunity, say, to consolidate separate product licenses into a token model for savings, or vice versa. A short engagement can yield significant ROI in license optimization.
FAQ
Q: How is a floating license different from a “Named User” license?
A: A named user license is assigned to one specific user (individual) and only that person can use the software (even if they aren’t using it at a given moment). A floating license is not tied to a single user; instead, it floats among any number of authorized users, but only a limited number can use it at the same time. For example, 1 floating license could potentially service 5 people if they use the software at different times, whereas 5 named user licenses would be needed to give all 5 people access at any time regardless of concurrency.
Q: Does IBM charge extra for the license server software needed for floating/token licensing?
A: Typically, IBM provides the license server manager (such as IBM Common Licensing or Rational License Key Server) as part of your entitlement. There’s no extra charge for the tool itself; you just pay for the licenses or tokens. However, you need a server (which could be a VM) to run it, which is a minor infrastructure cost. Always ensure you download the version of the license server that matches your product version for compatibility.
Q: Can we mix floating and named user licenses for the same product?
A: In many cases, yes. IBM products often allow a mix. For example, you might have 10 users who constantly need SPSS (you give them named licenses) and another 20 occasional users (served by a pool of 5 floating licenses). You’ll need to manage these as separate entitlements, but it’s doable and sometimes optimal. Be careful to track compliance separately for each group. Also note, the software installation might need to point to a license server for floating usage or a local license for named usage, so configuration differs.
Q: What happens if all floating licenses are in use and another user tries to access?
A: The user will typically receive a message that a license is not available – effectively, they are locked out until someone else logs off. This is why monitoring usage and having the right number of licenses is important. It’s good to have an internal policy or communication: e.g., instruct users to save work and close the application when done, especially if it’s known to be a shared license. Some IBM systems will queue the request or keep retrying, but generally, it’s first-come, first-served.
Q: Are token licenses available for all IBM products?
A: No, token licensing is available for specific IBM offerings or suites. Historically, IBM Rational products had token packs. More recently, IBM Maximo’s new version uses tokens (marketed as a unified license for its suite) and some IBM Cloud Paks have a form of token system for add-ons. But you can’t just apply tokens to any IBM software arbitrarily; it has to be under a token-capable license program. Check IBM’s documentation or ask your IBM rep if a token model exists for the set of products you use.
Q: How do we handle IBM audits with token licenses?
A: In an audit, IBM will likely request the usage logs from your token license server over a period (often last 12 months). They will check your peak token usage against what you purchased. To prepare, regularly archive and review those logs yourself. Also, ensure you have the Proof of Entitlement (PoE) documents showing how many tokens you own. If you’ve reallocated or traded tokens, maintain records of those changes. IBM audits on tokens are straightforward if records are in order: they just need to verify you never used more tokens concurrently than you bought.
Q: Do floating licenses work over VPN or remote connections?
A: Yes, if the user can reach the license server over the network, they can check out a license. With many employees working remotely, you may need to ensure your license server is accessible via VPN or is configured in a DMZ for remote access. However, watch out for latency – a very slow connection might have trouble keeping the heartbeat to the license server. Also, if a VPN drops and the server doesn’t see the license returned properly, it might hold it for a timeout period, which temporarily reduces available licenses.
Q: What is the difference between floating licenses and IBM’s “Authorized User Single Install” metric?
A: “Authorized User Single Install” is an IBM metric meaning a specific user is allowed to use the software, but only on one machine/installation. It’s a named user variant with a restriction on number of devices. It’s different from floating because it’s still user-specific. Floating licenses aren’t tied to individuals at all. The “single install” constraint is usually for scenarios where a user can’t have the software on two machines under one license. It’s largely a separate concept from concurrent licensing.
Q: Can tokens be used for production and non-production environments interchangeably?
A: Usually, token pools cover entitlements regardless of environment, as long as it’s the same product family. If you have a test environment and a production environment both drawing from the same token pool, that’s typically allowed – the tokens count usage in total. One thing to verify is whether you might need separate pools for separate environments due to access control or because mixing could complicate your internal chargeback. But from IBM’s side, a token is a token; it doesn’t distinguish prod vs dev usage unless specifically stated in the terms.
Q: Are there any IBM products where floating licensing is not advantageous or not available?
A: Some IBM products don’t offer floating models at all – for example, many IBM SaaS or cloud services are user-subscription only. Also, certain security or compliance sensitive tools might require named users for audit trails. And if a product’s cost is heavily user-centric (like collaboration tools), IBM might only sell by user. In cases where floating is available but you have a very small user count that all use the software heavily (e.g., 3 users who are in the tool all day every day), a floating license provides no real benefit over 3 named licenses and might even cost a bit more. It’s most advantageous for larger populations of occasional users.
Do you want to know more about our IBM Licensing Services?
