Maybe I don't understand your product accurately, but it seems that the concept is that you allow people who write server side JS code to protect their code: lock it down somehow and subject it to software-enforced licensing of some sort.
Now, I'm going to assume that without your solution or something like it, such code isn't protected. (Assume, correctly, that I don't know anything about server-side Javascript.)
The first question is: what is the competition? Is there a way of doing this that doesn't require your solution? If so, how are you convincing users to migrate to your way of doing it.
Secondly, suppose there is no competition. In that case, people who write server-side JS code do not expect to be able to do that kind of licensing, even before they have written any line of code. They deploy their server-side JS code in scenarios in which licensing that code isn't the bread and butter of their business; they lock in their bread and butter in some other way and take it for granted that people can easily reverse-engineer their server side JS code, and muck around with it, steal snippets and whatever.
In this scenario is where you are in trouble because you face the prospect of convincing the people who are doing server-side-JavaScript development world to do that kind of node-locked deployment model. Only if they are seriously on-board with developing and deploying something like that do they then become potential customers for your licensing scheme. By the time they get serious, they might even roll their own.
You might be better off developing a superior licensing alternative for for some toolchain whose users already do that kind of licensing, stealing those users from whatever they are using now. And then work the JavaScript story into that: "hey, existing users: if you want to branch into JavaScript work, under your existing licensing model, we have you covered".
Lastly consider that if node-license-locked server side JS development suddenly became immensely fashionable, how likely would it be for numerous solutions to appear, many of them FOSS?
Now, I'm going to assume that without your solution or something like it, such code isn't protected. (Assume, correctly, that I don't know anything about server-side Javascript.)
The first question is: what is the competition? Is there a way of doing this that doesn't require your solution? If so, how are you convincing users to migrate to your way of doing it.
Secondly, suppose there is no competition. In that case, people who write server-side JS code do not expect to be able to do that kind of licensing, even before they have written any line of code. They deploy their server-side JS code in scenarios in which licensing that code isn't the bread and butter of their business; they lock in their bread and butter in some other way and take it for granted that people can easily reverse-engineer their server side JS code, and muck around with it, steal snippets and whatever.
In this scenario is where you are in trouble because you face the prospect of convincing the people who are doing server-side-JavaScript development world to do that kind of node-locked deployment model. Only if they are seriously on-board with developing and deploying something like that do they then become potential customers for your licensing scheme. By the time they get serious, they might even roll their own.
You might be better off developing a superior licensing alternative for for some toolchain whose users already do that kind of licensing, stealing those users from whatever they are using now. And then work the JavaScript story into that: "hey, existing users: if you want to branch into JavaScript work, under your existing licensing model, we have you covered".
Lastly consider that if node-license-locked server side JS development suddenly became immensely fashionable, how likely would it be for numerous solutions to appear, many of them FOSS?