Category: Uncategorized

101 License Models – Nodelocked Licenses

Restricting Usage: Nodelocked Licenses

A while ago, we wrote a blog post titled 101 license models, and a followup on unrestricted license models.  In this post, we explore the second set of license models described in that post – Nodelocked Licenses.  To review, the Nodelocked Licenses we described are:

  • 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

Because these licenses are locked to a machine or user, they are more restrictive than the previously-described unrestricted license models.

You use nodelocked licenses when you want to restrict how and where your software is used.  Since nodelocked licenses do not require a license server, your customer is up and running with a minimum of fuss.

What you can do with Nodelocked Licenses

With nodelocked licenses, you have quite a bit of flexibility – you can:

  • allow any user running your software on the nodelocked machine access,
  • allow only a single copy of your software to run on the (specified) machine,
  • provide an expiration and/or a start date for the license,
  • create options so that you have an opportunity to upsell to your customers,
  • specify that the license is not usable on a virtual machine,
  • include the customer name, for use in a startup screen.  This often deters software theft.

Sometimes our customers use user-locked licenses, which are locked to an operating system’s notion of the user name rather than the computer’s hostid.  While it is possible to have multiple humans logged in as the same user name, this can be inconvenient for certain applications.

In addition to all these options, you can also upgrade a license to a newer version when a customer stays on maintenance.

We will explore the other main License Model categories in future blog posts.

101 License Models – Unrestricted License Models

Unrestricted License Models

A while ago, we wrote a blog post titled 101 license models.  In this post, we will explore the first set of license models described in that post – the Unrestricted License Models.  To review, the Unrestricted License Models we talked about are these:

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

These licenses are not locked to any machine or license server.  In other words, they work anywhere.  So, given that a customer can use as many of these licenses as they want, why would you ever want to use one of these?

One reason may be that you want to restrict how a license is used, as opposed to how many copies of that license can be used.  At Reprise, we license RLM to an ISV, but we do not restrict how many develpers can use the development kit, nor do we restrict how many copies of their application that can be used.   We do this by using an unrestricted license model – we lock the RLM license to the ISV’s short name (what we call the ISV name).  Once “out in the world”, a customer can only have software from one ISV of a particular name, so multiple companies would not use the same ISV name to license their software.  This provides sufficient licensing protection for our software.  A customer who has purchased an RLM license would get a permanent license with this ISV name, whereas a demo customer would get an expiring license with an ISV name of “demo”.

Another Reprise product that is licensed in this way is our Activation Pro product.  This is a server-based product, and the real value comes from having a single server that activates the licenses for an ISV’s customer, but we allow our ISVs to run multiple copies of this server, primarily so that they can do testing on a second installation.

Similarily, a product could display a customer’s name in a splash-screen.  Most legitimate businesses would not want another company using software that was licensed to them by name.

Frequently, our customers use user-locked licenses, which are locked to an operating system’s notion of the user name.  While it is possible to have multiple humans logged in as the same user name, this becomes inconvenient.

Also, ISVs might license their main program using floating or node-locked lienses, while some ancillary program or utility uses one of these unrestricted license models so that there is some amount of control, but provides convenience to their customers.

We will explore the other main License Model categories in future blog posts.

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

Token-Based Licenses, part 2

Advanced Use of Token-Based Licenses

Last time, we discussed how to license all your products as a function of a single base license, by using a Token-Based License.  Today, we will talk about the other 2 uses of token-based licenses:

  • create product bundles or packages (much like Package licenses), or
  • let a user consume a more-expensive alternative license when a more-common product is unavailable

If you want to create a product bundle called “office”, and that the components of this bundle are “write”, “calc”, and “present”, you would proceed as follows:   your 3 products would each check out the appropriate license (write for write, calc for calc, and present for present). To create the product bundle, you would create 3 token definitions for the 3 individual components:




These token definitions define how the products are packaged together, and don’t vary from customer to customer. Now, when your customer buys the office product, you issue them an office license, like this:


This license allows 6 copies of the office package to float on your customer’s network.   If the same user uses both write and calc, they still only consume a single license due to the share=uh specification in the office license.

