Some questions

Hey Andreas,

The customer fills in the license serial together wih the mac address and submits his license request. In turn, the existing license is activated and the custom feature "mac address" is set properly. Can we go that way?

Yes, this is exactly the way to go. You'll have to make a custom activation window for your app, and it would act something like this:

1. They enter their product key and custom feature value (in your case the mac address)
2. Post this data to a script on your site.
3. This script will call the LimeLM web API function limelm.pkey.setDetails to set the MAC address custom feature value. You can also do whatever else you need to do in this script (verify the MAC is in the proper range, etc.)
4. Have your custom script report either success or failure back to your app.
5. If the script succeeded then call the Activate() function.

You might want to automatically get your custom hardware's MAC address. The less your customer has to do the better their experience (also the less the support costs).

* We want to make use of a second custom feature "number of devices" that determines how many devices can the adressed from our software. [...]

I don't really understand. There are a few ways you can automatically change feature values and have them update on the client-side, but I need a bit more information before I can give you specific information. Are these extensions something the customer is purchasing -- like an addon? Or is this something you give away but they first have to contact your customer service?

* is there any kind of license statistic available inside the LimeLM web app.

Not yet, but we have been seriously considering adding it to LimeLM. Tell me what you need and we'll add it.

Hi,

thanks your response. Meanwhile I discussed the your licensing solution with my boss, and there are still some questions:

<Citation>2. Post this data to a script on your site.</Citation>

This is not fully clear to me yet. What do you mean with "your site". Most likely a web server hosted from my company, correct? If I have a script on my own server, how do I authenticate against the LimeLM web app? Having two servers involved doesn't seem to be an ideal solution, since now we have two targets for attacks. Isn't there the risk that someone gets unwanted access to my account at your LimeLM web server by observing the traffic between the two servers (or so)?

Or is there any chance to host scripts on the your server that runs the LimeLM web app? As far as I see this is not possible due to security reasons, correct?

<Citation>There are a few ways you can automatically change feature values and have them update on the client-side, but I need a bit more information before I can give you specific information. Are these extensions something the customer is purchasing -- like an addon?</Citation>

Let me explain a bit further:Basically, we would like to issue and sell two kind of serials: one (ordinary) serial for activating the application itself. LimeLM can handle this use case quite well (as far as I can see), I don't see too much problems with that.Also, we have a custom feature FOO (integer value) inside our app that we need for licensing purposes. We can have a custom feature FOO inside the LimeLM web app for that purpose, that's fine so far, too. But now it comes: Quite often, there is the need to increase the value of that custom feature FOO by one. Ideally this increase could be done by the customer independently, without any intervention from our side. The second serial is basically a one-time serial which we would like to sell to our customers. This serial would enable a customer to increase the value of the custom feature FOO of his application just by one (whenever he wants, at any time). For that purpose we would like to provide a form on a publicly available web server with two textboxes: one for the serial of the already licensed application and one for the one-time serial that enables the customer to increase the value of the feature FOO by one. After this form has been submitted, the one-time serial cannot be used any more. Can LimeLM handle that scenario, and if so, what would be the best way to impelemnt that?

Some more questions:* After activation of a serial via TurboActivate, how is the info about the activation stored locally on the PC? Inside the registry? Just curious, or is this your secret?

* is there the possibility to host the LimeLM web app on our own server (I think it is, correct?). If so what conditions must be met (OS, database server, ...)?

* In my last post, I wrote about some statistical features for accounting purposes. I had a look at the LimeLM Web API and identified the limelm.pkey command. This command however has the parameter email as required parameter. Is there a way to retrieve *all* product keys for a certain products, regardless of the email or serial key assiocated with product key.

Thanks for answering my questions.

Best regardsAndreas

This is not fully clear to me yet. What do you mean with "your site". Most likely a web server hosted from my company, correct?

That's correct. It doesn't need to be a webserver, but that's the typical use-case. It can just be an internal computer in your company that has access to the internet.

If I have a script on my own server, how do I authenticate against the LimeLM web app?

There's a special API key which give you access to functions you can use on your account.

Having two servers involved doesn't seem to be an ideal solution, since now we have two targets for attacks. Isn't there the risk that someone gets unwanted access to my account at your LimeLM web server by observing the traffic between the two servers (or so)?

No, there's no risk, the traffic is encrypted. That is a hacker could monitor your traffic and it would be useless because of the encryption.

