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 that are designed to perform very specific tasks very quickly. Unlike typical interactive or desktop applications, these short-burst applications typically do not have a GUI of there own, but are often launched by other applications within a product suite.
The “Short Duration” 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 “Short Duration” Pricing Challenge
The licensing challenge is really a pricing challenge. In other words, 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?
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 would 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.
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, how about introducing a metered or pay-per-use approach? This approach is based on actual usage time. A post-use billing model would allow 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 would submit a report generated from the license manager’s transaction log file that would summarize usage time. The user could put his own constraints on the licenses so as not to exceed 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.