But before going any further, and in particular before implementing the truly useful part that would be to be able to send data from Blender to Houdini Engine (what I call “support for SOP nodes” in the readma), I would like to comply with the restriction of the GPL.
To do so, I would like to make the intern/hbridge library I introduced dynamically linked, instead of statically linked by Blender. Could someone help me with this? Any other suggestion or feedback is welcome, of course.
Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)
No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?
According to this interpretation, dynamic linking would not help to comply to GPL requirements.
Hi @brecht, indeed it is not enough, I am aware of this, but it is a first step though.
As stated in the README of the branch, I would like to write a drop-in replacement for the proprietary code dependent DLLs, but I first have to make this part of the code (intern/hbridge) a dll with a very small ABI.
Sorry I did not take the time to precise it here at first, and thanks for pointing out the dynamic linking limitation!
I can’t give specific legal advice on this, but generally I would say the GPL is more about what the effective resulting behavior of the software is. A modifier that’s working as if it’s built into Blender could be considered a combined work regardless of the implementation details. Adding more layers in between doesn’t really change that.
Any reason you are doing with as a branch instead of an add-on? I feel like you might just make it an open-source add-on and say screw the GPL, people who want to download the add-on are free to do so, obviously without changing the Houdini company’s intellectual property.
It’s no clear to me how you would go about writing a replacement for the Houdini Engine library. That would be a huge undertaking, even to just do a subset useful for mesh modelling?
As far as dynamic vs. static libraries go in the build system, probably you’d make a variation of blender_add_lib that produces a dynamic library by calling add_library with the SHARED parameter. I think the code for linking this to the Blender binary would be the same as a static library.
@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).
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.
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?
@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.
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.
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)
@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.
@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.
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?
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.
