Author: staff

Engineering Technology Associates (ETA) Upgrades to the Reprise License Manager (RLM)

ETA switches to RLM

ETA switches to RLM

ETA had used an in-house proprietary license solution for many years. With a growing customer base and increasing complexity of its product portfolio, there is new demand for a more flexible and more reliable license system.

After evaluating several licensing products, ETA found that RLM met all of its requirements:

  • Cross platform (Windows, LINUX/UNIX and Mac OS)
  • Advanced network license server (failover, roaming and token)
  • Convenient tool for users to manage the license server
  • Flexible license policy to fit various users

The integration of RLM into ETA’s software products went smoothly. With an extensive API and a very responsive support team, ETA streamlined its licensing system with RLM quickly and easily. Several helpful new licensing features were added to ETA’s newest releases using RLM’s enriched functions.

About ETA

Advanced product development engineers working as structural analysts for the world’s largest automotive manufacturers established Engineering Technology Associates, Inc. (ETA) in 1983. ETA’s expertise in the areas of vehicle durability, NVH, metal forming, crashworthiness, occupant safety and product design have provided an intimate knowledge of the challenges and needs of the product development engineer. Proactive in the creation and implementation of new analysis methods and solutions, ETA is also the developer of the Inventium Suite, PreSys, VPG and DYNAFORM software solutions.

Using a License Manager as a Load Balancer

(or, if all you have is a hammer, everything looks like a nail)

Introduction – The Problem

At Reprise Software, our main product, the Reprise License Manager (RLM) runs on many different platforms (19 at last count). Since our product is a client-server product with an API, we have a set of regression tests that we run both during development and at each release.

One issue of testing a license manager is the desirability to run tests that both succeed in checking out licenses from a license server as well as tests that fail. Given that our product (RLM) is inherently a network-based product, and also given that clients can broadcast to discover a license server, our experience is that running regression tests on multiple machines on the same network at the same time will result in some number of checkouts succeeding that should have failed.

In the past, we have worked around this problem by timing the starts of our regression tests suites so that the individual tests would not overlap each other and yield incorrect results (in this case, incorrect results from the test environment, not from software faults). While this works fine in a development environment, it is extremely awkward during a release cycle when the goal is to build and test many platforms simultaneously.

The Solution – License Management

Since the regression tests are primarily run by a single user, the solution was to create a set of licenses, one per test, then use the License Manager as a Load Balancer to serve them with a single instance per license, nodelocked to the username of the person running the test. Each test checks out it’s own license, and if the license request is queued, the test waits until granted. Now, the tests synchronize across all platforms with the same test never running on multiple platforms at the same time. Different sets of licenses are served for different network segments.

We serve the licenses using RLMCloud, so that the license server is always available, even when development machines go down.  An extra benefit is that our normal regression tests also test the RLMCloud servers at the same time. Win win.

Remembering Daniel Birns

Daniel Steven Birns, Jan 18, 1954 – July 28, 2016

It is with great sadness that we have to say goodbye to our dear friend, Daniel.Remembering Daniel Birns

Some of you may know Daniel as “the FLEXlm support guy”.  Others may know him as the lead FLEXlm developer.  Many more (outside of GLOBEtrotter and Reprise) know him as an extremely talented musician, one who never seemed to find an instrument that he couldn’t master quickly.

We knew him as a dedicated, enthusiastic co-worker, a good friend, and a dedicated husband and dad.

I first met Daniel in 1993, when we were porting FLEXlm to the 88k processor.  Daniel worked for 88open, the industry consortium, and when I contacted them for help with the port, he said “I’ll just come over and help you”.   Well, he did, we went to lunch, and during lunch I realized that I needed to hire him to support FLEXlm.

Within 3 weeks of Daniel’s arrival, it was clear that it was a waste to have him only supporting the product, so I made him the lead developer, and the 2 of us continued to support FLEXlm.  Daniel remained the lead developer from 1993 until 2000.  During this time we had many, many good-natured knock-down, drag-out fights over the direction of the product, but the result in every case was an improved product.  When we sold GLOBEtrotter to Macrovision in 2000, Daniel remained lead developer for a year or two, at which point, he left to spend more time with his music.

