Speed up non-GPL compatible renderer's Blender addon with OpenGL driver and GPL system library exception?

I made this question in a place called stackexchange, I thought it might be useful to post a link to it here too:

Blender addon interface with non-GPL compatible renderer through OpenGL driver using system library exception?

2 Likes

It’s a bit strange to ask Blender developers how to sidestep the license under which they are providing the software to you. Personally I would not recommend trying to rely on some technicality when the intent behind the license is clearly different.

1 Like

It makes sense to at least try to ask how to make my addon work normally from my perspective when the alternative is to probably to give up on making a blender addon for now.

Also, it would seem fair to me that anyone can make e.g. a proprietary OpenGL driver which are covered by GPL system library exception and enjoy normal speed in Blender for their graphics and not just some companies.

GPL is a license, it doesn’t deal with what would be fair, it sets rights for people receiving the software, as long as you don’t take away any of those rights you’re in the clear.

The keypoint is here, the proprietary OpenGL driver ships independently from any GPL software. you’re absolutely allowed to write your own openGL driver and distribute it independently, but you can’t stick it in a software package with other GPL licensed code and distribute the two together.

2 Likes

I am not considering to stick my own OpenGL driver into a Blender addon but instead to distribute one with the renderer and use it from the separate GPL addon should it be available.

Of course, this is just early consideration. However, I don’t know how else this could work. Shipping around uncompressed frames with networking isn’t exactly usable and these graphics APIs are designed to do things like that.

So we can’t mix GPL files with non GPL compliant files in the same package. Clear.

What about non-code content then?
Blender logo for example is strictly proprietary
Yet, it is not shipped separately. It looks like a convenient double standard :face_with_monocle:

The Blender name and logo is trademarked, that’s different than copyright and compatible with the GPL.

2 Likes

Isn’t exactly that what Pixar did for Renderman?

They generated a system driver that can communicate with any software, blender amongst them, it seems to be the best third party approach to the date, where the very best integration was the one from LuxCore, but it lacked some performance and speed and other small things due to limitations in Blender and the Python API.

1 Like

No, it may involve some of the same words but the meaning is entirely different. Renderman has the concept of a display driver, but it’s not like a system library or an OpenGL driver.

3 Likes

I’ve been looking a bit about the intent of the system library exception in GPL.

Clearly the reason the clause is worded like it is to make GPL programs able to coexists with proprietary systems and not just to avoid distributing libc sources with Blender. GPL FAQ even directly talks about this with: “Can I link a GPL program with a proprietary system library?”

So GPL specifically allows linking to proprietary system libraries and GPL3 even allows to distribute such libraries together with GPL software.

So what is “the intent behind the license” that is “clearly different”? It doesn’t look like a technicality to me but something fundamentally part of the license that some companies are already using to efficiently interface with their proprietary 3D graphics libraries from GPL software.

I think the intent of the system library exception is to interface with the hardware, operating system, compiler or interpreter that the application will run on. It specifically lists those things and nothing else. I don’t think a third party renderer is part of the operating system, compiler or interpreter, in a way that a graphics driver is for example.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

4 Likes

I don’t frankly see the word “hardware” specifically listed anywhere there which doesn’t of course mean it couldn’t be their intention.

What I see is a set of libraries defined by how they are (a) included “in the normal form of packaging” of an operating system, compiler or object code interpreter and (b) either implement a Standard Interface or can be only used with those three components.

libGL satisfies Standard Interface requirement (b) and OS comes with some support or dependencies for OpenGL which makes it probably satisfy (a). Whether there’s more requirements, I don’t know but I don’t see them in the text.

I don’t see any requirement for a system library implementation to be a part of the OS, compiler or interpreter. In fact, the text says it isn’t part of any of those.

So using any third party GPU based libGL is fine and using software rasterization based libGL must be fine also because Blender has the option. But using some other libGL is wrong, especially third party renderer based ones. But I’m not sure there’s any such distinctions in GPL once the library satisfies the system library condition.

