wyDay blog

Today we've released TurboFloat 4.3. The marquee feature of this release is that when your app uses the TurboFloat library your app can now release any active leases when a computer goes to sleep. And your app will also attempt to regain that lease when the computer "wakes up".

An example of a computer going to sleep is when your customer shuts their laptop:

The laptop is now asleep. If you were using TurboFloat in your app, and your app had a lease before the computer went to sleep, the lease would be dropped immediately. This frees up the lease to be used by any of that person's colleagues.

Humans are messy and unpredictable

This feature is just the latest example of our focus on real-world user-behavior. A customer isn't going to switch to every app they have open, see if it's using floating licensing, and if so, invoke whatever method you've created to drop the lease while keeping the app running.

That would be a nightmare; no one has time for that.

A real person is either going to just walk away from the computer (and the computer will put itself to sleep after a few minutes). Or the person will explicitly put the computer to sleep (for example by shutting the laptop).

Our job is handling this, and other real-world behavior, so you don't have to.

If you're not already using TurboFloat for your floating licensing, signup for LimeLM today (it's free to try — no credit card needed).

We're proud to announce that we've made it possible to sell your app on a per-process-instance basis. Meaning you can directly limit how many instances of your app your customers can run at any one time.

It's available now for all LimeLM customers!

This new per-instance lease issuance is the alternative to the per-user-session leases that TurboFloat Server issued by default. The differences between the two is shown in the gif above as well as described in "Fine-grained control: per-instance vs. per-user session leases":

With the release of TurboFloat 4.1 we added the ability to issue leases either on a per-process-instance basis or a per-user session basis. This gives you more control over how you sell your software and how it's used by your customers.

For per-user-session leases, one lease is issued per-user session on a machine (real or virtual) that is using at least one instance of your app. For example, "Sally Doe" starting your app on a shared server will be able to start multiple instances of your app and it will use that one lease regardless of how many instances they start in that user-session on that machine.

For per-process-instance leases, one lease is issued for every instance of your app started. Every separate process-instance of your app started will request a license lease whether the separate instances are in the same user-session or are in multiple different user-sessions.

So, how do you use it? Simple: first, make sure you're using the latest version of the TurboFloat Server and TurboFloat library (get them on your API page). Then create a new TurboFloat Server key (or edit an existing one) and select the "per-process-instance leases" option.

That's it. We handle the rest. Easy-peasy, lemon (lime?) squeezy.

TurboActivate and TurboFloat 4.1 are now out! This release is a huge leap forward in quality and features and sets the foundation for the new product releases that will be rolled out over the next 2 months.

So, wait no longer: get the latest TurboActivate and TurboFloat on your API page.

If you're not already a LimeLM customer, sign up now for free!

Here are the big "marquee" features of this release:

NodeJS support

We're proud to be the first commercial licensing to offer true hardware-locked (a.k.a. node-locked) licensing and floating licensing (a.k.a. concurrent licensing) for NodeJS. This means it's easier than ever to sell your NodeJS and Electron apps. You can write in pure JavaScript and let us handle all of the platform-specific details that need to be figured out for fast and accurate licensing.

Learn more over in our "Using TurboActivate with NodeJS or Electron" article (for hardware-locked licensing) and our "Using TurboFloat with NodeJS or Electron" article (for floating licensing). These articles and the accompanying example apps will show you everything you need to know to add true node-locked and floating licensing to your NodeJS app whether you're on Windows, Linux, macOS, or FreeBSD.

Which brings us to our next big feature:

Full, native FreeBSD support

In addition to supporting the "big 3" operating systems (Windows, macOS, and Linux) with this 4.1 release we've added support for FreeBSD! All of our products now run natively on FreeBSD 10.x and above (no Linux compatibility layer necessary).

You can download the latest versions on your API page in LimeLM.

TurboFloat Server behind HTTPS

Prior to this release of TurboFloat Server version 4.1, the TurboFloat Library and TurboFloat Server only "talked" over encrypted raw binary. This was perfectly fine when the TurboFloat Server was behind a corporate firewall and all of the "clients" existed in the same network.

Things got trickier when a corporate end-user decided to host their TurboFloat Server on a public facing computer and their employees ran your app from different networks. If they had a "direct" connection to the server running the TFS instance (whether on the same network or through a VPN), then everything worked fine. But things are rarely so easy in a corporation. Inevitably communications would need to go through a labyrinth of proxies. And, unfortunately, proxies rarely support "raw" transmitted data.

The solution is letting your app (using the TurboFloat Library) talk to the TurboFloat Server over HTTPS. Read more about how to do it here: Configuring TurboFloat Server for HTTPS communication.

Now corporate clients with complicated proxy setups (or anyone else) can have all of the communication happen over HTTPS.

Better client-side trial fraud detection, real-time trial expiration

We're also excited to add improved client-side date/time fraud to the timed-trials functionality in TurboActivate. We improve client-side fraud detection with every release of TurboActivate, but this version took a leap forward.

Additionally, we've added a new function "TA_SetTrialCallback()" that gives you real-time notifications of trial expirations and fraud. This means there's no more need to "poll" TurboActivate functions for the life-time of your process. Just, call that function once, and let TurboActivate handle it.

More consistent Linux ARM builds

Prior to this 4.1 release we made the following ARM builds of our products:

• armv4t, 32-bit little-endian, soft-float

• armv7-a, 32-bit little-endian, soft-float

• aarch64, 64-bit little-endian, soft-float

But we've found this doesn't match the use-case for most of our customers on these platforms, so we've added "hard-float" version for everything other than the armv4t target, and we've added an armv8-a, 32-bit build. So, here's our new targets:

• armv4t, 32-bit little-endian, soft-float

• armv7-a, 32-bit little-endian, hard-float

• armv8-a, 32-bit little-endian, hard-float

• aarch64, 64-bit little-endian, hard-float

What this means in practice is that you can sell your app and target distros like Raspian (and all other popular arm-based distros) without having to re-target your app for "soft-float" support.

A ton more...

In addition to the big features listed here, we have a ton of quality improvements and tweaks to provide a better experience for all end-users. Read a condensed list of changes here for TurboActivate and the changes for TurboFloat.