While Daniel never worked at Reprise, we always stayed in touch and of course, many of us saw him at several of the GLOBEtrotter reunions.

Daniel, we’ll always love you and miss you, and we hope you are in a better place.

Matt Christiano

101 License Models

101 License Models – a license model for everyone.

License Managers are known for providing flexibility in how you price and license your software.  This blog post discusses 101 license models available to you with the Reprise License Manager.   These models fall into 5 main categories – Unrestricted, Nodelocked, Floating, Token-Based and Metered License Models.  We have discussed some of these in the past, and will talk about others in future blog posts.

So here we go…

Unrestricted License Models

These license models are not locked to any machine or license server.  In other words, they work anywhere.  Often these are appropriate for demo licenses or if you want to be able to display something about the license in a startup dialog, but allow it to run anywhere. Unrestricted licenses can have any of the following attributes:

  • any
  • customer name
  • demo
  • expiring
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • permanent
  • serial number
  • software version
  • user-locked
  Nodelocked License Models

These license models lock the license to a particular computer, and in addition provides other restrictions.  Nodelocked licenses can have any of the following attributes:

  • uncounted
  • computing environment limited
  • customer name
  • detached demo
  • expiring
  • single
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • permanent
  • platform-limited
  • software version
  • timezone-limited
  • upgrade other licenses
  • user-locked
  • VM enabled
    Floating License Models

Floating licenses are the most common usage of a license manager.  These are usable by anyone who can contact the license server.  The floating license models provide the richest set of license control.  Floating licenses can have any of the following attributes:

  Token-based LICENSE MODELS

token-based licenses are a special case of floating licenses which allow aliasing of a license or multiple license checkouts per request.  These are usable by anyone who can contact the license server.  Token-based licenses can have any of the following attributes:

  Metered license models

Metered licenses provide a “postage meter” type of licensing model. Metered licenses work either with pre-paid or post-use payment.  Metered licenses can have any of the following attributes:

  • per-hour
  • per-invocation
  • per-event
  • computing environment limited
  • customer name
  • expiring
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • password-protected
  • permanent
  • platform-limited
  • replace other licenses
  • software version
  • timezone-limited
  • user-locked
  • VM enabled

License Management as a Pricing Tool

Using License Management as a Pricing Tool

Do you want to maximize revenue while pricing your software in ways that make sense to your customers? A software license manager, such as the Reprise License Manager (RLM), is an indispensable pricing tool that can help you to design and enforce pricing models that are right for your customers, while giving you the flexibility to quickly adapt to new sales opportunities.

A License Manager Gives you Flexibility and Control
When a license manager is properly integrated into your software, it is able to interpret and enforce virtually an unlimited number of licensing and pricing schemes. You implement your licensing polices primarily by:

  • specifying parameters in your licenses, and
  • deciding how to handle unsuccessful license requests (to deny or permit use).

These two levers allow you to customize your license policies by product, customer type, location, etc.  You don’t need to maintain unique software builds for each case because licensing is mostly controlled by the license manager.  This also means that you are poised to quickly revise your policies to react to new business opportunities that crop up – without having to re-release your software.

What should I license?

First, you have to decide what to license. Usually applications are licensed as a whole using a single license, but in some cases you may want to license additional extra cost features. This helps to keep the price of your basic product low, while collecting extra revenue from the customers who value the advanced functionality. You may want to take this concept a step further to create multi-product “bundles” that correspond to common user types, or even support a tiered pricing model with “Basic”, “Advanced” and “Pro” versions to add greater pricing depth.

