I’ve been working for some time on an extension of OpenFX to 3D mesh effects, that I’ve called Open Mesh Effect: https://openmesheffect.org
The whole context is explained more in detail on a blog post, but long story short, I would be interested in some feedback from developers who worked with OpenFX, whether on the host (e.g. Natron) or on the plug-in side.
How do you feel about this API, do you like it? What are the most frustating things that you have to do when dealing with it? Are they things you could not find how to do with it?
I won’t change OpenFX regarding 2D image effects, but this would help me design Open Mesh Effect!
That’s a clever move, but if Blender never considered adopting OpenFX, why would they support openmesheffect? You would have to be more convincing (or maintain your own blender branch)
About the non-GPL plugins used by a GPL app: I would say that as long as the app is fully functional without the plugin, and the plugin is distributed separately, then the plugin is not a component of the app.
People in the Natron community do not think that people infringe the GPL by using non-GPL (including commercial) plugins, because Natron can be used without these commercial plugins. But, as the GPL FAQ states, “This is a legal question, which ultimately judges will decide” Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation . Note that this sentence has been in the GPL FAQ forever (at least 18 years, see Frequently Asked Questions about the GNU GPL - GNU Project - Free Software Foundation (FSF) ) and judges never had to decide!
Whatever Blender or GPL afficionados may claim, this is just common sense. And this is just the same as with Linux proprietary kernel modules. Linux is still GPL but is capable of loading proprietary modules. You can read Linus’ thoughts about that: proprietary-kernel-modules
If you really want to protect yourself against this situation, I would say that the OpenFX API should be rather easy to serialize through sockets, at the expense of performance. In fact, this is a solution that I looked into when I first wanted to make a GMIC plugin (GMIC has a GPL-like licence, and Natron was not GPL at that time, and we even kept the possibility of a Commercial licence for Natron until last year).
My goal was to make an “isolation layer” that would convert API calls to socket read/write on the OFX host, and on the other end a server would be in charge of loading the plugins and executing the stuff. Because OpenFX uses “handles” - (with a few exceptions such as kOfxPropHostOSHandle which is really a pointer), this should still be possible. But, in my opinion, this is a waste of time.
You can thank Bruno Nicoletti (founder of The Foundry) for such a great API.
Also, I would recommend that you talk with other people from the OpenFX Association, especially Pierre Jasmin from RE:Vision Effects (you can even speak French with him).
Hi Frédéric,
Thanks a lot for this detailed feedback!
Indeed making this standard supported on the long run will not be easy, so for now I obviously started with my own branch of Blender: https://github.com/eliemichel/OpenMeshEffectForBlender
Until it is mature enough, and features some actual plug-ins, there is no point for merging it upstream.
This is something different from OpenFX image filters anyways, impacting very different parts of the code, so even though the standard relies on the same mechanism, it is and will remain independent on the choice of Blender devs to support or not compositing OpenFX effects.
About the GPL, I think I’m covered enough if I do not distribute my Blender branch together with closed source plug-ins, and if there exists at least one GPL-compliant plug-in. I won’t go into the extra trouble of running it over sockets. By the way, thanks for pointing out the example of linux kernel modules, it is very relevant, and adds up to the list of jurisprudence cases supporting my method.
