Reimplementing the Houdini API as a no-op GPL stub is something that may infringe SideFX’ copyrights.
Once again, I am not reimplementing SideFX’ API. What I reimplement is my own API, for the intermediate program I called here “hbridge” (I should find another name, not Houdini-related).
I think it is time for a little drawing:
My idea is to define some open API in the same spirit as OpenFX does for 2D compositing. There are multiple GPL implementation of an OpenFX host, nothing prevents it, even though some OpenFX plug-ins are closed source. Since there exist open source OpenFX plug-ins (like all of Natron’s nodes), then an OpenFX host can be GPL.
Same here, let’s call it “OpenShapeGraph”. Blender would be an OSG host, and there would exist open source OSG plug-ins. And as a Houdini-based OSG plug-in that would happen to be compatible.
I strongly believe that this actually is the spirit of the GPL: forcing one to route code through open APIs to foster open source alternatives. Because by doing so, we pave the way toward an open source substitute for the Houdini part, so in the end, thanks to the constraint of the GPL, my implementation of the Houdini-Blender bridge helps spreading open source software. I would love to see an open source alternative to Houdini and this may help.
To take another example, if Allegorithmic would like to develop an “Substance Engine for Blender”, they would then have to go through this work of defining an open plug-in standard and this would be good for the open source community. I think that this is the spirit of the GPL, the GPL is not meant to frustrate developers but to foster the emergence of standalone open-source ecosystems.
edit: As I read OpenFX’ specification, I realize that the Core spec can be used as is in our case, because it is quite general. We could write a “Mesh Effect” OpenFX API, similar to the “Image Effect” OpenFX API used by Natron and the likes.