Which types of licenses?
Determining the right licensing model requires an understanding of how your customers use your products.  If your application is dedicated to a specialized niche purpose, you can use a named-user or node-locked license.  On the other hand, if the product is meant to be widely shared or used collaboratively, you might want to use floating or concurrent licenses.  If you support both types of licenses, then you can usually charge a price premium for the floating license, since it provides more value to your customer.  Price premiums can range from as little as 10-20 percent to a factor of three or more, depending on the type of software and how it is used. In general, it’s best to offer multiple license types because it helps you to deepen your account penetration by reaching more user types.

What is a “user?”
Defining the term “user” may sound like a strange exercise, but its meaning 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.  Question: should the same user on the same machine consume only one license of your software regardless of the number of copies he uses concurrently? Also, should a floating license that is used for only a short duration be allowed to return to the license pool immediately, or should the license manager force a delay to encourage the sale of more licenses.  As you can see, defining a “user” accurately is extremely important.  When defined properly in both your software license agreements and within your technical implementation you avoid confusion with customers about the scope of your licenses.

Should licenses expire?
Obviously, if you settle on using a subscription licensing scheme, you’ll want your licenses to reflect the paid license period, but even if you sell perpetual licenses, you may want to limit the duration of the license (start and end dates) so that licenses require periodic refreshment in the field. This can come in handy when you make wholesale changes to your pricing/licensing model at some point in the future (including switching license management vendors) – knowing that at a certain date, all old licenses will eventually expire.

Should licenses match a specific product version?
Although version numbers in licenses can restrict which application version can run, most publishers prefer allowing older versions of software to consume newer licenses, but not the reverse. Some publishers creatively use license version numbers to manage support contract periods.  For instance, a license that specifies a version of “2018.0101” would support any version of the application released before January 1, 2018. New licenses (with new “version dates”) are issued only to customers who renew their maintenance. Used in combination with a license expiration date, a license could permit permanent access to the latest version released during the user’s most recent paid maintenance period – without the license itself ever expiring.

“Post-use” licensing model
Another new source of revenue might be aimed at those customers who would rather pay for your software based on their actual measured usage. Again, a license manager is the perfect pricing tool for this because it can capture the details of the customer’s usage history allowing you to build accurate invoices weekly, monthly, or quarterly.  You could use a “post-use” model on a customer by customer basis, maintaining it as a revenue-positive alternative to your traditional licensing models used for the majority of your customers.  Perhaps you could sell a base level count of floating licenses to a customer, then use “post-use” billing to handle peak over-usage situations.  This creates extra revenue for the publisher and allows the customer to continue working during unusually busy times.

We’ve only scratched the surface here, so if you would like to discuss how license management can address your particular requirements in more detail, please contact us.

Shared Floating License

Count unique users of your application with the Shared Floating License.

We’ve discussed the floating license in a previous blog post.  A floating license allows a specified number of independent instances of your application to run anywhere on your customer’s network so long as that number does not exceed the predefined limit specified in the license.  But what if you want to allow each user to run multiple instances of your product, while still limiting the number of users who can access the product at the same time?  The Shared Floating License works well in this situation.

With a shared floating license, separate program invocations from the same user (or the same user on the same host) consume only a single license.

To implement a shared floating license in RLM, specify a license server with the SERVER line, and set the count field of the license to a positive integer.  The license itself has no associated hostid, meaning that it will run anywhere. The license should also have a “share=” attribute, and the value is any combination of the letters “u”, “h”, and “i”.

With a shared floating license, you have a good bit of control over the actual sharing of the license.  You can share the license across invocations of your product that have the same:

  • username
  • hostname
  • isv-defined string

or any combination of those 3 parameters.  So, for example, you can share a license requests from the same user on the same host by specifying the share= parameter of the license as “share=uh“.

In addition, you can limit the amount of sharing that is allowed.  For example, if you want to allow up to 5 invocations from the same user to share one license, but the 6th invocation to consume an additional license, specify “share=u:5“.

Shared Floating Licenses work well for interactive applications where the user will naturally bring up multiple copies to get a job done.  In this case, consuming a single license for multiple invocations seems like a natural and fair way to license your product.

 

