Sorry, newb, but I did do some Googling before coming up dry and deciding to bother you all. My colleagues have put a ton of work into their GH scripts, and we are now hiring new people who will be working remote / distributed and remote viewing/working the machine where the Rhino/GF lives. While the scripts aren’t exactly the keys to the kingdom, they do represent a lot of ‘equity’ in terms of months and months of painstaking trial and error to perfect what we do. Is there any way(s) to allow the remote work, but lock or hugely deter seeing how the GH scripts work?
If you have safety doubts in your office, you should keep the code literally away.
This is a raw solution, but somehow working:
With Data Input and Data Output components you can send ghdata on a lan shared location and let a single central rhino+grasshopper session do all the work.
Here i’m sharing files on a ftp folder in a raspberry in my home LAN…
It’s not fast, there is a delay, but as the example in the video, the laptop is totally “unaware” of the actual script that did all the work.
Forget it, you won’t find a nice solution. Riccardos solution is not that bad. But, you’ll need to start the script somewhere else and keep it alive. You could also obfuscate your scripts or build in little scripted traps, but in the end you fight against windmills.
Seriously, don’t care at all. Really, it is a better mindset. Thrust your coworkers or employees and maybe you get something back in return. Its not your script, but your skill which is valuable.
Trust your coworkers or employees and maybe you get something back in return. Its not your script, but your skill which is valuable.
Also, you could make them sign contracts / NDAs. Not foolproof, but the idea of legal action is enough to prevent most from doing something like that and is pretty standard practice.
Probably i didn’t catch the point, but you can use clusters for your scripts or their parts and assign passwords to them.
But be aware sometimes clusters doesn’t allow to your scripts works properly, it doesn’t work with looping through Anemone plugin for me etc. So you need to check if everything works fine, otherwise distribute script at several parts…
If you could force Grasshopper to always immediately execute a loaded file, then you could actually build in neat protections. This could be feasible by relying on a plugin which exactly prevents this on loading. Any gh file could then contain a check for the user name or to look for a license file and even sending a notification on misuses. This could also be included without this theoretical plugin, but it would be easier to disable it. Actually I always disable the initial execution when loading a gh file from the internet…
It’s easy to read a GH file offline. So it needs to be encrypted and decrypted in a controlled environment (e.g. by a plugin). But I think that goes too far.
@gankeyu
Yeah, no software is safe and can be bypassed somehow, often easily. Its about protecting against the average joes… If you have a certain skill, you don’t need these “amateur” gh scripts anyway
@matthias3
Here is another way, rename the c# component with your windows username and you have a basic protection. I would also comment out the MessageBox:
It could have restarted your computer, deleted the file batched or untervolted your intel processor… You basically can do a lot of crappy stuff. If you hide this functionality or make it to seem more to be a hardware issue, then nobody expects a protection mechanism underneath, and so the average joe don‘t even notice whats causing this… If you feed in no warnings, trigger it to happen randomly or strongly delayed then even more. (@Michael_Pryor) But if you name it password protection, then everyone likes to bypass this. The average joe couldn‘t even bypass cluster passwords, if nobody would tell how to bypass, downloading scripts or reading blog posts is easy…
Another idea: use a "hidden"code like yours only to notify the owner of the script when/where it is used, so if a copy is pulled “outside the office” you can pin-point the culprit… but it would be late… and the algorithm could still be copied into another gh file without the c# script…
Anyway, I would recommend to use dynamic dataflow, hosting core computation on another computer. It won’t be that bad if only a little geometry is involved. Rhino’s geometry serialization is not very fast but quite usable.
Still, there’re few thinking-heavy scripts which also draws attention from professionals.
I know a studio in China who has developed a very complicated GH script for generating smooth stairs from arbitrary side curves and it can deal with a huge number of edge cases. I’d like to learn how it works but that script is kept protected.
