Ethical dilemmas with an Open source and DLL or wrapped (paid) packages

FAQ
1

Does anyone beginning to have an ethical consideration with packages wrapped into DLLs?

I appreciate packages I can unravel, learn from and distill down to just the code I need (Yes I leave the original ownership lines intact unless I rewrite most of it) But I am seeing packages wrapped up in DLLs that prohibit access to the code. These are faster but limit portability in large organizations.

Dynamo is an Open Source project. For the beginner user in a one machine shop packages aren’t an issue- but when we look at portability and Dynamo as a player- I constantly ran into issues with mismatched or out of date packages… the forum itself has quite a few where packages aren’t listed, or are unavailable, or have morphed into something that no longer works with current versions.

The BIG question is - should we as end users or Autodesk as purveyors of content REQUIRE all the source remain open source for learning and access?

And most of all - I hate seeing packages-for-purchase as it wrecks the whole open-source flow and puts the kibosh on collaboration and portability.

1 Like
2

I think I might have to disagree with both of the statements that you made.

First and foremost, Open Source doesn’t mean it’s free (free as in beer to reference the great Richard Stallman). It means that you have unhindered access to the source code, and depending on licensing (yes please pay attention to licenses), you might have freedom to copy, distribute, sell, etc. The benefit of that is that it’s difficult for an open source tool/code to just disappear from the market. You know, once on internet, always on internet.

Now, packages that are wrapped into DLLs don’t necessarily have to be closed sourced. I certainly use that mode of development for the archi-lab.net package and it’s still open source: https://github.com/ksobon/archilab So are my Mandrill, Mantis Shrimp and Bumblebee packages. They all use DLLs for parts of their functionality yet remain open source. The only thing that a DLL file does is obfuscates the access to the source as it’s not direct. Check the documentation for the package and you might find that its source is still available.

Of course, yes, there are packages that use the compiled DLLs not just for ease of development and enhanced functionality, but also for privacy, and they are not open source. What’s wrong with that? Appreciate the fact that they were made available to you at no cost, while there was a significant cost in time, and money for the developer maintaining the package. This doesn’t hinder the open source community around Dynamo at all. If anything it’s just a sign of a healthy community, because it now attracts professional developers that are concerned about their IP rights, and deem their code commercially valuable. Chances are that it might be some good code. And, if they are asking to be paid to make that package available? So what? It’s their right. It sure as hell was their time they spent building the package in the first place. Would you work for me for free? Probably not, why do you expect others to do that for you?

As is right now, I haven’t personally seen a Dynamo package “for sale”, but I am sure they will pop-up. I have no problem with that, and it comes from a guy that developed 4 open source packages for free. People engage in the open source community for different reasons, me, nor you, and especially not Autodesk should be in position to stop them from doing what they are comfortable with.

Selling packages would by no means curtain collaboration. We might have different definitions about what collaboration is. I for example would say that you are quite a poor performer in the collaboration category because I have never seen you contribute code back to one of my free and open source packages. That’s my definition of collaboration, but others might have a different one and consider being active in the forum, reporting bugs etc. means that they are great collaborators. Both are valid points of view. Just to close this out, I will give you an example. Python is an open source programming language. Should that mean that no one should be allowed to build a great tool or service using Python and sell it? Try telling that to Google. Their entire platform is built on it. You probably have Gmail, or Google Drive, or used Google Maps, Google earth… Wouldn’t that make your argument cynical if not outright ignorant?

I am by no means calling you cynical nor ignorant, just trying to make a point.

Cheers!

9 Likes
3

For now the curt nature I will consider as just direct. I wouldn’t have posed it is an ethical dilemma if I weren’t inviting conversation. The apache license driving the Primary DYNAMO code license-is open and obscure, ambiguous at best- as any code that runs in the package could be construed as derivative and falls under the same licensure… " to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work" which allows licensure up until litigation then all access to the source is off (If my quick-glance legalese is up to date).

Konrad- you are a Dynamo + API guru; I have seen you a lot as I have sifted through (thousands…?) of posts here and elsewhere. Coming from an Architecture and CS background(more as a hobby these days) - I understand hard work and coding put into these notes - Archilab’s (yours) in particular : ) I am thankful for what you have brought and your insights are keen and helpful.

Part of the dilemma I have with a bound DLL package is why bother when API add-in would be much faster. Seems like a prelude to locking in then to sell the bound node- which I do have difficulties with. I talked with my company frequently about NOT locking up families and content as it creates a wall between us and consultants saying “this is mine- don’t touch”… but when it comes to problem solving- can one person bind or withhold and expect to ask for help without being hypocritical, fascist or an an outright user of others? That is where collaboration gets killed.Almost hyperbole - but It is a fine line.

