Tired of proprietary scripts being used freely without your permission? Itâs time to move beyond simple sharing and implement real security for your Computational Design assets!
Iâve developed a robust method to protect and license your advanced Dynamo scripts using a Custom Node embedded directly into the workflow.
The Mechanism:
Whitelist Integration: The Custom Node is designed to check a defined external .txt file containing a list of authorized users and compare it with their PC Name.
Conditional Execution: The script will only proceed if the current machine name is authenticated against the whitelist. Otherwise, the script execution is immediately halted.
Double-Layer (Hidden) Defense: Crucially, the Custom Node includes a mechanism that detects if the protection node itself is deleted or bypassed. Attempting to delete the node triggers an execution failure, ensuring the security layer is non-removable.
This approach transforms your script from an open file into a secure, licensable intellectual property. This is one of the ways to protect automation tools.
Are you already using methods to protect your IP in Dynamo? Share your strategies below!
"If this approach sounds like the solution you need, Iâm happy to share more details about the Custom Node implementation with interested parties."
First up a personal note: I genuinely dislike putting tools behind an authentication method of any sort. Dynamo and the spirit of the community where we are having this conversation is intended to foster collaboration- authentication blocking use doesnât do that, and in the communityâs history the locked down toolsets have brought less value to firms and users than the open ones.
Next up, scripts distributed and run locally can of be made secure as they are text which is editable by default. This means a semi savvy user can just delete that section of the openly available Python code theyâre up and running without the authentication check. Iâve even seen people remove this type of stuff in bulk across the entire graph library to recover some vandalism from a disgruntled contractor. This was a rather creative try though - so donât let me get you down entirely as this is good work.
Securing code requires shipping it in an obfuscated way, where users have to work to get to the innards. This means âScriptFromStringâ where the string is passed from a secure remote file (so not the DYN or a DYF on the userâs system) and then executed; or using a format which cannot be readily updated such as a C# node, ideally with a full licensing system in place instead of a txt file as the later can also be shipped without issue.
Thanks for sharing your thoughts! Protecting intellectual property is crucial, not only for developers but also to help the Dynamo community evolve through collaborative solutions.
As I mentioned:
âIf this approach seems like the solution you need, Iâd be happy to share more details about implementing the custom node with interested parties.â
My method is simple yet effective: The custom node reads a whitelist of authorized users from a secure (restricted access) .txt file on a server. This is accompanied by a built-in tamper defense system that immediately stops the script if the custom node itself is removed or bypassed.
Iâm always open to alternatives! What robust protection methods have you successfully used?
Iâm confused⌠does anything stop the user from just modifying your Python nodes or copying all but it out of the script? I fail to see how this is truly secure in nature unless you assume your end user has no idea how to use dynamo.
If youâre going to go to all this length, may as well just make an addin and embed the desired dynâs into it, then temporarily write out a dyn stored as an embedded resource, run it, then remove it from a temp/semi randomized location to avoid easy interception (or just write an addin in c#).
As with all threads of this nature I will point out this is very much against the point of Dynamo.
Thank you for sharing your view in a respectful and polished manner, as well as for your helpful recommendations; your suggestion about developing a full C# Add-in is certainly the gold standard for protection.
Here is how the method addresses the points you raised:
Server-Side Protection & Custom Node: You are correct that Python nodes can be easily modified. Thatâs why the entire protection logic is contained within the Custom Node itself. This node is then saved to a secured server path where users do not have write/modify permissions, making the core security mechanism (the PC-Name check against the secured .TXT file) practically tamper-proof for the average user.
The Anti-Deletion Trigger: The key to stopping a savvy user from simply deleting the Custom Node is the logic embedded in the next node in the script flow. This relies on the following conditional
Deletion of the Custom Node breaks the script flow because the next step specifically requires its output (The bet here is that the user is not proficient enough in Python to discover it.)
Dynamoâs ethos is around involvement and community building. The purpose is to recognize the creatorâs efforts.
Although Iâm not in favor of script protection, I disagree with this. Dynamo for Civil 3D or Revit is very closed, it is only the core part that is open. I donât see Autodesk publicing the source of their additions. So it is quite defensible that someone wants to protect his own investment too.
But I think the best protection is to not share graphs in the first place, and warn your coworkers that it is companyâs property.
The Dynamo for Civil 3D integration is actually the odd duck here - both Dynamo and Revit have been and and continue to be Open Source. Also if memory serves the early prototypes of Dynamo for Civil were heavily influenced by the open source integration with Advance Steel (which is where Iâd start if someone were to request a Dynamo for Plant 3D or similar even though I have access to other source code as an Autodesk employee).
And yes, those repositories power a TON of the AI tools which are generating everyoneâs vibe coded add-ins.
Iâm going to strongly disagree on this bit. The open and editable nature of things in Dynamo is what allows us to develop and grow as a community. Closed source and productions solutions have:
Significantly less adoption among the user base (7 of the top 8 packages in use are open source)
Reduce the ability for the users you want to grow into the next âyouâ from doing so organically (if they canât get to your source code they canât use it as an educational tool)
Prevent AI based production of new tools (if the AI canât see the code base it canât learn incorporate it into something new)
Incorporate additional âgotchaâ moments when you go to scale (âWhoops - we havenât added your new PC to the list yet. Give me a few.â)
The fact is that everyone building Revit automations with Python today is either formally educated as a developer (in which case they arenât likely using Dynamoâs Python node for much more than a prototype), or has relied on and benefitted significantly from the open source content available to the larger community via things packages, Python scripts, GitHub repositories, blogs, forums, conferences, workshops, and the like.
Can you explain how preventing execution by any means of authorization helps the Dynamo community collaborate more than âhereâs a good tool for thatâ?
Personally Iâd avoid it entirely for the reasons outlined above. Unless there is a valid business case my stuff is as open as it can be - edit the Python all youâd like! Those business use cases have shown to be VERY rare in my 10+ years of Dynamo development and use at a rather high level (that is more or less my job at a software development company). I think I have had 3, all of which were due to using Dynamo as a preliminary prototype for a larger project which had potential to become a formal product offering. In those cases my preferred method has been using a licensed zero touch package that throws an error unless youâre logged into an Autodesk account whoâs ID is on the encrypted list of approved IDs. The resulting solution:
Licensed so that you have legal backing should it be reverse engineered.
Zero touch so people canât just remove the authentication mechanism via double click, highlight, and delete.
Autodesk ID so that people have to hack a 2 factor log-in to get around approval.
Encrypted IDs means youâre hacking the file to force an ID on the list.
Deploys as one packaged offering, without requiring external server access of any kind (preventing the âI canât see the licenses.txtâ).
Being C# based it converts to a standalone app more readily as Dynamo has validated the functions and the graph allows calling them in the desired order.
Again, you have to have a demonstrable business case to bother with any of that as itâll take a month or more to stand up correctly. And those demonstrable business cases are far rarer than most think (rule of thumb: could you get people to pay a million dollars to use this or an evolution you build over the next 3 years), and even more rarely can be put into a script. When you add in the speed at which AI tools are starting to produce content similar to what you get with Dynamo and help users riff on what youâve built, the potential business value becomes less and less about âwhat you can do with Pythonâ and more and more about âwhat you can do to make this robust enough to scaleâ.
(PS: I keep unmarking my first post as solution - as this should be a discussion. There is valuable insight here and as I said before the effort @ahmed.roushdy put in to build this is good - just not something I would personally implement)
I really benefited from this comment, and I will consider every word and evaluate the tools and ideas you provided if I want to sell what I do to make money, as what I have done now suits my small business environment.
As others have said, a .txt file locally along with some logic in one python node isnât going to stop anyone. There are ways to actually obfuscate Python code, but would involve writing your own interpreter node. I think this is interesting research, but even your, âDM me for the custom nodeâ is (to put it bluntly), exhausting and in an of itself an attempt to âprotect your ipâ.
I will end my comment with,
I have never thought to myself,
âGee, I wish Python scripts in Dynamo would take LONGER to runâ
Benefit here is that pyc files can not be decompiled readily (more akin to C#), like C# theyâre closer to machine code which means they should be almost as fast to execute, but in my (admittedly limited) testing interop with Revit API got a bit less reliable, with known CPython bugs becoming more exaggerated and error handling getting harder to diagnose (and harder to troubleshoot).
) Defense: Crucially, the Custom Node includes a mechanism that detects if the protection node itself is deleted or bypassed. Attempting to delete the node triggers an execution failure, ensuring the security layer is non-removable.
.