brucebWe have a software product that uses LimeLM licensing/activation. We are currently using the License Fields to activate different modules for the product based on what the user purchases. We are finding this to be very cumbersome to manage and would like to know if there is another option for this.
Here's what we would like to do:1. Create a separate product in LimeLM for each module so they each have their own activation code.2. Be able to use multiple activation codes for a single software product to active different modules within the product.
This would give us more flexibility for our customers. Some what to purchase two modules and run them on a single computer and other want to purchase the two modules and run them on separate computers. Having separate codes would allow us to easily track what customer have purchased. Having the module activation buried within a single activation code makes it difficult to find what's activated and difficult to separate if the user chooses to run them on separate computers.
Hope this makes sense. Thanks!
Hey Bruce,
This will be easier in TurboActivate 4.0, but in TA 3.x the way to do it is
1. separate TurboActivate.dat files2. Each plugin or app loads the TurboActivate.dat specific to that product3. Use SetCurrentProduct(VersionGUID) before calling any TurboActivate function in your product if multiple products are in the same process. If the products are separate processes (the typical use-case) then calling SetCurrentProduct() is completely unnecessary.
Does that make sense?
brucebSam,
I'll get this info to my programmers to see if there are any questions. When will TA 4.0 be available? How is TA 4.0 different than TA 3.x in this area?
Thanks!
It'll be out in about 3 weeks (barring no unforeseen complications).
How is TA 4.0 different than TA 3.x in this area?
It's different in that you use a version GUID to get a handle (using TA_GetHandle()), and you use that handle in all of the TurboActivate functions. So you can use multiple products and multiple handles all within the same process and TurboActivate just handles it.
With TA 3.x and older, that "handle" system doesn't exist, and multiple products in the same process exists in a rudimentary form (using the SetCurrentProduct() function before making a call to a TurboActivate function).
If you're using a language other than C/C++ then these changes will be largely abstracted away. For example, in C# you'll have a separate TurboActivate class for every "product" you want in that process.
bruceb"It'll be out in about 3 weeks (barring no unforeseen complications)."
Just checking to see if TA 4.0 has been release yet.
We're working to get it out before Christmas.
brucebOk. Please reply when it is finished. I have a software product ready to release that is waiting for this upgrade.
Thanks and Happy Holidays!
It's our number 1 priority. It will be released ASAP.
brucebSam wrote:> It's our number 1 priority. It will be released ASAP.
Getting any closer to releasing TA 4.0?
Every day we're closer. This release took longer than normal for a lot of reasons. The server-infrastructure changes that needed to be rolled out without downtime are a big part of the delay.
brucebSam wrote:> Hey Bruce,> > This will be easier in TurboActivate 4.0, but in TA 3.x the way to do it is> > 1. separate TurboActivate.dat files> 2. Each plugin or app loads the TurboActivate.dat specific to that product> 3. Use SetCurrentProduct(VersionGUID) before calling any TurboActivate> function in your product if multiple products are in the same process. If> the products are separate processes (the typical use-case) then calling> SetCurrentProduct() is completely unnecessary.> > Does that make sense?
Sam,
Currently we have one module being sold and are updating the app to include a second module. Do you have any other suggestions on how to handle this to make it easy for us to track which customer has what module and how to track and deliver the additional module when a customer wishes to purchase it?
Currently we are using the Custom License Fields function to trigger what is active in the app. This makes it very difficult to automate the purchase process should a customer with one module want to purchase the other module at a later date. Also no way we know of to track this process in our backend customer/sales database.
Since we already have a TA.dat file in the existing product, our programmers are saying this would require changing the app to include the two TA.dat files, which would prompt a relicensing of all the exiting sold apps that our out there (100 or so). Not very convenient for all.
So I'm asking for some thoughts on what's our best approach to accomplishing adding a second module to our app that can easily have a paper trail with regard to sales and who has what? What are the downsides, and what hoops will our customer and us have to jump through to accomplish this (relicensing, etc.).
I'm also assuming that this is handled much better in TA 4.0, right? Would waiting for 4.0 still be a better route to take, with less pain for all in the long run? My problem with this is that we've been waiting since early November for TA 4.0 (I understand why) and have our product release on hold at this point waiting for TA 4.0. Any options with caveats would be appreciated so we can move forward.
Thanks!!
>> "Currently we are using the Custom License Fields function to trigger what is active in the app. This makes it very difficult to automate the purchase process should a customer with one module want to purchase the other module at a later date. Also no way we know of to track this process in our backend customer/sales database."
Well, custom license fields is the best way to handle it. Even with TurboActivate 4.0.
Why do you say it's difficult to handle? What part in particular is giving you trouble?
brucebSam wrote:
> Well, custom license fields is the best way to handle it. Even with TurboActivate> 4.0.> > Why do you say it's difficult to handle? What part in particular is giving you> trouble?
Well I guess maybe I'm making too much of the limitations I'm seeing. Here's a couple of scenarios:
1. A customer purchases Module A, so we create a license code that has Module A set to 1 in the custom license field (CLF). All done automatically via our web store or via our intervention in our admin portal. We can easily track the purchase within our db and it's easy for the customer to see they paid for Module A, received the code and download link. They later want to purchase Module B and add that to Module A on the same computer. This then becomes an odd situation as from where I'm sitting someone would have to go into LimeLM and find their original code and put a 1 in the CLF for Module B. That then automatically allows them to use Module B, but the transaction within our web order db would have nothing to deliver to the customer and the customer would receive nothing physically for their purchase. I'm not sure if this can be automated within our automated process or not.
2. Taking scenario 1 above and changing it slightly. The customer purchased Module A and then later wants to purchase Module B but wants Module B on a different computer. We would then need to create an original code for Module A and a second code for Module B as the customer would need two separate installs of the product. Confusing for the customer and even more confusing for our record keeping and database automation.
3. What if they started out with both modules on a single computer and then wanted to split them up at a later date? Remember, both modules are part of the same software application, so they would need to install a second instance of the original application, change the code so it no longer has Module B activated and then generate a new code only for Module B. AGH!
Am I missing something here, or overthinking this? Probably most of the confusion stems from trying to wrap my head around the different combinations of scenarios and how to address each within our automated sales/delivery db system. It just seems that separate codes for separate modules would be the easiest all around.
In our industry (printing) the common way to sell software features is with add-on license codes. The app has all the features but restricts access to those features that haven't been licensed. You purchase a license code for each feature the user wants to unlock and have access to. Seems simple to me and easy to track. Plus makes it easy for the customer to make changes themselves down the road if they choose to move a Module to a different computer.
>> "1. [...] This then becomes an odd situation as from where I'm sitting someone would have to go into LimeLM and find their original code and put a 1 in the CLF for Module B."
No, you can automate this. Have the customer enter their existing product key into the order form. Then use the limelm.pkey.setDetails function to set the custom license field: http://wyday.com/limelm/help/api/limelm.pkey.setDetails/
>> "2. Taking scenario 1 above and changing it slightly. The customer purchased Module A and then later wants to purchase Module B but wants Module B on a different computer. [...]"
Well, if this is a case you actually deal with, then yes, separate product keys for separate "modules" is the best route. If this is just a hypothetical, or happens so rarely it's not even a blip, then you should handle them like the edge-case they are -- giving them separate poroduct keys, but using custom license fields for "modules".
>> "3. What if they started out with both modules on a single computer and then wanted to split them up at a later date? [...]"
Is this is case that happens a lot? If not, don't worry about it (you can handle cases like that on a case-by-case basis).
>> "Am I missing something here, or overthinking this?"
Yes, it sounds like you're overthinking this. You should automate the "base case". That is, the case that will happen most often. Then, handle "exceptional" cases by hand. Eventually you'll see which "exception cases" are eating up your time and you can automate those too.
You can waste hours and hours thinking of every possible case, but you also have to put it in perspective. Namely, asking yourself how often the exceptional cases will really happen.