Dynamo script is made to be edited, tweaked and rehashed. Given DYNAMO is at least 10 X slower than the API why create bound nodes at all- why not just create addins? Compiled nodes it is the first step to commercialization- and as soon as capitalism is involved - collaboration falls to the wayside for profit- seen it time and time again.

Otherwise why not compile the nodes as branches off the main Dynamo Revit library so it is all baked in to the main distributable? Is someone there not taking others coding seriously and bogarting the code? Yes that could be construed as Lazy- but distributing to thousands of users is not easy- nor consultants- keeping folks on the right version alone is a massive undertaking.

If we could take pieces of Dynamo and Compile and decompile them to/from groups that would be the ideal.

If you look through you will see several areas where I have posted PY nodes with source and routines- I am just now starting to dig in hard core to generate a line work substitution routine and my frustration hit overload with the 'nth example with packages that didn’t work or were bound up. I am stuck in Dynamo at the moment as I don’t have time to re-learn the current Visual Studio or open coding platforms at the moment- I don’t do packages for the aforementioned reasons above as more BIM Architect than coder.

We could use an open source DYNAMO standards cleaner and rehasher. I know it could be done in the API- Just don’t have the knowhow at the moment to under take that- so I nibble away at it through PY and DYNAMO>

4

Hi Ron,
I had a few thoughts regarding some of your comments.

How so? Dynamo nodes support a “kit of parts” style of thinking. Example: Rather than me (john) make an addin to “fix” a user’s dimensions strings, I simply give you the pieces to do it yourself in node form. (Ex. Below)

20180420-dimensionExample
20180420-dimensionExample1484×769 283 KB

Tell me how the heck I am supposed to know that this is what the end-user wanted to accomplish as the end result had I built it as a single button add-in? Also, this specific example uses methods available in Dynamo (not the RevitAPI), combined with RevitAPI methods. The comment about “Creating Revit add-ins being faster” seems to have very little basis.

Are there any facts to support this? “Plug and chug” methodology with the python script editor is WAY faster than:

  1. Starting a Visual Studio Solution
  2. Building out the addin.
  3. Debugging
  4. Dismissing unsigned code windows constantly.
  5. And who knows what else.

Konrad has done this several times. There are a few others as well. As to why I make custom packages instead of doing this is simple. First, I personally don’t believe I am at the appropriate experience level to contribute in a meaningful way, and second, having a sense of branding and ownership is pretty cool. Considering all of the development I do on Dynamo is primarily free, I really like the idea of getting some credit and being able to receive feedback on my nodes.

Thankfully, Dynamo supports the ability to poke and prod at the API without learning all of that other stuff. Additionally, you have access to a bunch of free packages (open and non-open) to allow for you to explore further. That definitely is faster than reprogramming the API calls yourself :wink:

To round out my response. I have to say, I am in complete agreement with @Konrad_K_Sobon’s comments and I won’t touch on anything he mentioned any further.

The logic that is being presented in this thread is a bit troublesome to say the least. Using this logic, that means every Dynamo graph you have made needs to be immediately made public because Dynamo itself is open source. How does the idea of uploading all of your DYNs to here make you feel? I for one know a ton of people who would be firmly against an idea like that and would probably stop using Dynamo as a platform.

_*another thought… I may be off-base here. But to my understanding, there is nothing in the Apache license preventing people from building their own Dynamo and selling it, correct? I am referencing section 3 here, https://www.apache.org/licenses/LICENSE-2.0_.

Also, the very definition of open source allows people to pretty much do with it as they please, https://opensource.org/docs/definition.html

Thanks for bringing this up though, it is a good discussion to have.

-John

2 Likes
5

I mean NO disrespect to Konrad- he has been very helpful to me directly in the past. I did not realize his code was ending up in the Base Revit Dynamo … Mea Culpa! : ) (And Kudos to Him for solving the issues and getting in)

We all have egos. Ownership is moot when content is share and collaborated openly as it has been here in the past : ) However, now bound nodes like those from the ZeroTouch process hard codes process from C# to a DLL prevent users from exploring how things are processed or dissected - taking things outside dynamo and effectively locking it up. I don’t want this to happen to everything! Advantages come with the disadvantages.

Tell me how the heck I am supposed to know that this is what the end-user wanted to accomplish as the end result had I built it as a single button add-in?

Loseley Using your example as I don’t understand how Rythm or you code works on the dims in this case - If I wanted to have those dims stack on top of one another- how do we do that?(We stack, we don’t alternate) I cannot look in the rhythm package and extract the PY or C# nodes because it is bound. There may be a way to alter the dimensions, but that is a dead end and I have to look elsewhere because of a bound node.