Named User Licenses

Named User Licenses – Let your License Manager build user lists dynamically

Floating licenses are the most versatile of the license types. When available, anyone on the network with access to the license server can get a license to run. This is tremendously powerful for the software user, but there are times when software publishers want to sell the convenience of floating licenses while enforcing a more restricted license model. Named user licenses do just this by restricting access to users who are on a list.

Business Benefits
The benefit of named user licenses to the software user community is that their regular software users will not have to contend with other users for licenses. The licenses are in effect dedicated to the group of named users.  These licenses may also be less expensive than floating licenses. The publisher, on the other hand, benefits because he can sell named user licenses, perhaps at a lower cost, that better match the spirit of his license agreement.  If he chooses, the publisher can still sell unrestricted floating licenses, but at a premium to the named user type.

Names can be Dynamically Assigned
In Reprise Software’s RLM, named user licenses allow publishers to require that user names be included on a list in order to use the licenses. The list can be assigned by the system administrator, or RLM can create the list “on the fly.” The number of users in the list can be less than, equal to, or greater than the number of licenses available – all at the publisher’s option. Once a user is added to the list, he can be deleted, but once deleted, he must remain off the list for a minimum number of hours (24 hours by default). This prevents the manipulation of the system in an effort to defeat the named user license policy.

If the number of named users is smaller than the number of licenses, then this small group will share the larger pool (assumes that it’s feasible for a single user to consume more than one license at a time).  If the number of named users is greater than the number of licenses, then the larger pool of named users will contend for the available licenses.

The “How To”

To deploy a named user license, the publisher does not need to modify his RLM-enabled application at all; it’s controlled in the license certificate itself.  To create a named user license the named user keyword is simply added to a standard floating license certificate, in one of the three following ways:

named_user – to require the same # of users as there are licenses
or
named_user=n – to require a maximum of n users to be named
or
named_user=”n min_hours” – to require a maximum of n users to be named, and to specify the minimum number of hours before the deleted user name can be re-added back to the list.

Managing the List
As was mentioned earlier, the license server can construct the list of users automatically as license checkouts occur, or the list can be entered via the RLM web interface by the end-user administrator. If entered manually, either individual user names or GROUP names (as defined in the server options file) can be used.

Named user licenses utilize the INCLUDE functionality of the license server, and do not need a fully populated list of users before the licenses can be used. In fact, no users need to be specified since the license server will add users who do not appear on the list if the current list size is less than the number of allowed named users.

Best Practices for License Management

Best Practices for License Management

Time spent paying attention to best practices for license management will pay dividends down the road in customer satisfaction. Following a few basic guidelines will be greatly appreciated by your end-users who will see more consistent implementations from ISV to ISV.

Let’s dive right in:

The Product name you use to check out a license for a product should be as close to the name of the product you sell as possible. We consider it best practice to use the name of the product from your price list.  This is probably the most important thing you can do in your implementation.

In practice, it’s often quite reasonable for ISVs to use multiple license names in an application – just keep it within reason. A good rule of thumb is to use a new license if you charge separately for that feature.

Fewer checkouts per product are generally better from an end-user support and understanding standpoint. In the early days of license management, companies literally “went crazy” adding license checkout calls to smaller and smaller pieces of their application, which resulted in several licenses required to run one product. Resist the temptation to do this.

Installation of Your Product and Finding the Licenses

When you integrate licensing into your product, you need to think about how you will deliver the licenses for it to operate. A large percentage of support calls occur during the installation of the software application. One way to decrease the support burden is to make the installation of the license file as seamless as possible.

For less complex applications deliver the license via automated Internet Activation, such as Reprise’s Activation Pro.  This can make for a much easier installation experience for the end-user.

For more complex applications manually delivering the license may be the best option. Delivery of the license file via email or downloading it from a web support location may be more appropriate. Make sure that it is clear where the license file should be saved.

