Short Duration Apps
Many valuable software tools that require floating licensing run for only a short time. These include various solvers, development and design tools, and other specialty software products designed to perform specific tasks quickly. Unlike typical interactive or desktop applications, these short-burst applications typically do not have a GUI of their own, but are often launched by other applications within a product suite.
Licensing Challenge
The licensing challenge is based on the fact that a floating license is a shared license. When a floating license is used it is unavailable until it is returned. But, short duration tools consume licenses for only a short time, so a single license could potentially be shared by a large number of users.
The licensing challenge is really a pricing challenge. How do you set a price for a single floating license that is low enough for small sites to afford while at the same time scaling your pricing so that larger sites that use more of your software pay you more for that use? How do you prevent large sites from satisfying their requirements by licensing only a single floating copy of your software?
Node-Locking
An outdated approach would be to revert to node-locked licenses tied to each workstation or user. Although this would solve the problem, the vendor and end customer would be inconvenienced by having to create, install and manage N licenses for N users. This is very inefficient.
Customers prefer to float licenses to users who need them.
Extra Hold Time
One way to handle this problem is to implement an extra hold time on the floating license. This holds the license for an extra number of seconds after it is released, regardless of how long the license was actually used. So, for example, if the application uses the license for 20 seconds, upon termination of the program the license is held for an additional 300 seconds, say, for a total of 320 seconds. The effect is that the floating license can be shared by fewer users because it is “busy” for a longer period of time each time it is used. This encourages customers to order more licenses to satisfy their user population. But, some customers may object to the license being unavailable for such a long time.
Minimum Checkout Time
Another similar method is to enforce a minimum license checkout duration. Instead of extra time being added to the end of a licensing session as in the above example, a license would be held for at least a specified minimum amount of time. So, a license with the minimum checkout time set to 300 seconds would add 280 extra seconds to a license that was in use for only 20 seconds. Licenses used for more than 300 seconds would not be affected.
Both extra hold time and minimum checkout time should be specified in the license file, external to the application, so that the same executable can use either method without modification to the source code.
Post-use Billing
Since the ultimate goal is for the vendor to get paid an amount that is proportional to the value derived from the customer’s use of the software, you may want to introduce a metered or pay-per-use approach based on actual usage time. A post-use billing model allows a customer to use as much or as little of the software as he wished, with no artificial licensing constraints. The vendor and customer would agree not on a per copy price, but on a per hour price. Periodically, say once a month, the user submits a report generated from the license manager’s transaction log file that summarizes usage time. The user can add their own constraints to the licenses to prevent exceeding a certain budget, but both the customer and the vendor would be satisfied.
RLM can handle these approaches, so please contact Reprise Software to discuss your needs in more detail.