But - if that ingram, that tiny piece of code is fundamental atom of existence to Dynamo and Revit where the functionality is perfect and does everything revit allows for that object- why is it external to Dynamo and not incorporated into Dynamo base package for distribution?(Konrad apparently incorporates into the primary package- what about others?) Are the Revit Dynamo owners bogarting the code?

The Rhythm compiled DLL node is faster to execute while in that node- but has portability issues for medium or larger distribution groups- or looking back to old vs new versions. Potential security issues, etc. I am not going to the extent of reverse engineering through a decompiler to look at code - nor sould anyone have to.

I like the idea of credit- I get a better feeling knowing I helped someone solve an issue and made their stress levels go down and gave them some job security : )

For the best possible payoff for everyone involved and for what is is worth, I am not a noob in Dynamo, nor am I advanced~ so my solutions and offerings have limited value; I share them when I feel someone could benefit. I Share in the hopes of helping others as I have been helped from others providing like and the same. Like parallel processing - we can all solve problems faster by sharing rather that locking everything in silos. I could only one of a few that thinks this way which is part of the reasons why I ask questions like this. from the responses I can measure if varying degrees of altruism are present (or not) to help me judge if I am too far out on the limb, or not far enough.

Apache does not prevent you from selling, but in the event of litigation - particularly regarding patent and ownership - I believe they have the right to “cut you off” from the trunk:

…then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed

//Good summary on licenses here.//

6

And I know folks are busy- and here is proof I am not trolling and do share DYNs: Objects to Worksts based on assembly codes

It isn’t fantastic but some folks do use worksets by Major Assembly code…

More (I was reminded to follow up today : ) on my page. They aren’t earth shattering but hopefully they help : )

7

No, AutoDesk is not holding onto this with an iron fist. Look into the contributions made by others in the Dynamo 2.0 release. Each release has included more and more contributions within the larger scope. Having that as an open ended tool is more important.

If the question is why there isn’t more of this? The answer is mostly because the core users are trained as architects not as coders. So most nodes written fail to meet the requirements for integration within the larger distributable. They also often fail to have the overall simplicity to meet the needs of the many, while maintaining the flexibility needed to meet the needs of the few. Johns script above actually does this. You move the first point by 0 on the X and y direction, and the second point can be created by moving the first

I agree it’s nice for a mid-level user to be able to pry apart the inner workings of the custom nodes. It’s how I ‘grew up’ into the user I am today. But that certainly doesn’t make zero touch nodes less useful. In fact including that function opens up results above and beyond the uses you’re fixating on. As an example, try calling MS word add in functions via python. Or specification writing software. Because the dlls can be called directly via zero touch firms can now assemble pieces beyond the limits of the base Revit.

9

Sorry if it sounded like I was beating on you @Ron_Allen! I actually share many of your concerns, and in fact voiced as much in a previous post, with @Andreas_Dieckmann pointing out that he had no plans to close out his work at any point, which pretty much made my month. I just intended to say that I understand why this was opened up, and that overall I think it’s a good thing.

As @erfajo said (better than I put it), the ability to access other stuff in a .net environment is the biggest gain via the zero touch aspect. Well in my opinion anyway. This shift does require that package maintainers share the source code on a GitHub or similar for people to reference, which while one more thing for them to have to manage, also means that others can fork, edit, improve, alter and otherwise contribute. In a perfect world more community members would contribute to the various repos, but I do understand the intimidation factor Ron expressed before. It’s scary stepping that far out of your comfort zone.

3 Likes
10

All excellent points.

While I understand @Ron_Allen concern and the very real utility to be had in exploring through the more easily accessible, I tend to think the move to more zero touch nodes coming from a general rise in sophistication in developers of Dynamo packages.

This may lead to more commercialization and closed packages but that doesn’t mean that there will be no open packages that are still useful. That also doesn’t mean that there won’t be resources for the interested Dynamo user to learn from. The Revit API is a good example of this. While most high quality add-ins are paid add-ins, there are lots of places to find code examples, ask questions and just generally learn about add-in development. The overall add-in landscape is richer for having both open source and paid options.

For me, the choice to primarily create zero-touch nodes had nothing to do with keeping my code away from others or its potential for commercialization. Compared to python, zero-touch nodes are much easier to handle complex data and algorithms. While speed of zero touch nodes is a nice advantage, it was not a primary consideration.

By their very nature of being interpreted and essentially being a single function, python nodes tend to be simpler. Being loosely typed, Python also requires a lot more careful type and list management. C#'s strong typing can be a pain sometimes but leads to very robust nodes.

