I have to confess I have hard time understanding what you mean, if you asking me whether it is possible to add code to Blender without adding code to Blender , the answer is of course, yes.
DLLs is the way I do it for my project, although I use C not C++, not that it makes a difference. As I said I created my own plugin system for a commercial version of Blender I am developing, basically implements my features only in DLLs. Those DLLs are not even needed to start Blender. I can open and close them manually from Python , I do this to reload changes I made in the code without having to terminate Blender and to speed up compilations times. That means I build them separately from Blender.Which helps me reduce compile times even ten times depending on the situation.
As long as you donāt try to license the code under other license than GPL you are fine, because unlike LGPL, GPL also covers DLLs.
The plugin API I have developed is only for C and only for my needs , its not meant for general consumption but theoretically one could use it to add any feature imaginable. Those DLLs, I call them ācomponentsā , have also access to Blender internals so they can do anything normal code that is added directly to Blender source can do. Of course implementing the actual Plugin API means I have to add it to the Blender source code but is quite minimal and does not mix with existing Blender code to avoid conflicts , it lives inside separate source files. Components also can be accessed directly from Python without a need to wrap them with additional C code , which is the normal way that Blender Python API works. I do however make my own Python API in case someone wants to add component functionality in their addons the easy way. Components themselves are purely coded in C for performance reasons. Of course components like addons are cross platform, like addons can easily be updated and like addons you can turn them off or on or even combine them. They are also not affecting blend files or cause any incompatibilities with Blender, or at least that is the intention. They are not meant as addons replacement but designed to work together with addons. They are basically C addons.
Why you think this is a no go ? How exactly one can hurt Blender code ? I am sorry I am confused with what you actually mean.
The only things that matter to me, is to respect the license, keep 100% compatibility with Blender, offer enough features to justify the asking price and hopefully contribute some of the code back into the Blender main repository if the devs like my code. Is that not enough ?
I would sacrifice my first born, problem is that I donāt have kids
Pretty much this covers the topic of what I am saying.
The point is to have the plugin system setup as you mentioned for the simple reason to minimize any risk of legal conflicts from cross-pollinating two codebases. Not to mention that also in terms of software architecture the plugin system is a more proper way to add features and avoid monkey-patching existing code.
You can use the plugin architecture to double license your code. GPL and even closed source, of course that would require to build a platform as well that allows you to easily move components between apps. As long as the component does not directly depend on Blender code GPL cannot stop you.
In my case I am GPL all the way because my component are deeply dependent on Blender source because they directly access Blender functions. But it was never my intention to double license anyway. My project after all is to extend Blender.
If the component depends on Blender code or even worse contain even calls to Blender functions and you try to double license it you are in for trouble. So its not enough to have plugin you have to make sure your plugins are Blender āfreeā and not tied to Blender source in any way. See Cycles for example.
So a plugin system is by no means a perfect solution to deal with GPL or make it easy to update code, it has its own issues. As long as you know what you doing and you play fair, you will be fine. Make sure you understand GPL first very well.
I donāt see how plug-ins would change anything. The GPL would then apply to the plug-in just like it applies to Blender. That is even stated explicitly in the Blender FAQ:
Can I sell plug-ins for Blender?
Yes you can, but only if you provide the plug-in and the sources to your clients under the GNU GPL license. The client then benefits from all rights the GPL offers; free to use it, or even distribute it when they wish.
Hence why I am talking about āComponentsā. Its easy to get confused. In the links plugins is refered to addons, addons depend on the Blender Python API thus are bound by GPL. If you design your component in such that does not directly access blender source you can avoid GPL when you use the component outside Blender for another app.
Itās a bit like bytecode of Python running on top of Python VM. Of course you would need a platform for the component to sit on and that platform will have to depend on Blender source and thus it will have be licensed GPL only.
Remember I am talking here about double license not completely avoiding GPL, if your component is meant to run on top of Blender it will have to be licensed GPL. So you cannot avoid releasing the code. This is why I told you to look at Cycles.
So GPL cannot be avoided with plugins, you just gain the extra ability to have another license when the code is not run on top of Blender.
In case of Cycles it was useful because some apps plainly do not like GPL making it possible to port it to other 3d applications
Thats the thing if you run the component outside blender , lets say Maya, you wont have any connection with the GPL source or dependency. Of course you wont have any connection with āshared complex data structures eitherā. Because DLLs by default they do not share memory, which is the technology that plugins use. If you make use of shared memory sure,you are bound by GPL.
What you link is shared data, I don not talk about that scenario. It also talks about whether GPL can be avoided, I am not talking about that, GPL cannot be avoid, I am talking double license which is another thing.
They do. DLLs (or shared libraries on other systems) share their address space with the host application and are able to exchange pointers and read/write each otherās memory.
Anyhow - regardless of the tech details, my point was: adding a plug-in API to Blender would not change the situation with the GPL license at all. I know many ask for a plug-in API, but some my have illusions about what such an API would do or not do for them.
yeah its way more complicated than that, if you try to directly access a loaded DLL you going to fail. In order to gain access you have ask for the pointer to the address of the data structure and function. It also works the same the other way DLL needs pointers to executable memory and it also needs function pointers to access executable functions.
However I am talking about DLLs that loaded during runtime without the executable having any dendency to them. For example DLLs can be compiled together with the executable to avoid the pointer hell scenario this way the executable can directly locate DLLs features.
However plugins are not build like that , I think, at least not my components.
Well in my case which is why I call them ācomponentsā and not plugins, I also import calls, my components can execute Blender functions. I do this to move my code completely to the component. So I am practically married with GPL and we have kids together :D. Which way I said in the first place that my system is unsuitable for double license, its hardcore GPL. But that also makes them way more powerful than usual plugins.
You can call them components, plug-in, add-on or modules - - itās only names. The GPL is defined around āderived workā and ācombined workā and not specific to implementation details or language semantics.
I am not question GPL , I will tell it again, I was refering to the act of multi licensing which is what Cycles does and how you could do that with plugins and why my system is unsuitable for such scenario. I stressed again and again that GPL cannot be avoided.
I call them components because they are not plugins, plain and simple, afterall most people things that addons are plugin anyway. I dont call them components because it sounds cool.
They are definitely not modules, because modules for me are more like libraries and definitely not addons cause they are coded only in C. Sure if we stretch the definition yeah, but in the end the devil is in the details.
anyway I cannot make myself understood, cannot make it any more clear sorry. In any case my code is 100% GPL so I do not care for those scenarios anyway.
My apologies, I must have sounded more aggressive than intended. I did not mean to talk about whatever it is youāre building at the moment, I was just in general talking about schemes to avoid the GPL. Iāve just seen too many ācreativeā ideas of working around the license, which in the end all just were elaborate reinventions of RPC and shared memory.
I understand that the GPL is a hindrance for many things - it is unlikely that Blender will ever see a rich ecosystem of high caliber commercial plug-ins like commercial packages enjoy it, forced publication of source code is not an option for many. This is frustrating for both users and developers alike. However, I am convinced that if it werenāt for the GPL, Blender would not be anywhere near where it is today.
And their is already V-Ray, Octane for the closed source plugins (which also require their forked Blender version and use sockets iirc), and cool GPL plugins like flip fluids, which uses C or C++ code on top of the python API. So the Python API and the GPL already allow a lot.
Regarding Cycles, itās indeed Apache, so that Rhino, insidyum (with Cycles4D), etc. can take it all in their closed source programs, but I canāt remember any closed source app giving substantial code changes back to Cycles?
Did they ever make any substantial code changes to Cycles in the first place? I donāt think their Cycles version is somehow more advanced than Blenders.
No need to apologize, you never came remotely close to sounding aggressive.
Its my fault because I have the tendency to love writting text wall.s
The summary of my point, even with plugins you have to design them in specific way in order to not violate GPL. Thatās all.
I used to be against GPL, I always found ironic to talk about freedom and yet force people to open source their own code just because they use open source code. However I see now that sometimes you have to put the foot on the ground and become the ābad guyā to make sure freedom is protected. Now I am in favor of GPL.
Frankly the biggest misunderstanding is that FSF the ones that made GPL does not want people to make money with open source. Quite the contrary they support making profit not only creation open source software but also distributing it as long it obeys with the license and has good intentions. Ironically they emphasizes what I have always stated that the commercial nature of open source is a guaranteed of its viable because all project need funding. They also work together with companies to make sure they feel safe using GPL or their other licenses.This clearly stated in this article
- itās only names. The GPL is defined around āderived workā and ācombined workā and not specific to implementation details or language semantics.