- Basics
- Getting started with LimeLM
- Types of software licensing
- What are Activations & Deactivations?
- How hardware-locked licensing and online activation works
- How to switch your licensing to LimeLM, TurboActivate, and TurboFloat
- Frequently asked questions (FAQ)
- Adding users to manage your LimeLM account
- Custom license fields
- Extra activation data
- Using TurboActivate
- Timed trials in your app
- Basics for TurboFloat (floating licenses)
- TurboFloat Server
- Using TurboFloat
- Advanced
- Account security
- Offline activation
- How to generate product keys after an order
- SaaS and time-limited licensing
- Proxies in TurboActivate
- Licensing multiple products per process
- Licensing from inside a virtual machine or hypervisor
- Web API
- LimeLM web API functions
- Overview
- Encoding
- Response Formats
- REST
- JSON
- feature
- add
- delete
- edit
- getAll
- pkey
- activity
- advancedSearch
- deactivate
- delete
- find
- generate
- getDetails
- getID
- manualActivation
- manualDeactivation
- removeTag
- revoke
- setDetails
- setTags
- prod
- getAll
- create
- createVers
- changeName
- editVers
- tag
- delete
- test
- echo
- trial
- advancedSearch
- manualVerifiedTrial
- trialExtension
- delete
- generate
- getDetails
- getID
- search
Types of software licensing
There are many types of licensing, and with these different types of licensing comes different ways to sell your app. This article will cover all of the major types of licensing, give you different scenarios in which you might use them, and how to use them in LimeLM.
Also, you can include all of these licensing methods in your app and choose which one to use at runtime. This means thereʼs no need to create separate versions of your app. This reduces your overall development costs.
Hardware-locked licensing (a.k.a. node-locked licensing)
Hardware-locked licensing “locks” your software to a particular computer. This means a customer that buys one license from you can only use your software on a single computer. If the customer tries to use your app and that product key on another computer, then they won't be able to activate your software.
TurboActivateʼs proprietary “hardware-fingerprint” technology can tell if the customer is trying to activate on other devices. It can accurately differentiate between having two completely separate computers versus having one computer that has just had minor hardware upgrades (and is really the same computer). And, it can do all of this without you having to mail your customers a separate “hardware-dongle”, which reduces your costs dramatically.
How hardware-locked licensing works in LimeLM
The way to add hardware-locked licensing to your app is to include TurboActivate in your app. After adding TurboActivate in your app, the process of locking licenses to a specific number of computers looks like this:
A customer goes to your purchase page (or however you want to sell customers your software).
After the customerʼs order is verified, you generate a product key in LimeLM, specify the number of allowed activations, and then send this product key to the customer.
They enter the product key in your app and press the “Activate” button.
In the span of less than a second, TurboActivate locks that product key to that particular computer with the following steps:
It generates a “hardware fingerprint” to uniquely and anonymously identify the customerʼs computer.
This product key and the computerʼs unique “fingerprint” are sent to an activation server.
If the server allows the activation, then the product key and fingerprint are cryptographically signed (so they cannot be modified) and sent back to the user.
Based on this cryptographically signed block, your app or installer will know whether the user is allowed to use your application or not. And it can do this cryptographic-verification without needing to be connected to the internet.
A more detailed view of how LimeLM and TurboActivate locks your app to a particular computer is covered in the “What is hardware-locked licensing and why choose LimeLM?” article, specifically the section titled: “How hardware-locked licensing works”.
Why choose TurboActivate over TurboFloat?
The main advantage TurboActivate (node-locked licensing) has over TurboFloat (floating licensing) is the simplicity of the TurboActivate interface and functionality. With TurboFloat, the customer needs to install a separate TurboFloat Server somewhere on their network, and then, inside your app, configure the TurboFloat library to connect to that TurboFloat Server.
With TurboActivate, the customer just enters a product key, presses an “Activate” button, and TurboActivate “magically” handles all of the details.
So, TurboActivate is the best choice when you want a simple method to make sure customers are running on the number of computers that you specify. With this feature, you will also be able to control whether or not your clients are able to move licenses between computers).
Floating licensing (a.k.a. concurrent licensing)
Floating licensing using TurboFloat, like hardware-locked licensing using TurboActivate, also uses our proprietary algorithm to determine “hardware-fingerprint” of the device to limit who can use your app. The difference between how floating licensing (TurboFloat) works and how hardware-locked licensing (TurboActivate) works is in how a customer uses your app:
With TurboActivate, a customer installs your app on a computer and tries to activate your app on that computer with a product key you generate and send to them. One of two things can happen:
If there is 1 or more unused “activation slots” left for that product key, then the activation will succeed and that customer will be activated on that machine with that product key.
If there are 0 unused “activation slots” left for that product key, then the customer will not be activated and they won't be able to use that product key on that computer. When this happens, you will then have the chance to prompt your customers to buy more licenses.
With TurboFloat, a customer must first activate and install the TurboFloat Server on a computer on their network. Once the customer has installed and activated the TurboFloat Server, the server has a “pool” of “license leases” (i.e., the maximum number of instances of your app that can run at any given time), the size of which you specify when you create the product key. Then they can install your app on as many computers as they want. When a user launches your app, the following happens:
Your app, using the TurboFloat library, tries to connect to the TurboFloat Server that the customer activated and installed on their network. If your app can successfully connect to the TurboFloat Server, it requests a “license lease” from the TurboFloat Server instance. One of two things will happen:
If thereʼs 1 or more “license leases” left in the “pool” then your app will get that “license lease”. This also means there will be one less “license lease” left in the “pool”.
If there are 0 “license leases” left in the “pool” then your app will not be able to start.
When the user closes your app it releases that “license lease” back into the “pool” so that it can be used by other users in that network.
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.
Advantages of TurboFloat over typical floating licensing
TurboFloat goes above and beyond the run-of-the-mill licensing you can buy from other licensing companies. We care about the little details. A few of the details that set us apart from the competition:
License lease per-user-session or per-app-instance: With other floating license software you're only able to limit users to a lease per-machine. With us (using LimeLM and TurboFloat) you can require leases either for every user-session on a machine or for every instance of your app that your customers launch. We describe the differences above.
Either of those choices allows you to increase your revenue and have greater control over how your apps are used by customers. One real-life example is you can increase your profits from customers running your app on Citrix / Terminal Services (TS) / Remote Desktop Services (RDS) type machines (where multiple users run apps from a centralized computer).
“Zombie-lease” prevention: With licensing from other companies, a “zombie-lease” occurs if your app requests a license lease, and then your app crashes sometime before the lease expires. When this happens, the zombie-lease takes up one of the license leases from the pool even though no instance of your app is using it. With TurboFloat, under most circumstances, when your user re-runs your application on that computer under that user-session they'll be able to pick up where they left off with that same license lease. This feature increases customer satisfaction, which ultimately saves you time and money in reduced need for customer support.
Handle Virtual Machines (even if they're cloned): If you use TurboFloat in your app you'll be able to prevent users who clone Virtual Machines in order to steal “free” licenses from you. TurboFloat differs from typical floating licensing in that it is uniquely designed to handle virtual machines even in cases where the machines are cloned bit-for-bit, which protects your company against fraud.
Why choose TurboFloat over TurboActivate?
There are a handful of reasons why you might want to choose floating licensing (and using TurboFloat) over using the more traditional hardware-locked licensing (and using TurboActivate). Here are the biggest reasons:
The most common case is when your customers need a “pool” of licenses to be used across many computers. For example: a large university that has hundreds of thousands of computers but only want 50 instances of your app to run at any one time.
If your customers are running your app on Citrix / Terminal Services (TS) / Remote Desktop Services (RDS) type machines and you want them to buy more than just a single license.
If the customer is in a completely locked-down network where no traffic is allowed inside or outside of the network, and anything generated on the computer is considered “confidential” or “classified”. With this functionality, customers can protect their information by only having it communicate with the TurboFloat server instead of directly with the LimeLM activation servers.
When the customer will be installing your software on virtual machines, and you want to prevent casual piracy by way of virtual machine cloning.
Named-user licensing (a.k.a. per-seat licensing)
Per-seat licensing is a variant of floating licensing. The only difference is that with typical TurboFloat Server licenses, any user in the companyʼs network (or any user who has access to the TurboFloat Server) can request license leases from the TurboFloat Server. With per-seat licensing you specify exactly which usernames are allowed to request license leases from the TurboFloat Server:
Why choose named-user licensing over typical floating licensing?
You might choose to use named-user licensing if you want all the benefits of the floating licensing plus you want to further limit who runs your app to specific usernames inside a company. This gives you another way to control who uses your application (and a way to sell more licenses).