If I made libGL and run workbench with it I don’t see how that possibly could be wrong or sidestepping Blender’s license any more than any other vendor’s libGL. Now whether this has some situation changing difference to applying libGL to at least uncripple my addon I don’t know yet.

Edit: I replaced: “that is designed to run workbench” to: “and run workbench with it” in the above paragraph to better convey what I was trying to say.

1 Like

About intent, I don’t think that included using the system libraries exception to interface with non-system libraries that happen to have some overlap in API, but an overall different purpose. I’m not arguing it’s wrong, I don’t have a strong opinion on the legal side of things.

It just seems like a shaky thing to rely on. And probably mostly on a technical level, because Blender use of the OpenGL API is complex and changing all the time, with Vulkan and Metal coming to replace it in the future as well.

1 Like

I’m a little confused what’s going on honestly.

  • Writing your own opengl driver is clearly allowed, it’s an open published standard
  • You may publish said driver under a license of your choosing
  • If that license is not GPL or GPL Compatible you may not ship it in the same package as your GPL addon
  • You said you had no plans to do that

case closed? there’s nothing wrong with this plan at least in the licensing department

is it technically a sound plan? probably not, but that wasn’t the question, the question was “is it allowed to do this”, not “should I do this?”

1 Like

My understanding is that the idea would not be to write a generic OpenGL driver following the standard, but rather something specifically designed to interface with Workbench/Eevee OpenGL calls. That may still risk creating a derived work, especially if you are looking at the Blender source code.

1 Like

Might I ask a related question about mixing licenses here?

Let say, for X external render engine, if the GPL plugin code is indeed clearly published on its own in GitHub server for everyone to see, could the product only consists of an installation wizard, that would download and install the GPL code in one step of the process?

Would an installation wizard fix this “shipping in the same package” issue? Because it looks like it would :thinking:

1 Like

The GPL does not us the words “shipping in the same package”, it talks in more broad terms.

Perhaps an argument could be made that the package download + installation wizard are a way to distribute a combined work incompatible with the GPL, if it was clearly designed for that purpose and is just a more complex distribution mechanism.

2 Likes

Doesn’t really matter as long as you Implement a Standard Interface for which an implementation is available to the public in source code form you’re good, there’s no stipulations that it has to be a “good” implementation. The OpenGL standard clearly qualifies as a standard Interface here.

If i were to write an opengl driver that is nothing more than stubs, literally the bare minimum that would build and load, it would quality for the system library exception. My intentions do not matter, if i wrote it cause i’m bored, or cause the world needed a better openGL driver or… just because i want to spy on what kinds of opengl calls an application does (there’s commercial packages that do just that from most major GPU vendors).

Don’t get me wrong, trying to get data in/out of blender to an addon though the OpenGL driver feels like a crazy bad idea, yet not one incompatible with our license imho.

Would an installation wizard fix this “shipping in the same package” issue? Because it looks like it would :thinking:

The GPL does not us the words “shipping in the same package”, it talks in more broad terms.

The GPL only speaks about distributing “shipping” was me paraphrasing. [personal opinion starts here, not legal advise] while the GPL does allow aggerate distributions i do not think this installer would quality for that, as it was conjured in a time where software being distributed on CD’s stuck to magazines was a thing and the aggerate or compilation sections are clearly designed to allow that if there’s a loophole in there that would allow it, it is unintended. [/personal opinion end]

With that said, I’d like this thread to return to the question asked, and not turn into yet another wild “but what if” thread.

3 Likes

It’s fine to write a driver to trace OpenGL calls. But if you trace the OpenGL calls or GLSL code of a commercial application, and use what you learn from that to write your own implementation, it may not be ok.

1 Like

Although using what you learn may not be ok, as normal copyright still applies to the glsl , model and texture information you may extract that way, the piece of software you wrote that got you that information is in the clear GPL wise.