12-14-2009 10:43 AM
Hi,
When issuing a deployment, we typically intend the software to be used on one PC.
However there is nothing to stop our customers from deploying the deployment on multiple PC's.
Is there any simple way that we can limit the number of deployments that are possible?
thanks Sean
12-15-2009 01:42 AM
Sean,
i am not sure about what is happening at your customer. The main reason:
A TestStand application needs at least the Base Deployment License which is not for free. So even if your customer installs the application on other PCs, the application will not be executable.
If you are not referring to the runtime environment, but on test sequecens, i suggest you to create a license agreement for your sequence files. If the customer does not honor the agreement, you can talk to the customer and tell them that they are breaking the agreement which can lead to fines due to this.
hope this helps,
Norbert
12-15-2009 03:17 AM
Hi Norbert,
I'd like to tackle your first statement, "i am not sure about what is happening at your customer". I never said this was happening at a customers site, to my knowledge nothing is happening, but as they say in the software business, "licensing without enforcement is a license to steal". NI is obviously aware of this as the customer must pay a license fee for each deployment.
However for software developers, developing VI's and Sequence file there does not seem to be a built in option and it is on this matter that I was enquiring.
"If the customer does not honor the agreement, you can talk to the customer and tell them that they are breaking the agreement which can lead to fines due to this."
Unless you are suggesting we raid the premises of our cutsomers, we have no visibility as to the status of the agreement and we would not insult our customers by asking them such questions.
In any case it appears it cannot be doen and we need our own solution, thanks for the feedback Norbert.
Regards,
Sean
12-15-2009 03:40 AM - edited 12-15-2009 03:42 AM
Sean,
first of all: not all runtime environments of National Instruments software products are liable to pay costs (some are as TestStand or Vision, some not like e.g. LabVIEW).
Second point: There are many forms of licensing available, and all have advantages and disadvantages. Let's make some examples:
I include an EULA (end user license agreement) in my software. The user may use the software on three different systems. How do you track the usage? You can only rely on the customer....
If you include an online licensing mechanism, you can track the number of activations of the product (this is what NI does). If the software got activated a fourth time, you can ask why this was done....
If the activation uses a strikt pool of licenses and a new license might only be retrieved if another one is returned: what do you do with PC crashes where the return is not possible (e.g. headcrash of HD)?
Maybe you are more interested in distributing "dongles" (softwarekeys on e.g. USB sticks) which is probably the best method for you. But what happens if the customer loses this USB stick?
You see, there are several approaches and all lack of proper handling in certain situations ("overburden" vs. "unsecure"). There are books with lots of information about this topic (e.g. Code Complete) and many people discuss different approaches. This is the reason why NI software does not inlude any default mechanism for licensing custom made software. You are correct that you have to implement/include your own licensing model.
Norbert
12-15-2009 05:09 AM
Norbert,
Thanks for your reply. That's basically what I've been doing, looking at all the license options.
Hardware is the simplest but there seems to be no end of problems with missing dongles, etc. so I've been investigating setting up a secure activation database since yesterday evening, obviously it would be great if NI offered this service but I appreciate that's not the case.
I'll check out 'Code Complete'.
Thanks for all your feedback and help.
Sean
12-15-2009 06:20 AM
Sean,
sorry, but i gave the wrong book as reference: It should be the book "Beyond Software Architectur" written by Luke Hohmann.
Hopefully you read this before purchasing the wrong book.....
Norbert