Use “Virtual Dongles” for Software Products Deployed in the Cloud
Do you want your customers to be able to use your software in the Cloud? But, you worry that since machine cloning is so easy that your software might be subject to unauthorized overuse? Control your software deployment with “Virtual Dongles for the Cloud”.
Consider using RLM Personal Edition or RLMCloud to easily serve your Cloud licenses.
To enable a customer, simply add his or her username or device ID to your customer list. Since RLM Personal and RLMCloud licenses are floating licenses, users can access your product from any development platform that you support, but use only one licensed copy at a time.
Think of it as a “virtualdongle” that’s cheaper than USB dongles, never gets lost or stolen, never breaks, and doesn’t require shipping. And best of all, it works in the Cloud.
Use the simple RLM Personal Edition API or RLMCloud to checkout the license assigned to the customer’s username or device ID when your software starts.
License checks happen over standard browser protocols.
You can store customer-specific options in each license… specify things like service levels, features, or expiration dates. The RLM Personal and RLMCloud APIs let you retrieve this optional information from within your program.
If you sell subscriptions, no problem, simply remove the user from the list if they cancel.
These licenses can be used for evaluations and paid licenses.
everyone hates them (with the possible exception of their spouses and mothers),
all are (to some extent) illegal, and
for them to be successful, they must be bad for (your) business.
What does this have to do with license management? Nothing at all. But this kind of behavior is an annoyance for everyone. This week we spent an unreasonable amount of time identifying and stopping a bad bot that was generating roughly 50% of our website traffic.
When we finally found them they told us “you can block our traffic in your robots.txt file”. Really? (We had already blocked them). Should the onus be on us to find them then block them, when we never asked to have them come and abuse our site? And because their software developers don’t test their code before they unleash it on the internet at large?
They are in business to make your business worse.
When we found them, they told us this: “(product name) is a digital marketing software that allows its users to view various information about their competitors from an SEO and SEM standpoint.” Well, that makes me feel so much better about their bad software flooding my server with bogus requests.
In our case, their bad requests each generated a 404-not found error, which they repeated minute after minute, day after day. And there is 0 advantage to us, in fact, their business allows our competitors to take advantage of us. Their business makes our business worse. And they will do the same to you. Also, their business slows down our website. And in our case, it was about to force us to upgrade our web hosting plan. I would call that, at a minimum, unethical. We won’t mention the company name, but they are a well-known company in the SEM business and given the state of their software, they are in a hurry to release new versions.
So their business is, at some level, putting a burden on each and every website owner (unknown to them) so that they can generate a profit. They should be compensating every website they invade, or at a minimum, requesting permission before they perform this kind of attack on a site.
Leave us a comment, and we will be happy to show you how to block them. They have no business messing with your site. It’s time to stop this kind of abuse.
Peregrine developed a small toolset for tracking usage internally, but they needed help from a third-party solution so they could concentrate on building better products instead of trying to maintain licensing.
On rare occasions, an activation request will get a read timeout status return (-105). There are several causes to the RLM_EH_NET_RERR (-105) error. They are described in the debugging section of the manual, repeated at the end here.
If you can activate from some systems, then the first cause (server down) is unlikely.
More likely is that there is either a proxy/firewall/anti-virus package blocking the response or the system fails a reverse DNS lookup and is timing out.
The easiest way to test for this is to set the activation timeout to 60 seconds. Do this by setting the environment variable RLM_ACT_TIMEOUT to 60, and re-running your activation utility. If this fixes the problem, then you can either leave the timeout set to 60 or have your customer add a PTR record for their host as described in this article: https://en.wikipedia.org/wiki/Reverse_DNS_lookup
If increasing the timeout doesn’t help, then disabling the proxy/firewall/anti-virus would be the next thing to try. It is beyond the scope here to attempt to address all possible proxy servers, firewalls, and anti-virus software.
Environment variables are flags that you set outside an application that the application reacts to. Applications and libraries like RLM read environment variables that they define. Some RLM environment variables are RLM_ACT_TIMEOUT (adjusts the timeout to the activation server to the value supplied), RLM_QUEUE (enables queueing for a license), and RLM_ROAM (controls setting up, using, and returning roamed licenses). This is not an exhaustive list, but gives you an idea of what environment variables can do. In some situations, a Reprise Software support person may ask you to set a particular environment variable to some value and then run your application. This article is about how to set environment variables, not which ones are available in RLM.
A characteristic of environment variables is that they are set in a process, like a Windows command window or a Unix/Linux shell, and are inherited by processes that are created by that process. So if you create 2 command windows and you set an environment variable in window 1, it won’t be set in window 2. But if you run an application in window 1, the environment variable will be set in that application.
The easiest way to use an environment variable with RLM is to set it in a command window or shell, then invoke the application from that window or shell. For example, if you wanted to set RLM_DIAGNOSTICS to cause the application to write RLM diagnostic information to the file “diag.txt”
Windows: set RLM_DIAGNOSTICS=diag.txt
sh, bash : export RLM_DIAGNOSTICS=diag.txt
csh: setenv RLM_DIAGNOSTICS diag.txt
Then invoke the application from the window where you set RLM_ROAM. But it’s inconvenient or sometimes impossible to invoke the application from a command window on Windows. In that case you can set the environment variable via the Windows control panel:
Bring up the control panel.
Search for “environment” in the search box at the top right.
Click on “Edit environment variables for your account.
RLM effortlessly allows software vendors and customers to change licensing models by simply changing the content of the license file itself. This allows software vendors to focus on usability and supporting the customer in configuring the floating license server itself.