Developer Center Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Tying license to toolkit major release number (or equivalent)

I'll be interested in trialing the Licensing toolkit soon, and have a question to which I can't find an answer yet. Can a license key be paired with the major release number of the version number of the toolkit? I would want the license to allow minor updates to be installed and remain valid, but not work for major release updates.

Imagine a hypothetical toolkit released as V1.0, using the Development Add-on Licensing method to differentiate between a Free and Paid release. Customer 'A' has paid for the license to unlock the full feature set of the Paid release. This license needs to work for all V1.x releases. So for example:

At a future date, the toolkit is re-released as V1.1, with several bug-fixes. Customer 'A' would be able to install the new release and use it without requiring a new license key, or indeed re-activating it.

At another future date, the toolkit is re-released as V2.0, with some major improvements and enhancements. Customer 'A' would not be able to install this release and apply his license key, the toolkit would instead to revert to a Free release and a new license key is required.

Can all this be achieved with the NI Third Party Licensing & Activation Toolkit? If so, does it need the Advanced Licensing mode? Do I need to use the API to perform my own checks in the toolkit at run-time or can this all be handled by the licensing features inherent in LabVIEW?

Thanks in advance,

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 1 of 8
(8,559 Views)

Hi Thoric,

Great question.  I can think of a few different ways you can do this with Third Party Licensing & Activation Toolkit Standard Mode.  However I'm not exactly sure which is the best/easiest way.  I don't want to give the details until I'm sure I'm giving you the best answer, but I know it is possible.  I'll need to do some testing/research, but give me a day or two and I'll let you know for certain.  The good news is that any change needed to make this work can easily be made without casuing you to back track, so feel free to start playing around with it until I get more information.

Thanks for the interest!

David

0 Kudos
Message 2 of 8
(5,225 Views)

Hi David,

Thanks for the quick reply, I'm glad someone like yourself is looking into it, I look forward to your next message with earnest

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 3 of 8
(5,225 Views)

Hi Thoric,

LabVIEW Third Party Licensing & Activation Toolkit allows the user to activate the product once and then subsequent updates will not deactivate it.  This goes for minor and major version changes.  Because of this it looks like the best way to handle major upgrades would be to treat the new release as a new product in the Licensing server.

For example you create a product called "Awesome Toolkit v1".  You sell a customer Awesome Toolkit 1.0.0 and when you update to 1.1.0 they can install it with the same license.

When you upgrade to 2.0.0, you create another product in the license server called "Awesome Toolkit v2" which uses a different license file and therefore a customer would need to buy it. 

I tested this out and it all seems to work with no problems, but of course let us know if you come across any.  I hope this helps clear things up, but let me know if I can help further.

David

Message 4 of 8
(5,225 Views)

OK David, thank you very much for researching this for me. I will trial that concept and see how it works.

Are there any unsavoury consequences to listing major releases as a wholly new product?

For example, V2.0 will presumably appear as a new and disparate toolkit in License Manager? If so, that would give the operator the impression that both V1.0 and V2.0 were installed simultaneously, but V2.0 would necessarily overwrite V1.0 files at install making it practically unavailable. Is there an easy way to eradicate V1.0 from the NI bubble (License Manager) when installing V2.0 to prevent potential confusion and ensure they don't show side-by-side?

I hope these aren't unreasonable questions,

Thanks,

Thoric

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 5 of 8
(5,225 Views)

Thoric,


These are very reasonable questions, with hopefully reasonable answers.  I cannot think of any reason that creating different products for new releases should be a problem.  In fact there are customers who already do this, and it is the recommended guideline from the developer of the licensing solution (Concept Software).

As a background, the Third Party Licensing & Activation Toolkit actually does not use the standard NI License Manager that all of the NI products use.  Instead it uses the Help > Activate Add-ons dialog in LabVIEW.  Products need to be registered with LabVIEW in order to add or remove them from the dialog. 

To upgrade a product to V2.0 your installer must first unregister the V1.0 toolkit, upgrade the files and then register the V2.0 toolkit.  If you use VIPM 2012 for installation, this should automatically be taken care of for you.  If you use a LabVIEW installer or your own solution, you must call the RegisterAddon.exe with the -u parameter in order to unregister the old toolkit.  Then you can register V2.0 like normal (described here).

Does this help clarify things for you?  Glad to help more if needed!


David

Message 6 of 8
(5,225 Views)

That's great! Thanks David.

I would initially be looking at using the VIPM method, it's built in and comes recommended, but I'm intrigued that others choose other routes. Are there any obvious benefits to taking the long road and building your own installer?

Thoric

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 7 of 8
(5,225 Views)

I'm intrigued that others choose other routes.

Me to!!! 

We've been fighting the VIPM fight for a few years now.  There are 2 main reasons I've seen people choose to not use VIPM for shipping their toolkits.  1) They already developed using another method before they knew about VIPM and cost to switch is too high.  2) Some companies are skeptical about using any product that is made by a third party or does not come default with LabVIEW.  We've been trying to convince people that there is nothing to worry about here, and shipping VIPM with LabVIEW 2012 will hopefully help this going forward. 

David

0 Kudos
Message 8 of 8
(5,225 Views)