In my own package development, I found creating .Net based nodes much faster and the nodes much more robust and less error prone then developing in Python nodes.

As @john_pierson pointed out, there is a certain flexibility to developing nodes rather than full add-ins. That is the power of dynamo, to be able to prototype full functioning workflows quickly without the need for a add-in. My opinion is that once a workflow is developed that is stable enough and useful enough then it should be an add-in. The main advantage with developing nodes over add-ins is that nodes require a lot less error handling and no User interface. Both error handling and UI development is time consuming and doing it well is difficult.

As for whether to contribute to base dynamo or to develop your own package, I do believe there should be more contributions to the base dynamo source code. However, I am not a professional developer and struggle to achieve the quality, testing and submission requirements that is needed to make it into the main base. THIS IS A GOOD THING! Base dynamo should be high quality. But if I am going to learn to contribute, like Konrad has, then I will need to continue to learn to develop Zero Touch nodes, not python nodes. I have read and heard various members of the Dynamo development team express interest in having more community contributions. They want all of us to get involved, but it is a daunting task for most of us.

In the end, my choice to develop zero-touch nodes has nothing to do with my commitment to open source. I develop my package through git hub and is is available for anyone interested to look at the code. I don’t see a conflict between the two approaches.

3 Likes
11

Having the means to port to native code or an addin would make my day… and then add and call other items that were wrapped this way- then the ability to unwrap those as needed to pry apart the code. That is where I hope this leads. Much like converting the old VBA modules to an addin.

12

@erfajo Well put sir! : ) Exactly my point. @arthur.mcgoey also thanks- well put. As dynamo evolves I would love for it to be a hold out for open source. Perhaps as I get back into programming in C#/VB I will begin to feel more like the higher end coders… but stuck in the middle as I am now, having especially those PY nodes is incredibly invaluable to dissect, pull apart, and recode into something that solves my specific problem.

With Dynamo being relatively new, it is still growing and evolving- hopefully to the betterment and not the detriment of the community.

2 Likes
13

The drawback to open source and compiled binaries has finally reared its ugly head.

Twelve malicious Python libraries found and removed from PyPI

One package contained a clipboard hijacker that replaced victims’ Bitcoin addresses in an attempt to hijack funds from users.

Complete article here:

This is the first real example I have seen in Python and exactly my concern with zero touch or compiled nodes. As much as I would like to be idealist in painting open source as idyllic, we need some sort of block chain and trusted publishers to help keep the bad out; and a way to decompile and check those nodes back into python or some identifiable familiar language. @jacob.small

14

Hey @Ron_Allen - long time no see.

I saw that (or a version thereof) recently. Malicious code in Python is nothing new. Also, PyPI lacks some basic functions which in my opinion would actually help keep you safe. Features like download count and the ‘hey this could harm your system so be sure to check it carefully’ message go a long way.

In this case, each of the malicious packages used a typo-squatted name, but had minimal downloads (50ish noted in one of the malicious packages, while the ‘real’ version has over 9,000 dependent repositories). For Python in particular there are many scarier package stories out there than the one you posted. Try this one for example:

I have significant doubts that Dynamo packages have the ability to run at that level, but I’ll discuss with the team at the next check in. For now if you’re worried about the type of issue you shared, stick to the following:

  1. Try to keep to the frequently downloaded and well known packages.
  2. Maintain and distribute a package repository and direct users to talk with the management team if they see a need for new packages to be added to that rather than downloading whatever they want for themself.
  3. Test everything carefully, unpacking dlls and reading your python nodes as needed for you to feel comfortable with them before installing anything. It’s always a good idea to do this anyway, as you will learn more and be able to see ways you can leverage methods in the future.
  4. Maintain and uphold normal security measures. I bring this up as most people fail to do this. Remember, you’re still WAY more likely to be impacted by a .html, .zip, .jpg, .doc, .dwg, .xls or a litany of other file types than you are Dynamo, as those vectors are by far more common.
15

Hi @ erfajo

This topic is very hard for me as am still a wanderer in Dynamo and Revit but .as you said-

Blockquote
Profile - erfajo - Dynamo
Revit is a clear image of that. Revit was brilliant in early 00’s but is now passed by other software.

I like to know what other software s are better and why… as well some guys suggest that it is better to know 3/4 BIM softs at a time (Help me to choose: ArchiCad or Revit. And Why - modlar.com), that’s why am asking and I feel Revit’s massing environment need to be updated. You might share some links also which could guide me in this regard or your valuable experiences as an experienced user of those software s. If it needed a new topic (here or in Revit forum or to merge in an old one anywhere), I think we need to do that.
Thanks in advance.