I have a grasshopper definition which I would like to distribute with licensing restrictions. I’m wondering what is the best way to do this. Is it possible with a GH definition or does it need to be completely transcoded into C# or Python?
This post talks a bit about password protected clusters or user objects. This solves somewhat the IP issue but doesn’t address the licensing issue. This tutorial talks about plug-ins that expire (which would somewhat address the licensing issue) but it is for C/C++ and I’m not sure how that is compatible with a GH definition.
Hey Paul,
Depending on the level of DRM you’re after password protected clusters might not be the most suitable, for example this post which uses reflection to change the cluster password (not verified, just from a quick search). IIRC there was some discussion/warning about not expecting high security from clusters when passwords were first introduced.
That said, a ‘lazy’ way of doing the licensing would be to write a simple ‘gate’ component which passes data through if the license is valid, and passes nulls to ‘break’ the definition if the license is invalid.
There are lots of ways to do licensing, but the quickest way I can think of would be to include a hashed/encoded text file in the same folder as the GH definition which is referenced by the ‘gate’. If you want to license for a specific machine, you could create a hash based on some combination of the MAC address and expiry date. Lots of plugins have done this in some capacity in the early stages of development - where the client generates a request code which is really just some version of the MAC address, and then you provide a license specifically for that request code and any other data you want to embed. Typically this would be done through a .reg file to simplify installation of the license.
You should write it as a plug-in, there is no great way to protect definitions (like cluster passwords which are extremely easy to go around, and there is somewhere on this forum saying GH2 probably wont have a password option anymore for clusters). Also, definitions are much more prone to breaking as Gh updates happen. (look at how the basic math components made in an R6 Gh file cannot be opened in an R5 Gh file) - seems like it would be a real pain to manage and keep up to date, where as coded plugins (that don’t reference other 3rd party librarys) don’t really ever stop working since Rhinocommon isn’t broken very often.
As a plug-in you could license it similar to something like Karmaba.
Another viable option is keep your definition as a “trade secret” and don’t distribute it, instead charge people for your services, in which you would be the one using the definition on their project.