Any ideas on how to add a license mechanism to a Dynamo Player script?

Developers
1

Hi folks,
Does any one have any good idea (or experience) on how to license a Dynamo Player script? While I am happy to share a lot for free (and will continue to do so in the future), I do have some more complex ideas I would like to make some money of (you know, for food, rent and such… :wink:).
The current way I am exploring is to write C# (which I still would have to learn) instead of a .dyn, but I was wondering if there are any other ideas out there for that?
Thanks,
GG

1 Like
2

An easier way to get paid is to sell your knowledge. A training, or consultancy, support with writing graphs, things like that. If you sell graphs with some support, you don’t have to worry about licenses.

3 Likes
3

Depends on the use.

Dynamo has three goals (my phrasing is off but the intent is there - not booting up my PC to find the official wording):

  1. To provide a simple but capable programming tool
  2. To enable users at every level of ability
  3. To foster and grow a community of users

Licensing or blocking execution of dyn files is up against numbers 2 and 3, and in some ways 1.

As such .dyn files aren’t secure in that anyone can open and edit them as well as share them (both of which are part of the community). Same with Python. So if any any point you distribute that type of content someone smart enough will be able to pull it apart and remove your licensing mechanism (i.e remove the node, or take out the few lines of Python).

I have see people who have claimed to build a mechanism which plays the .dyn without exposing it (similar to Dynamo Player) but I am 99% sure that if things are on the disc they can be edited all the same.

This doesn’t mean you have no options here, but that it is not easy.

  1. Host part of the code remotely. Force a user to pass a valid token to get access to the important bit of Python script which your graph requires to execute. Pass that Python to the graph and out into a Python Script From String node. Your users will have to pass the token over the web, which means your tool will need web connection to run and advertise that it is sending and receiving data. Many will avoid using it for this reason, so your licensing will cost you users.
  2. Provide part of the code encrypted. This would require passing a token to decrypt the content and allow execution therein. This is more apt to keep users from avoiding the tools, but it is still somewhat restricted.
  3. Write your code as a zero touch node, using a token validation to allow execution. This requires you learn some C# to build the node, but it is less of a jump in knowledge requirement than you get to a complete add-in.
  4. Move to a complete standalone application or add-in. This is what you were after before.

Three of the above require passing the authentication method. This isn’t easy - and the mechanism thereof will require some thought. Could be a Dynamo extension. Could be an external tool. Could be part of the node. Could be just about anything. You’ll have to think it through carefully, and that mechanism will have to be passed along with the rest of the code, and incorporate some means where just passing the package along won’t enable the tool again… oh and you’ll have to manage the this in the great many Dynamo builds which are out there - so at the moment this is between 2.10 and 3.3…

When I have seen people attempt all of that, there is always an easy win early on. Five days later there is a roadblock. And then a day later another. And another. And on and on until the person trying it gives up or moves onto a full application.

One last thing to note: when you get into building this stuff out be very careful of the content which you consume or pull code from. Every package on the Dynamo package manager, and even Dynamo itself has legal protections which makes incorporating them something difficult to navigate without legal guidance. A zero touch node is likely the easy way forward, as that is the least likely to cause constraints and the easiest to get started with.

1 Like
4

Thank you both for your answers here!
Especially Jacob with your findings, that helps! :slightly_smiling_face:

1 Like
5

C# is the way to go if you are going commercial. Really the only way to go.
The end user gets a more refined interface.
Installation can be more automated for install on different versions.
The API is more stable than dynamo nodes.
You can draw from other installed application resources like Excel, Word, etc…
Packaging and distribution are simple.
You can use an off the shelf likening system without writing one from scratch.

6

If you really want to create plug-ins for AutoCAD and Civil 3D, then I can advise this book:

https://books.huiz.net/book/using-net-to-program-plug-ins-for-autocad/

It is quite good :wink:

1 Like
7

Small point here…

Each Dynamo node is an API which can be called directly in C# without concern… Any percieved stability is likely moot unless you’re using the Python engine to do the calls (at which point you’re fighting the conversion issues…).

Beyond that, yes C# is easier to capitalize on.

You do not have to go full add-in though - Dynamo nodes themselves are perfectly viable and can be tied into license validation. Towards that end I have a POC which validates via Autodesk account (if the email doesn’t end with the right domain the node returns “you do not have permission…”), but you could also use an APS authentication or even 3rd party mechanism just as well.

8

I should have said “Evolving”. Not really an issue of will it crash. but will the same nodes work the same way over which versions.

1 Like
9

Very good point - if you own the full system you have less concerns around required code updates than what you get with Dynamo changes. However we should remember that Dynamo updates with the host application for most functional uses. And most host applications are desktop based which means you’re getting 1 or 2 breaking API changes a year and you can update your tool accordingly and in advance of the release if you’re testing the beta releases.

But if you compare that with a web APIs… well changes will happen at any time, with no notice, and no way to ‘get it running again’ until you update your code. There is a reason ‘web tools’ have high costs, and it’s not just so the provider can make more money, and a lot of it has to do with the testing required to keep thing up and running when the integrated components are updated.