In an effort to understand this TPLATK I've been following the tutorial provided here and attempting to produce a toolkit that's licensable.
I already have a toolkit, something which will soon be released as an AddOn on the LabVIEW Tools Network, so I'm applying the trail effort to that library and not the included demo library.
So here's what I need to create:
1. A toolkit that installs in trial mode, active for 30 days with unrestricted access to the functions available in the library.
2. After 30 days the toolkit falls by default into 'community' mode whereby restricted access to the tools is all the developer then has.
3. At any time the developer can purchase a license to activate the toolkit permanently (or perhaps for just 365 days), giving them the same full access to the library as in mode 1.
Now, from what I've understood about the licensing utility, only one license is applied to the toolkit library, and all the varying features of my 1, 2 and 3 have to be handled by differing Options within that one license. So my first question:
Q1: Where do I set the different licensing options for varying lengths of trial?
Furthermore, I need to set restrictions in the toolkit to prevent access to everything in mode 2. New question:
Q2: How do I use the API to access the current license details and determine which license/option type is active in order to customise the toolkit's accessibility?
I followed the trial anyway, in an effort to learn more, and indeed it installed well and I saw the National Instruments Third Party Toolkit license window appear after restarting LabVIEW informing me that I had a new toolkit installed in demo mode, with an "Activate" button. I clicked Activate and was greeted with this:
In the Wizard I have two "User Codes" and in the Activation webpage I have a "License ID" and "Password". Copying the two numbers across results in a license activation fail (Invalid Data Entered error), so I presume these numbers aren't meant to go here. In which case:
Q3: What on earth is this all about?
Also, in an attempt to create a number of different licensing options, I added several Options under the Product in the SOLO Server system.
But I couldn't see where to set the license activation period for these options, there appears to be no such field. So:
Q4: How do I create options, if this is the place for creating the varying licensing modes I need, that are valid for different time periods?
I hope there are others in this community group able to assist with this. I'm finding it all so very confusing, and the help doesn't cover my use cases so I'm not having any luck with that either
I'm sorry to hear that you are having trouble getting this set up, but hopefully I can clarify things. Also sorry for the short story below, but there was a lot to explain. I didn't specifically answer Q1-Q4 in order because I'm hoping to lay it out in a more clear way for your usecase, but let me know if I miss anything.
First of all let me start with the initial license file. You create this in LFEdit (part of ProtectionPlus package) and set it up with the licensing options that you want a user to start out with upon first installation (in your case this is a 30 day trial mode).
Once your customer has the product in their hands they will use it for 30 days and then they will need to activate it. To activate it they will need a license ID and password which is created in the SOLO server. For each license ID you can specify how it will activate the license file. For example you can create one license ID that will activate the software for 365 days, and create another license ID that will activate it permanently. These options are all configured through the use of different product options (Q3) in which you need to change the "trigger code" and the other fields in the product option page. This is a whole other rabbit hole of it's own, but most of this should be documented in the SOLO server manual. We can try to help understand this part, but the Concept Software support team can also help with all the details.
Now the most confusing part of all this probably comes with the fact that you want to have restricted functionality for your toolkit. Using the library licensing method discussed in this document, code within a library either works or doesn't work. If the license is in "evaluation" or "activated" state then the code runs, and if the license is in an "expired" state than the code is broken. If you want to have a toolkit that has certain functionality that works forever and certain functionalty that works only if a user pays for it, than you have a few options.
The first option is to separate your "community code" and "paid code" into different libraries and only license the "paid code" using the TPLAT licensing tool or VIPM Pro. Then once the trial expires, the community code is unaffected by the license, and the paid code is broken. This is only good if there is a very distinct separation of code that is free and code that you want licensed.
The second option is to use the TPLAT API. This is briefly described here but the general concept is that you actually place licensing code into the VIs that you are distributing instead of licensing the library. Then your toolkit can check the license status at run time and then restrict the code to do different things depending on the license status. I'm sure you can be creative in this step, but the simplest implementation is to check the license status in each VI that you want to restrict and only run the code if it's in an activated or evaluation state. The downside of this method is that the licensing isn't fully integrated into the LabVIEW activation dialog and you have to create your own methods for the customer to activate the code. This is usually done at run time, but there are a few other creative ideas to make this work nicely.
I know this was a pretty long response but I hope this helps clear up most of the confusion and answers your questions. Let me know once you wrap your head around this and if you still have some missing pieces I can help with.
That's a great answer, thank you for finding the time to explain that to me. I must admit I didn't understand the system at all beforehand, and have been pulling my hair out today trying to figure it all out.
So, anyway, due to the complexities of the SOLO system my company has decided not to adopt it and instead perform all activation operations via email. For example, if a user decides to purchase a license, they will choose an option in the toolkit which takes them to a web page of our own design which requests their details and payment. We will then create and send an email with the appropriate license codes which they will need to copy into an activation panel accessible from within the toolkit
All this means I will be avoiding the 'wrap your entire library in the license' strategy outlined everywhere in this community and perform manual checks instead. So I guess I still have a few questions:
1. Without the use of SOLO, can we still create activation codes that activate toolkit installations in different ways? I mean, for most customers we will provide a 365 day activation period, but occasionally we might provide an extended trial, so would want to provide an activation that expires in just 10 days. Can this flexibility be accommodated through simple codes emailed to the customer?
2. In the future, the amount of restriction might be altered. For example, we might produce three tiers: Community, Professional and Enterprise releases. These will need to be identifiable from within the toolkit using the API to ensure the correct levels of access are made available. Can this option be accomodated in the license file (which currently seems to accommodate a working/not working approach), and can these variations be configured through activation codes emailed to the customer? Is this perhaps related to the custom-fields of a license file? If so can we access these through the API? I don't see a VI function for that.
3. In the API, the Get License Status VI refers to TWO licenses, but we've already covered the fact that only one license can be associated with a toolkit. In the help it states that one is the run-time license (which is a mandatory input to the function) and the second is a development license (optional input). In my case I'm implementing a development license, not a run-time license. How do I use this API to get the Development License Status information when I don't have a run-time license?
4. Now that I'm not wrapping the whole toolkit in the licensing feature, what are the implications with regard to the toolkit being built into an executable? I presume if I'm using the API to query the license it will now need a distributed license file in order to remain activated in the distributed application? Can this be somehow automated so that a developer doesn't need to consider including a license file in their application builder specifications, or will they need to ensure they clone their license file alongside the built app to keep it activated?
Sorry for the endless questions, but I'm beginning to see just how complex this really is. There are lots of issues to consider that I hadn't previously realised.
I'm not sure I completely understand your intention. Is your intention to create your own licensing scheme from scratch? Or do you still plan to use Protection Plus to create licenses but just not SOLO server? If you are using the Third Party Licensing & Activation Toolkit it only works with the Protection Plus licensing software, so if you don't intend to use Protection Plus software, you will have to create your own licensing functionality.
I will comment though that using the SOLO server method has a tremendous benefit to the customer in which they can automatically activate their software immediately without having to wait for the back and forth of an email correspondence.
Assuming that you are thinking of rolling your own licensing solution, then obviously all of your questions are most likely possible, as long as you write the correct logic to handle the situations. You just won't be able to use TPLAT for your own licensing solution I've answered your 4 questions below assuming you are talking about using TPLAT with Protection Plus but not SOLO.
1. If you are using just Protection Plus without SOLO, you may be able to handle different licensing techniques through their trigger code system, but I'm not 100% since I've never tried it. You would have to talk to ConceptSoftware to get more information on this.
2. Again I'm not familiar enough with the Protection Plus software outside of the use-case that Third Party Licensing & Activation Toolkit uses, so I'll have to again point you to Concept Software (CS) to figure out if this is possible with their product. However assuming that it is possible with Protection Plus, then it should be possible in LabVIEW. The Third Party Licensing & Activation Toolkit API covers only a subset of the Protection Plus features, however they are pretty much LabVIEW wrappers that abstract out the Protection Plus API. I have heard of some developers calling directly into the Protection Plus DLLs which is pretty well documented. However if you went this route, you'd be outside of the scope of knowledge of most people in this community, so you'd have to look to CS for support.
3. The concept of two licenses in this VI assumes that you are using a combination of the TPLAT API and the Library Licensing wizard. If you tell the API that "Dev license is valid" then it will assume that the user can EITHER have a license in the normal place that the licensing wizard expects (which is C:\ProgramData\National Instruments\Partners\<Company Name>\Licenses) or the user has another license elsewhere. Each license can still only have 4 states (Evaluation, Expired, Activated or Invalid) but the Get License Status VI will take the "best" state between the two. So for example if your development license (in ProgramData) is expired but your Run-time license is activated, the Get License Status will return Activated.
4. If you are using the API, the API will be looking for a license no matter what so the EXE will need to have the license file somewhere. You may be able to implement some logic in which it ignores the licensing if built into an EXE, but this may be a challenge. If you are using the Library Licensing method, then the LabVIEW environment takes care of this situation for you. VIs that are in anything but an Activated State will break an EXE build process, but once the VIs are activated then an EXE can be created with no problem.
I hope this helped and didn't make things more confusing, but until you get your head around this whole thing then feel free to keep the questions coming.
Have a great weekend!
Again, thanks for taking the time to reply, I really appreciate it. And apologies for not being clear, but are right in assuming that I am still using ProtectionPlus, it's just the SOLO service we're not using anymore.
1 & 2. I still need to understand the triggering from ConceptSoftware, and study their API because until now I've been trying to just use the TPLAT API. I'll get cracking with that a.s.a.p.
3. This was the first I'd heard of there being two possible licenses, and it sounds useful. We will be using a LFEdit created license file, stored outside of the TPLATK expected domain and therefore outside of the NI 3rd Party Licensing domain. Does this count therefore as our 'Development' or 'Runtime' license? I'm still confused as to which is which because in my mind the toolkit is licensed by the same license file during both development and execution runtime.
4. I've since realised that we definitely need any executables checking for activation also, so the API does need to read from the license file at all times. I can't use the Library Licensing method for the reasons outlined above, so I guess I need to ensure the license is installed alongside any executable a developer might create that incorporates the toolkit.
It's just question 3 that I'm still a little unsure about. Apologies for the endless questions!
No worries at all. To clarify for question 3, the "Development License" will always be the license found in C:\ProgramData\National Instruments\Partners\<Company Name>\Licenses where the run-time license can be located wherever you tell the VI it should be. The way to tell the difference between the two is more clear when looking at the inputs to Get License Status.vi.
For the regular license file info, you must input a path and for the dev license info you must input a name (of the license file that is stored in ProgramData) and a company name (to determine the correct path under ProgramData). Let me know if you run into any other roadblocks.