Home » Uncategorized

Category: Uncategorized

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:

LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<office 1.0 1>”

LICENSE SOFTWARE_CO calc 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<office 1.0 1>”

LICENSE SOFTWARE_CO present 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<office 1.0 1>”

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:

LICENSE SOFTWARE_CO office 1.0 PERMANENT 6 SIG=XXXX share=uh

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:

LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<writerPro 1.0 1>”

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.

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