As far as our servers goes, we're constantly monitoring for odd behavior and we also schedule regular security audits to make sure our protection is up-to-snuff.

Or is there any chance to host scripts on the your server that runs the LimeLM web app? As far as I see this is not possible due to security reasons, correct?

I wish we could host scripts on our servers, but unfortunately there are too many security problems (it's exceedingly hard to safely sandbox scripts).

Basically, we would like to issue and sell two kind of serials: one (ordinary) serial for activating the application itself. LimeLM can handle this use case quite well (as far as I can see), I don't see too much problems with that.

Yep, LimeLM handles this fine.

[...] After this form has been submitted, the one-time serial cannot be used any more. Can LimeLM handle that scenario, and if so, what would be the best way to impelemnt that?

Yes, LimeLM can handle that. There's no real need for the intermediate step of a special serial. You can just increment their total FOO count the second their credit card is processed (using limelm.pkey.setDetails). Or, if you want to go down the "intermeditate serial" route, you can. I just don't see the need for it.

* After activation of a serial via TurboActivate, how is the info about the activation stored locally on the PC? Inside the registry? Just curious, or is this your secret?

It's not a secret -- the data is stored across several files. The way hardware-locked licensing works is that these files will be useless if they are copied to any other machine.

* is there the possibility to host the LimeLM web app on our own server (I think it is, correct?). If so what conditions must be met (OS, database server, ...)?

Yes, you can run LimeLM on your own servers. The self-hosted LimeLM can run on all major operating systems (Windows XP+, Linux, Mac OS X 10.5+). Currently LimeLM only works with the MySQL database, but we're prepared to support PostgreSQL if you need it.

* In my last post, I wrote about some statistical features for accounting purposes. I had a look at the LimeLM Web API and identified the limelm.pkey command. This command however has the parameter email as required parameter. Is there a way to retrieve *all* product keys for a certain products, regardless of the email or serial key assiocated with product key.

You can within the LimeLM dashboard, but there's no way to do this using the LimeLM web API. If you can tell us what you're looking to track and measure we can build whatever features or functions you need to help you do that.

Hi

thanks for your prompt reply.

<citation>Yes, LimeLM can handle that. There's no real need for the intermediate step of a special serial. You can just increment their total FOO count the second their credit card is processed (using limelm.pkey.setDetails). Or, if you want to go down the "intermeditate serial" route, you can. I just don't see the need for it.</citation>

The need for that "intermeditate serial" route arises from the way how payments are handled inside our company. Unfortunately, we cannot use credit cards (or PayPal or whatever) in order to charge the serials we hand out to our customers. I know that this "intermeditate serial" route is a bit akward and complicates things, but there's currently no way how we can overcome that.So the question is: Can we use LimeLM for handling both serials, the serial for the app itself and the "intermediate serial" that allows to change custom fetaures of existing licenses?

The idea is to have two different "products" inside LimeLM, one real product "FOOBAR" with all the serials for our FOOBAR app and one "product" that handles the "intermediate serials" that are used to change the custom feature FOO of our FOOBAR product. Can we go that way?

We would then ship two kind of scripts together with our application FOOBAR:

* a script more or less like TurboActivate (we need to extend it a bit so that we can set a certain custom feature during activation of our product, that shouldn't be too complicated).

* a second "update" script that allows to increase the integer value of the custom feature FOO of our FOOBAR application. In order to successfully use that script successfully, a "intermediate serial" must be given.

Basically the idea is that handling of *all* serials (both the "real" serial and the "intermediate" serial) is done inside the LimeLM web app. Ideally there would be no need for us to set up our own web server, everything is handled from the scripts/forms that we ship together with our application FOOBAR.

This means however that we have to activate *two* serials inside out FOOBAR app, one for the app it self and one for changing the custom feature FOO for our app. Is LimeLM prepared for that? Is that something like that doable? If so, could you elaborate on that a bit?

Thanks for your reply.

Best regardsAndreas

Even though you're not using credit cards or any form of "instant" payment, there's eventually a moment that your customer's money leaves their bank account and goes to your bank account. At that moment you can increase the FOO feature count. That is, you can increment the FOO feature value for a product key either using the LimeLM web API or by manually logging in to LimeLM and changing it.

Then, you can contact that customer (by email, phone, or even a little message within your app) that the FOO count has increased. Then they can manually click a button or a menu that downloads the latest feature data from LimeLM. (See: Changing feature values).

So, unless I'm missing something, the intermediate serial is completely unnecessary. But maybe I'm not seeing the full picture.

Here's how I see the process working:

1. The customer orders your app, you generate a product key with feature values then send them the product key & the software.
2. The customer installs the software and uses the product key to activate.

Then later, the customer purchases an increase in the "FOO" feature.

1. You receive the payment, and you either manually or automatically increase the FOO feature count for their product key.
2. You either automatically notify their software (if this is possible within your app) or you manually notify them to click a button or a menu to retrieve their new feature data (which includes the updated "FOO" feature).

Does this sound right, or have I misunderstood you?

<Quote>So, unless I'm missing something, the intermediate serial is completely unnecessary. But maybe I'm not seeing the full picture.</Quote>

No, you are not seeing the full picture. We don't sell to the end customer directly, instead license handling is done from our distribution partners.Those distribution partners will be the one who extend the custom feature "FOO" for the installation at the end customers site. And those distribution partners/resellers would like to have more flexibility regarding the licensing of our software product. They basically want to buy a bunch of entitlements (= one time serials) for changing the custom feature FOO at the end customers site. At the moment when they buy those entitlements (this is also the moment when money leaves the bank account of our distribution partner and goes to your bank account) we do not know what end customer installation our resellers are using the license for. That's where the need for the intermediate serial arises from. I have to admit that the requirement for "intermediate serials" is owed to our special workflow, but I don't see a way to change that workflow inside our company.

So my question remains: can we use LimeLM for both the "real" and the "intermediate" serials, freeing us from the need to set up an own database for our serials?

A few questions concerning the scenario that we decide to host LimeLM on our own server (I just spoke with my boss about this this morning):* what costs are we looking at?* do we get binaries only or would you be willing to provide the sources, too (if the latter is true, are there any additional costs involved with that?)* what language did you use for the LimeLm app? I would assume it is sime kind of Java solution, correct?* what are the requirements concerning the web server? I know about the MySQL database, that should be fine. Do we need anything else (e.g. a Java Application Server (Tomcat, Jetty, or whatever))

Thanks for your answers

RegardsAndreas

[...] At the moment when they buy those entitlements (this is also the moment when money leaves the bank account of our distribution partner and goes to your bank account) we do not know what end customer installation our resellers are using the license for. That's where the need for the intermediate serial arises from. I have to admit that the requirement for "intermediate serials" is owed to our special workflow, but I don't see a way to change that workflow inside our company.

OK, I understand now. Well, there are quite a few ways you can do this, but I'll talk about the best 2. Since you're already using intermediate serials in your company workflow Method 1 is probably the best option for you in the short term. That is, it will be the least amount of effort to switch to LimeLM. However, I think Method 2 is a better method for your company and your distributors in the long term:

Method 1: Stick with the intermediate serials

You can create intermediate code (it doesn't need to be a serial) that these distributors enter onto a form on your website along with the customer's product key they are increasing the FOO count for.

Then, on your server, you check to see if that code has already been used. If the code hasn't been used then contact the LimeLM servers to increase the FOO count for the particular product key this distributor passed in.

Method 2: Distributor login

Instead of creating these intermediate codes, you can just create a login on your site. That is, after a distributor buys X entitlements, they can login to your website and use these X entitlements however they want on their customers' product keys. When a distributor uses an entitlement you can internally decrement the number of entitlements they have.

This method requires a bit more work than Method 1 (in that you have to create a login system for your distributors), but it will eliminate the need for intermediate serials altogether. Not to mention it's a more seamless process for everyone involved.

-----------

It goes without saying that whatever method you choose we'll help you write the code that integrate within LimeLM.

LimeLM on our own server [...] * what costs are we looking at?

It's about equivalent to the cost of the Max plan.

* what language did you use for the LimeLm app? I would assume it is sime kind of Java solution, correct?

The LimeLM frontend is written in PHP. All backend work (encryption, activation, etc.) is done by separate native processes. For speed reasons these processes are written in C, C++, and Assembly.

* do we get binaries only or would you be willing to provide the sources, too (if the latter is true, are there any additional costs involved with that?)

The front end code written in PHP is completely open. The backend is only shipped as binaries. If you're interested in the source code for the backend binaries and/or TurboActivate (the part that integrates with your app) then we can work something out.

But this is really unnecessary -- we fix bugs when they're reported to us and we gladly add features.

* what are the requirements concerning the web server? I know about the MySQL database, that should be fine. Do we need anything else (e.g. a Java Application Server (Tomcat, Jetty, or whatever))

A good HTTP server (IIS, Apache, or NGINX) and the latest version of PHP (currently 5.3.x). That's it. We help you set all this up so it functions as fast as possible.

Hi Wyatt,

we are getting much closer now, and I have the impression that LimeLM can handle our use case quite well.

However, some questions still remain and some comments have to be placed:

<Quotation>Since you're already using intermediate serials in your company workflow</Quotation>

No we don't. We only intend to introduce them together with our new licensing system.

<Quotation>Method 2: Distributor login</Quotation>

For a variety of reasons that is not really what we want. And we are primarily not put off by the amount of work that has to be invested but by the fact that we would create an additional overhead and that we don't see too much benefit deriving from an own login system (which we in fact already have, for another purpose).

<Quotation>Method 1: Stick with the intermediate serials

You can create intermediate code (it doesn't need to be a serial) that these distributors enter onto a form on your website along with the customer's product key they are increasing the FOO count for.

Then, on your server, you check to see if that code has already been used.</Quotation>

Even better if we could check on the LimeLM server if that intermediate serial exists there. Let me explain why it is favorable for us (from my point of view, comments are welcome) that we make use of the LimeLM server to handle the intermediate serials.

Our workflow goes like that:

1) We get an order from our resellers, via fax or however.2) We create an order inside our ERP system.3) We already have a piece of software that filters out the orders that contain our software product that need to be licensed. We would alter this software so that it will create serials for new installations on the LimeLM server, that shouldn't be too difficult.Additionally we would like to extend that software so that it can create intermediate keys on the LimeLM server. We would print those serial numbers (both real ones and intermediate ones, whatever they order) to a paper invoice and send it to our resellers. We then get in turn the money from our resellers and the issue is closed from our side.

In order to make that scenario work, we need two more pieces:* for new licenses: a modified version of TurboActivate that sets the value of a custom feature of the real serial key (a MAC address) during the activation of our software product.

* for existing licenses: a publicly available form on your website. Inside that form, our distributors will enter the intermediate code (represented as serial stored inside LimeLM) along with the customer's product key they are increasing the FOO count for. Once they submit the form, our server will contact the LimeLM server and will perform a lookup if the intermediate serial exists. If so, the custom features FOO count will be increased and the intermediate serial will be revoked afterwards. (The end customer has to reactivate his license then, of course).

These are the advantages that I can see by hosting all serials on the LimeLM server:

* if our web server that hosts the form will be compromised, there will be no great harm for us since the server is only relaying the serials to the LimeLM server, there are actually no intermediate licenses stored on our own web server.* we don't even need to set up a database for that publicly avaliable server nor do we have to set up a link between the web server and our ERP system inside our company network. This would minimze the number of points that can be used for attacks against our licensing system and would also minimze the amount of setup work needed.

Is that something that could work out?

Thanks your your attention

Best regardsAndreas

* for new licenses: a modified version of TurboActivate that sets the value of a custom feature of the real serial key (a MAC address) during the activation of our software product.

You don't really need a custom TurboActivate. You can use the existing code to do this. For instance, before activating, you can call a script on your website and pass in the product key and MAC address. This script will modify the feature value of the product key. Then, once the user has activated, the MAC address will be a feature value.

We can help you write this. It's not that complex.

* for existing licenses: a publicly available form on your website. Inside that form, our distributors will enter the intermediate code (represented as serial stored inside LimeLM) along with the customer's product key they are increasing the FOO count for. Once they submit the form, our server will contact the LimeLM server and will perform a lookup if the intermediate serial exists. If so, the custom features FOO count will be increased and the intermediate serial will be revoked afterwards. (The end customer has to reactivate his license then, of course).

Sure, you can do it this way.

* if our web server that hosts the form will be compromised, there will be no great harm for us since the server is only relaying the serials to the LimeLM server, there are actually no intermediate licenses stored on our own web server.* we don't even need to set up a database for that publicly avaliable server nor do we have to set up a link between the web server and our ERP system inside our company network. This would minimze the number of points that can be used for attacks against our licensing system and would also minimze the amount of setup work needed.

If your servers are compromised you'll have some pretty big problems even if you defer most of the work to LimeLM. That is, you still need to make sure your servers are secure.

Is that something that could work out?

Yep, this is all possible. If you need help writing this bit of integration code that makes this all possible, we'll be happy to assist.