Run-Time license

[ANV_Vollinger]

Hi all,

I am developing a toolkit which consists of several Libraries. It has following licensing requirements: 

1. When user installs it (via VI Package Manager) it should be in evaluation period for 30 days, then it expires. While in evaluation, user should not be able to build any part of the toolkit into executable.

2. Development licensing - in this version, user is able to use all libraries in toolkit, however, he should still have no access to source code. It should be possible to build executable with this version of toolkit for certain libraries, however, executable shall still require activation (run-time license).

3. Run-time license - Certain libraries, which are included in executable should be activated by this license, however, user should still have no access to source code.

I am using TPLAT + Protection PLUS 4 SDK + SOLO server automation for this task. I managed to create licensing in LFEDIT and also license several libraries which I can activate through SOLO server as intended. What I struggle with is having several licenses bound to a single library. I found that it can be done with TPLAT API. But from what I understand, this API requires putting license check into block diagram of my VIs, and one of the information I am putting here is license file password. If I understand correctly, if user gets access to this password, he can then open the license file and modify it, which means he can also cancel licensing at all. 

To sum this up, I am trying to add licensing to several LabVIEW libraries, having different licensing options and I am not sure what is the best way to perform this, especially concerning the security of licensing. Every idea will be appreciated.

[RDR]

If you have not reached out to Concept Software, they are also a valuable resource for their toolkit.

There are two primary licensing use cases supported by both the Third Party Licensing and Activation Toolkit (TPLAT) and NI License Manager (NILM):

1. Development licensing - were a license is bound to a LabVIEW library (lvlib) and protects its contents from A) being built into an executable (and FPGA bit file) when in eval mode or if the license expires or becomes invalid, and B) from being executed within the LabVIEW development environment beyond the eval period or when the licenses expires or becomes invalid. If no passwords are blocking the block diagram when the license is bound to the library, the customer will only have access to view source and build EXEs after activating the license. However, if the block diagrams are protected prior to binding their library to a license the protection will remain even after a customer activates the license. Development licensing is intended to provide the same functionality and experience that a customer expects from NI toolkits.
2. Deployment licensing - there are also APIs included with both TPLAT and NILM to perform licensing checks at run-time. These are intended for use in protecting built applications where the code is compiled into an EXE, and we don't recommend using them to implement run-time licensing models for libraries because it does become confusing to users who expect built applications to continue working without maintaining a run-time license for development libraries. However, functionally they could be used within a library as long as the developer takes measures to protect the diagrams where the licensing VIs are used. Several discussions have taken place at community events, like the CLA Summit on methods to protect diagrams and what a "hacker" would need to do to work around them. The discussions usually land on the fact licensing and protecting code is very difficult, and in the end you are keeping your customers honest with software licensing and trusting customers don't want to break the law by finding a way to work around it. Often, the more you do to protect code the more unusable/tedious the resulting library becomes for honest customers who want to license and use it.

I'd like to hear what other developers have to say on this topic.

-RDR

[Taggart]

---

@RDR wrote:

Several discussions have taken place at community events, like the CLA Summit on methods to protect diagrams and what a "hacker" would need to do to work around them. The discussions usually land on the fact licensing and protecting code is very difficult, and in the end you are keeping your customers honest with software licensing and trusting customers don't want to break the law by finding a way to work around it. Often, the more you do to protect code the more unusable/tedious the resulting library becomes for honest customers who want to license and use it.

-RDR

---

That is what I remember from those discussions.

[ANV_Vollinger]

Thank you for your reply RDR. From what you described, I would like to use both development and deployment licensing. However, I am having trouble implementing deployment licensing with API. Some of my libraries need to be available in both development and deployment license, while others only in development. Hence, I tried to separate them by using two license files. I tried to attach two license files to single library and somehow logically OR licenses, bit this did not work for me. I tried also using TPLAT API, but havent achieved meaningful results. I went through documentation and also examples for TPLAT API.

Could anyone please help me achieve result which I am looking for?

[RDR]

Sure, I believe there may be some confusion around development vs deployment licensing.

• Development licensing requires binding a license file to a library in order for LabVIEW to recognize the library is protected and needs to be handled following the behaviors I described above.
• Deployment licensing doesn't require binding a license to a library. Instead, you ship a second license and use the TPLAT API to check the license status at run-time and based upon the status returned decide what to enable/disable. There are examples shipping with TPLAT showing how to license EXEs/applications using the TPLAT API--I recommend checking those out.

[ANV_Vollinger]

Thank you. I managed to deploy runtime license. Now I found I have another issue - I am using development license for several libraries. For some reason however, during evaluation I cannot reference these libraries among themselves (see attached picture). Consequently, after installing toolkit in evaluation, VIs are broken. Is there any workaround for this, so that I can use libraries with same license among themselves?

[ANV_Vollinger]

As I found, this was issue of community scope in Libraries I used - changing it to public solved the issue

[ANV_Vollinger]

My license now works almost fine. There is one issue still however - now I am using TPLAT to perform license checks during runtime. TPLAT uses several DLLs (keylib32.dll, keylib64.dll, skca32.dll and skca64.dll). When I build .exe and use a VI from my library inside one of source files of .exe, it requires these DLLs to run. I can manually copy DLLs with .exe, but this is something, which would be really bad from a user point of view. I found, that for some reason, Project explorer is unable to display DLLs in file explorer and I am unable to right-click => explore on them (see picture). It appears to me that project explorer at the same time knows and doesnt know, where the DLLs are. I suppose this might also be the reason, why it does not include them in support files of .exe. I considered replacing DLLs, but since they are dependencies of TPLAT´s VIs which are locked, I cannot modify these VIs. Any idea how to solve this issue?

[Chakib11]

Hello, 

I encountred the same issue, did you  fix it ? 

Thanks