Use “sharing” to enforce multi-use license policies
Defining “what uses a license”
Defining “what uses a license” may sound a bit odd, but the meaning of what constitutes a new, unique, license use may have a profound effect on the scope of your licenses. Getting it right means that your customers will use your software precisely as intended. For instance, should a user consume only one license regardless of the number of instances of your software he uses concurrently, or should each copy count separately? What about multi-threaded applications? Should they consume a single license? a license per thread? should there be a limit to the number of threads per license? As you can see, defining “what uses a license” accurately is extremely important. When designed properly to match your software license agreements you avoid any confusion with customers about the scope of your licenses.
License sharing will affect how your pricing scales, so you have to get it right.
What is a “Shared License?”
In RLM, licenses can be shared between separate running processes. To do so, your license must specify the share= attribute. A license can be shared between processes with the same username, hostname, or ISV-defined data, or any combination of these. Sharing is specified as share=UHI, where the keywords ‘U’, ‘H’, and ‘I’ indicate that the Username, the Hostname, or ISV-defined fields must match. If more than one is specified, all specified elements must match in order to share the license.
For example, if sharing is specified as share=UH, then both the username and the hostname of a license request must match an existing checked-out license in order to share that existing checked-out license. If share is specified as share=u, then only the usernames must match on two processes in order for them to share the license.
The share= keyword accepts an optional maximum instance count which can share the license. To specify a maximum instance count for a license that is shared by user, use:
| share=U:nnn |
where nnn is the number of unique checkout requests (instances) which can share this license. The nnn+1st request will consume an additional license.
If the :nnn specification is omitted, any number of checkout requests can share the same license.
When to use Shared Licenses
Generally speaking, interactive applications are often the best candidates for license sharing. Consider the example of a software development tool that is designed to run many sessions on the user’s desktop simultaneously. By using “share=UH” a single license will be consumed regardless of the number of open sessions on this user’s computer. Consider another example of a multi-threaded simulation or solver application that is designed to spawn many copies of itself in order to solve complex problems. Sharing could be implemented in such a way that up to 5 instances spawned from the same processID (PID) would consume one license. The keyword would be share=I:5, where I is the inherited PID from the parent.