As we said before, the best part is that you don’t have to do anything special to start using Token-Based Licenses. You implement the RLM API as you would for any supported license model. No need to create a second version of your product to support Token-Based Licenses – it’s built in.  In each product, check out a license that is specific to that product, for example, “write”.

For another example, let’s say that you sell both write and writerPro licenses, where the writerPro license includes all the functionality of write, plus more.   If your customer has both write and writerPro licenses, they may run into the situation where they are using all their write licenses, and the next user wants to use write, but no licenses are available and yet there are unused writerPro licenses.

If you define a token-based license for write that uses the writerPro license, then your customer can use the more-expensive writerPro license to run write.  That license would look like this:


Of course, they would need to have both write and writerPro licenses available for this token definition to do any good since the TOKEN license itself doesn’t authorize any license usage, it is simply a mapping from one checkout request to another.  And in this case, they would want the licenses to be in this order:

  • write license
  • write token definition
  • writerPro license

This order ensures that requests for write first use the write licenses, then if none are available, they would use writerPro licenses.


Software License Management and The Dongle

Software License Management and The Dongle.

Dongles have had a long and checkered past when used for Software Copy Protection and Software License Management. In the 1980’s and 1990’s ISVs selling high-value desktop and/or workstation class software to scientific and engineering customers needed to “lock” their software so that it can’t be shared with others.  If even a single unlicensed copy is used,  a serious revenue hit would result.  What to do?

Dongles provide serial number to lock licenses
Along came the dongle.  Well, it wasn’t originally called a dongle. It was a “hardware key” or “security key” or “security block”, and many other names including product names like hasp. In any case, the dongle, as it is now commonly known, was a solution to the software locking problem. It was a primitive physical device consisting of some simple electronics that, when queried through software, returned a factory-preset serial number to which a software product could be tied. This was a boon to software developers who at the time were experimenting with using, of all things, floppy disks as keys.

Weaknesses soon found
But, as soon as the use of dongles became more widespread, inherent problems surfaced.  Early dongles used parallel printer ports of the PC (remember those?).  Dongles were designed to allow printers to connect pass-thru style, but since these ports often had non-standard electrical characteristics including power differences, dongles sometimes failed in the field.

Failed dongle == failed software.  Not good.  So, ISVs kept FedEx and UPS busy, sending overnight dongle replacements – the cost of the overnight trip exceeded the cost of the dongle. Other problems surfaced too: dongles were lost or stolen, users failed to install updated software drivers to keep up with OS revisions, the dreaded dongle-snake appeared (so many dongles chained together that they literally fell off the PC), etc.

Along comes PC networking
But the biggest factor in the dongle’s demise was the arrival of PC networking.  Once networks became popular, software could be tied to the hardware address of the ethernet communication card. Licenses began to be shared over the network as software license managers (like RLM) exploited the power of interconnected users to allow even casual users access to valuable software licenses.

Dongles still solve license mobility problem
So, dongles waned in popularity as a general solution for licensing software, but they found a new use – to lock the license manager’s license server to a computer.   Dongles allow the license server to be moved by the end-user without involvement from the software publisher.  Also, today, dongles are much cheaper, more reliable and are usually connect via USB ports – making them easy to attach to a modern PC.

Today’s floating license management and dongles
Floating licensing provides a mechanism for licenses to be shared among networked users. The whole license pool can be locked to a single server using either the server’s host ID or a dongle acting as a proxy for the server’s ID. In this way the license manager encodes the dongle’s serial number as part of the pool of licenses

Software License Management and The Donglethat it serves. By using advanced functionality in license managers, like the concept of “roaming” in the Reprise License Manager, the user can disconnect his laptop, and take his licensed software on the road temporarily while the licenses appear to be “in use” back at the office. When he returns to the office, his license is put back into the pool for all users to share once again.


Supporting Virtual Machines
In addition to the mobility advantages of dongles, virtual machine software dedicates the USB port to a single VM instance, so using a dongle is a good way to lock a license server to an instance of a virtual machine, without worring about the license server being replicated across the network.

Dongles are still an important part of a complete software license management strategy, and will likely remain so for some time.