- 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
Licensing from inside a virtual machine or hypervisor
Virtual machines (like VMWare, VirtualBox, Parallels, Xen, Microsoft Hyper-V, etc.) allow customers to copy a fully configured "machine" bit-for-bit and run these copies simultaneously on as many machines as a customer wants. With typical hardware-locked licensing, when a customer activates on a virtual machine then they can use your app over and over again on every virtual machine instance without paying for extra copies of your app (because the virtual machines "look" identical).
This article shows you how to sell licenses for each individual VM instance, by using TurboFloat, even if the virtual machines are copied bit-for-bit.
Use the latest version of TurboActivate
The first step is to use the latest version of TurboActivate in your app. If you're new to LimeLM, then the "Getting started with LimeLM" article is a good place to start. If you've used TurboActivate before and you've already integrated TurboActivate in your app, then get the latest version of TurboActivate on your API page.
Step 1. Disallow VM activations
After integrating the latest version of TurboActivate into your app, the way to get paid for every copy of your app is to disallow Virtual Machine activations. Why? Because for customers on virtual machines, you'll want them to use TurboFloat, which is specifically designed to handle virtual machines (among other things). More on this later.
Why disallow VM activations?
There are two reasons why you should disallow activations on virtual machines by default.
The first reason you should disallow virtual machine activations is that when a customer activates your software on a virtual machine, the "unique fingerprint" that TurboActivate uses is of the VM instance (and not the computer the VM is running on). Meaning, the customer can copy the virtual machine instance to another computer and TurboActivate will still see the VM's fingerprint and not the "base computer's" fingerprint.
In other words, if you let your customers activate your software on a virtual machine they can then copy that virtual machine as many times as they want.
Another reason why you should disallow VM activations is that on certain "cloud VM providers" like Azure and Amazon Web Services, whenever you reboot the machine the VM instance is started on a different underlying physical machine, and thus the "computer fingerprint" changes. This means that a customer that is activated on one of these machines, reboots the machine, they suddenly become deactivated.
TurboFloat solves both of these problems (see "Step 2" below).
Possible exceptions
There are a couple of cases where you might want to make exceptions and allow customers to be activated on virtual machines:
For whatever reason you can't include TurboFloat (the floating licensing) in your product.
Your customer is stubborn and/or unwilling to install TurboFloat Server on a physical machine. So, for example your app can be used on servers and the customer is running on a virtualized server (Amazon EC2, Linode, Rackspace, Xen hosted servers, etc.) and they don't have a publicly facing "hardware" (non-virtualized) server to run TurboFloat Server.
Although, it should be noted, if you allow a customer to activate your software on a system like Amazon Web Services, and they ever reboot that machine, the "underlying physical machine" of the VM will change, and thus the fingerprint of the VM will change as well.
Allow / Disallow VM activations at the version level
When you create or edit a product or version in LimeLM you have the option of setting whether to allow virtual machine activations:
Set this value to whatever you want the "default" behavior to be for product keys.
Allow / Disallow VM activations at the product key level
You can override the default behavior set at the product / version level when you create or edit product keys:
The options for allowing or disallowing virtual machines on for each product key are as follows:
Default: This product key will always inherit the value set at the version level. Even if you change the version value later (e.g. from "allow VM activations" to "disallow VM activations") then the product keys with this "Default" setting will inherit this change immediately.
Disallow: This product key won't be allowed to be activated on virtual machines regardless of what the version default is set as.
Allow: This product key will be allowed to be activated on virtual machines regardless of what the version default is set as.
Step 2. Use floating licenses (TurboFloat)
The way to make money selling to customers who use virtual machines is to use TurboFloat. TurboFloat is designed to see the difference between virtual machines. So if you want to allow a customer to run your app on 1 concurrent machine at a time, then you can actually enforce it. Even if the customer copies a virtual machine bit-for-bit (thereby copying the "unique fingerprint" bit-for-bit) the customer will only be able to run your app on 1 copy of the VM instances.
The way you might implement this in your app is to use TurboActivate and TurboFloat together. For regular customers on real machines use TurboActivate, and for everyone else use TurboFloat. One way to do this is to use the UseTrial(TA_DISALLOW_VM) function. And if it returns TA_E_IN_VM then you can request a license lease from the TurboFloat Server (read more about how to do that in "Using TurboFloat").