Ok then, on a forum for Blender developers it’s not the best suggestion to disregard the license under which those developers released Blender.
5 Likes
@Keavon I actually respect Blender developers a lot, as well as their choice of releasing under the GPL. I wouldn’t have come talk here otherwise.
@brecht My plan is to make two versions of hbridge: one GPL, that does nothing; another one not GPL, but not using anything related to Blender and not distributed with my Blender branch. The API I will have to reimplement is not Houdini’s, but hbridge’s API, which would have something like 5 symbols.
Then the instruction of the non-GPL hbridge would ask its users to download the blender branch release and replace a DLL. The GPL states that any derived work is allowed as soon as it remains private. This looks like a crack, but since any user is doing it for oneself, it feels ok to me. Warning though: this MUST NOT be automatized by some package manager or other third party installer.
If this is still not acceptable for some reason, there is another fallback: I would go for a client-server architecture. This is explicitely allowed by the terms of the GPL (other wise GPL web browsers could only communicate with GPL web servers for instances).
3 Likes
Asking users to download non-free software is not something i’d like to see in mainline blender, if you distribute this dll with your addon, fair enough, I suppose you technically complied with the license *1 but still it’s not something i’d like to have bundled with the official versions.
*1 Not a lawyer, not legal advise, not speaking for the blender project as a whole.
From your screenshot on the GitHub page:
It looks like the modifier directly has a file browser link for the user to select the Houdini library path. Meaning the proprietary library has no involvement until the user selects it as an asset, just as they might select an image texture or some other art asset. Does that solution not work to get around the GPL restrictions, because the user—not the code—is linking the proprietary side with the GPL side?
1 Like
@LazyDodo I’ve never planned on making this available in the default official Blender. I’d rather try to orient it toward a way to easily add C++ modifiers at runtime, whether it is related to Houdini or not. The Houdini part itself has nothing to do in regular Blender.
@Keavon There is a missunderstanding about the term “library”. Here we are talking about the linking of software library, while the modifier reads a “Houdini asset library”, which is a file format like any other, and not related to our current issue. 
1 Like
Oh, I misunderstood. I’m not familiar enough with how Houdini handles things like files. So that “Library Path” file browser is just accessing the actual Houdini asset?
But then, I suppose, my (misunderstood) point still stands: why not let the user select the actual code library file path by hand, and treat that proprietary (code) asset just like any other proprietary (art) asset? Because it is not done by the code, but rather, by the user, that does comply with the GPL terms if I am not mistaken. It’s a hassle to browse for, but you could make your code memorize the path the user initially selects for subsequent usages of the modifier (so long as the code never hardcodes the path and requires human intervention, then memorizes that human intervention).
Still, this is such silly jumping-through-hoops to just achieve something that is universally useful and harmful to literally nobody.
1 Like
Interesting point, it could work, and it’d open up the way to any C++ modifier. Would have to define a non-GPL interface, though, as if it was a third party file format. Worth investigation.
(Yes, the Library Path is a path to a Houdini asset file, that is called “library” because it may contain many assets)
1 Like
@Keavon Just because the user is creating the GPL infraction*1 on their local machine doesn’t mean it is OK, or something we would like to encourage. But before we descent into yet another “how do I sidestep the GPL” discussion. This is not what we want, this is clearly not what @Elie wants, so I suggest you drop this line of thinking.
[edit]
*1 as @Elie points out below it may not be an infraction, but it is certainly against the spirit of the license we chose, so don’t expect us to spitball ideas with you on how to sidestep either the actual license or the spirit of the license that was chosen.
1 Like
@LazyDodo You’re right, I am not here to hack or break the GPL. I am convinced that there is a reasonable way to achieve this bridge.
Note that the user cannot conceptualy break the GPL, because the copyright limitations of the GPL apply to the distribution of the software. The user may even modify the software if she does not redistribute it.
Also, how is this problem tackled in the case of OpenEXR/Alembic/whetever non GPL library used in Blender?
Those libraries have GPL compatible licenses, but we’re derailing this thread massively, please feel free to discuss this specific issue elsewhere, blender artists has a pretty long thread on the subject.
1 Like
I am not that familiar with the way Houdini works or which libraries are needed or can be re-implemented or what they do. So I am curious, could one of you summarize what the end goal is in order to achieve the premise of this modifier feature without breaking the spirit of the GPL? Because from what I can tell, it sounds like what I see being described is that the entire premise of this modifier feature inherently and fundamentally breaks the spirit of the GPL even if we can figure out silly loop-holes that get around its wording. What sort of solution would be the goal here to make the premise kosher?
The GPL faq offers this solution.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs.
but then pretty much instantly muddies the water
But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
4 Likes
Similar to Keavon’s suggestion…
Instead couldn’t a middleware Asset Engine (handler/converter) be constructed?
An Asset Engine (Handler/Converter) could do the following;
Steps
- Open Asset Engine (Handler/Converter).
- Select Houdini asset file.
- Edit parameter.
- Asset file (temp autosave) in Asset folder.
- Open Blender.
- Append Asset file (temp autosave) from Asset folder.
- Adjust Blender Asset Refresh to desired refresh rate.
- Continue editing in the Asset Engine (Handler/Converter).
The only linking to Blender, would be by the user appending an asset file in Blender.
Blender: Asset Refresh
- An asset refresh timer would allow Blender to update the asset data after X amount of time.
Asset Engine (Handler/Converter): Asset autosave
- A (temp autosave) would allow the Asset Engine to automatically save data after a parameter change.
If the update timing of the two programs a relatively the same, the user could have the asset update in Blender within moments of the Asset Engine parameter change.
Do to the nature of the middleware, the GPL should not be an issue.
Lol. In a sense, Blender could be used as a viewport for the Asset Engine (Handler/Converter).
You could create various plugins allowing other functions/programs to do the same.
@brecht I tried your suggestion of making a variant of blender_add_lib for dynamic linking:
But it still tries to use hbridge.o/.obj when building blender.a/.lib, apparently:
10>------ Build started: Project: blender, Configuration: Release x64 ------
10> Creating library E:/SourceCode/blender/build_windows_Full_x64_vc15_Release/bin/Release/blender.lib and object E:/SourceCode/blender/build_windows_Full_x64_vc15_Release/bin/Release/blender.exp
10>bf_intern_hbridge.lib(hbridge.obj) : error LNK2019: unresolved external symbol __imp_HAPI_CreateInProcessSession referenced in function houdini_Modifier_runtime_ensure
10>bf_intern_hbridge.lib(hbridge.obj) : error LNK2019: unresolved external symbol __imp_HAPI_Initialize referenced in function houdini_Modifier_runtime_ensure
[...]
10>E:\SourceCode\blender\build_windows_Full_x64_vc15_Release\bin\Release\blender.exe : fatal error LNK1120: 22 unresolved externals
10>Done building project "blender.vcxproj" -- FAILED.
The function houdini_Modifier_runtime_ensure() is a static function of hbridge implementation, there is no reason for the blender project to even be aware of its existence…
I first though it was because the build system would force static linking of what is in BLENDER_LINK_LIBS defined in blender_add_lib but I could not find any other references to this variable in the CMakeLists.
@Dev1 Thanks for giving it a though, but imho this sounds a bit overkill. ^^ If the middleware approach works, then the strategy of building a generic hbridge should be valid too.
I believe that is your only option here. I would suggest going through an intermediate file/stream format that is open and documented, such as Alembic or USD - not only will that useful for debugging, but it will also allow it to be modified to work with programs besides Houdini.
Anything else is about as clear of a GPL violation as I can imagine: You’re taking Blender and Houdini Engine and link into a single program. You’re releasing a version of Blender for which you can’t provide the full source code, as your build relies on third party source code.
Reimplementing the Houdini API as a no-op GPL stub is something that may infringe SideFX’ copyrights. I don’t know the details of the license of Houdini Engine, but depending on the jurisdiction you’re in, simply usign the same function names could be interpreted as a copyright violation.
I understand your motivation, Houdini is a powerful software and when used together with Blender, one can do spectacular things. And it’s cumbersome when going through the import/export tools. I’m all for improved exchange between Blender and other programs, but I don’t want you to get into legal trouble over this.
2 Likes
I have also been keenly eyeing the Oracle v. Google case and hoping the Supreme Court accepts its appeal (although I haven’t seen any updates on that lately). The entire software world has operated until now on the assumption that API naming is free to use, as long as you don’t steal any code (just the names of the interfaces).
But assuming that is the case (the English text that is the name of the interfaces) is fair game to reuse, then that also begs the question: how does any add-on (for example) for Blender (or any other GPL software) actually violate the GPL license if it doesn’t actually contain any licensed code? Sure, it “happens” to be code that does useful stuff if some user decides to download that code and stuff it into Blender, but the actual author of the code just wrote their own original code, unrelated to Blender’s code. How, legally speaking, can the GPL claim to have any jurisdiction over someone’s original code?
Oracle v. Google is about a clean-room implementation. A Blender add-on does not only use the same names as the Blender API but also directly relies on their implementation by calling them and sharing data. You can’t develop a Blender add-on without using Blender.
2 Likes
You’re welcome.
The idea is more like a plug in/add on, then a full blown middle ware.
I should have thought a bit more about the usage of the terminology, my apologies.
Below is a simplified version of the idea.
Plug in for Houdini: Generate a temp autosave asset file upon a parameter change to a user defined folder. (Toggle: On/Off)
Add on for Blender: Auto refresh assigned asset after X amount of time. (Toggle: On/Off) (X: User defined) The assigned asset would be an appended asset.
The asset file format could be Alembic or something.
It would be nice to have an auto refresh asset feature in Blender. This would be helpful when working with vertex paint and vector displacement nodes.
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.
7 Likes
I want to ask you to respect the logo guidelines. This is not a product made by Blender Foundation, so you have to use your own identity. I also think Sidefx would think the same.
Just use the words Houdini and Blender, and add the logo of your own company or your name/url if you don’t have this.
Our logo guidelines: https://www.blender.org/about/logo/
Ton Roosendaal
Blender Foundation
3 Likes