It is also critical that the application be able to locate the license file at runtime. When Integrating RLM into your product there are a few ways that your application and license server can locate the licenses they need to operate. We provide a “best practices” section in the RLM Reference manual that outlines the best way to define the parameters for defining the license file location. If you follow this advice, you will have a better end-user experience.

Best Practices for License Roaming

A common floating license option provided to end-users is License Roaming. Increasingly, users want to take their work “on the road.” RLM’s built-in license roaming capability allows users to check out a license from a server, physically disconnect from the server and continue to use the license for a specified number of days on their notebooks or laptops, after which the license is automatically returned to the server. Again, no extra work is required beyond enabling roaming in the license file. As an ISV, you control whether licenses are able to roam, and how long they can be checked-out in the disconnected state.

RLM license roaming was designed to allow ‘disconnected’ use for short durations up to a few weeks.

Best Practices for Product Evaluations/Demos

One compelling value of software licensing is to provide a way to promote and market your application to prospective buyers. You should provide demo or evaluation licenses to your customers. Here is a brief summary of best practices for this scenario that can help increase sales.

  • Expose all functionality to the user – even if you limit scope of use, show the user what could be possible.
  • Show “number of eval days remaining” on the start-up screen – creates user urgency and an expiration date creates timetable for sales follow up.
  • Always remind the user how to buy, even after the eval has ended, by providing a link to information on how to buy
  • Do not require the software to be re-downloaded or reinstalled when upgrading to a paid license – this is one key value of a license manager.

One of the primary goals of software licensing is to increase revenue opportunities. In order to maximize the efficiency of software licensing, it is critical to spend time in planning and design. Various license models can be utilized to increase revenue opportunities and varying degrees of security can be incorporated. It is also important when implementing software licensing, that the end user’s interaction be considered.

A software License manager like RLM is an indispensable tool that can help you to design and enforce pricing models that are right for today’s customers, while giving you the flexibility to quickly adapt to new opportunities as they emerge.

Increase License Server Capacity with Disconnected Use

Cloud Computing Highlights the Need for Increased Server Capacity

Last time, we talked about how an increasing number of software vendors are hosting license servers in the Cloud for their end customers and how client-side caching decreases the load on the license server.  Another requirement for license servers in the Cloud is the ability to serve more clients than a traditional on-premises license server.

To address this challenge RLM supports “disconnected use.”  While a normal RLM client application requires a socket to remain open to the license server for the lifetime of the license checkout, with “disconnected use” the socket is closed after the initial checkout, and only re-opened when the application performs a heartbeat to the license server.

Since RLM v10.0, “disconnected use” allows software vendors to initialize RLM in a way that sets communications with the license server to a “disconnected” mode.  Our internal testing indicates that a license server can support roughly 10 times the number clients using disconnected operation, as compared to the usual connected operation.  The limit with disconnected operation is generally reached when the server can no longer process heartbeats from all the clients in a timely manner.

For a more detailed technical description of this feature, including some performance guidelines, please refer to the RLM Reference Manual section entitled “Disconnected Operation.”

Client-Side Caching Improves Licensing Performance

Cloud Computing Highlights the Need for Client-Side Caching

An increasing number of software vendors are hosting license servers in the Cloud for their end customers. The longer physical distance between client and the license server introduces more network latency.  License checkout times may be slower over these longer distances compared with those over a local area network. Applications with short duty-cycles or massively parallel applications that require frequent checkouts over a short period of time are affected the most. To address this challenge RLM supports “license caching” on the client.

Since v10.1, RLM lets software vendors create licenses that specify a “cache time” in seconds so that when licenses are checked out, RLM will create a cached license on the local client machine.  If the same user on this host subsequently checks out the license before the cache time expires, then the local cached license is used, avoiding a connection to the license server.

To use caching, the license must specify the keyword “client_cache=N” where N is duration of the cache period in seconds. Any license with a client_cache specification is treated by the license server identically to a license with a min_checkout specification.

For a more detailed technical description of this feature, please refer to the RLM Reference Manual section entitled “Client-Side License Caching.”