1

Basic Information

I am writing a Blender add-on which enables the use of Blender with a piece of hardware (i.e., a lightfield display). Blender and the use of the specific Python API, which is required to write Blender add-ons, is licensed under GPL. In order to communicate with the lightfield display on the software level the manufacturer of the display provides a compiled, closed-source DLL under a non-GPL license. The add-on cannot provide the main functionality without this DLL.

No piece of third-party software can be written for this 3D display without this DLL. Since this DLL and the API calls it provides are fundamental to communicate with the display in general, me (and the manufacturer as well) consider this DLL to fall under the "system library exception" of GPL v3.

Issues / Questions

Assuming the copyright-owner of the closed-source DLL would grant me the right to distribute the DLL in its compiled form (.dll, .dylib, .so, etc.), while the DLL remains closed-source, non-GPL:

Is it GPL compliant to distribute this DLL within the add-on package or would GPL force me to let the user install this library? This question can be generalized to more general terms:

Is it GPL compliant to distribute any non-GPL, closed-source linked library, which falls under the system library exception, with GPL code?

My understanding

While I would interpret GPL, that this is allowed, since I couldn't find any clause that prohibits distributing a system library in the GPL license, I couldn't find a reliable definite answer to this. I would appreciate if someone could answer my question and cite the corresponding text passage in GPL or any other official statement, from which the answer to my question can be clearly derived. Thanks!

Edit: There is also a passage in the GPL FAQs, which I would interpret in favor of my understanding, but I am not totally sure if I read it correctly. So any comments on this are welcome:

If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them. Source: https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

Could someone confirm that this FAQ statement means that system libraries may be distributed with GPL code? And does this also count for non-compiled executables like Blender add-ons which are always distributed as python source code?

4

I agree with JNic above. I note your edit regarding the distribution of binaries linked to System Libraries, but I think you are misunderstanding this exception.

The FAQ entry you quote makes it clear that if a library is a System Library, then the mere choice to distribute a copy of said Library along with your work doesn't prevent you from availing yourself of the System Library exception. It does not, however, exempt you from the other tests of whether something is a System Library.

GPLv3 holds that

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 ...

The DLL is clearly essential to the use of this particular 3D display. Does that make it a System Library? I would hold not, because the display is not an "essential component" of this operating system. You can easily buy a computer running the OS in question without this display, and the DLL in question is not then required to make it work.

I'm sure it pleases the manufacturer of this display to regard their DLL as a System Library, for this lets them continue to distribute hardware which requires proprietary drivers without suffering one of the normal penalties, namely free software not working properly (or at all) with their hardware. I am therefore not persuaded by their stance; if they're really so keen to be interoperable, let them free up their drivers.

I read the GPL as I think JNic does: since your work is required by the Blender licence to be under GPLv3, you may not distribute this DLL with your work.

10
  • Thanks for your detailed answer. Do I understand you correctly that - in general - drivers or driver-like API can never be regarded as system libraries? Does that also mean that I may not distribute this add-on at all, even if the user would install the driver separately?
    – reg.cs
    Jan 10 at 13:15
  • @reg.cs I'm not saying never, because there are exceptions to almost any rule. But closed-source driver code for non-standard hardware, that has to be installed independently of the OS? To me, no, none of that can be so regarded. As for distribution, I think you're fine to distribute your code, but the user will have to source and install the closed-source blob him/herself.
    – MadHatter
    Jan 10 at 13:23
  • That would be sad, if such drivers could never fall under this exceptions. But is it really dependent on whether it is delivered by the OS? If I remember correctly software components like compilers (even closed-source ones) fall under the system-library exception. Why would drivers not? Anyway, I will do some research in that direction. Something that is less understandable by me is, why letting the user install the library would be okay? If it doesn't fall under the system library exception, GPL demands providing source code for any software component linking to the GPL code, doesn't it?
    – reg.cs
    Jan 10 at 13:55
  • GPL requires that you provide complete corresponding source alongside any binary you provide, and that this source be conveyed under GPL. If you don't convey the driver, you're not obliged to provide its source.
    – MadHatter
    Jan 10 at 15:19
  • Then I would at least be able to convey the Blender plugin. However, I still don't see this in the license text. I also looked at the FAQ again, and there it is stated that: "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." From that I would understand that the mere linking to non-GPL library would prevent me from conveying my GPL-covered work. Doesn't it?
    – reg.cs
    Jan 10 at 16:07
2

Is it GPL compliant to distribute any non-GPL, closed-source linked library, which falls under the system library exception, with GPL code?

A library distributed with the program does not fall under the system library exception.

3
  • Sorry, I was a bit slow. I was editing my answer while you wrote because I was afraid the answer you gave would come up. The quoted FAQ statement (see my initial post edit) contradicts your answer, doesn't it?
    – reg.cs
    Jan 10 at 0:11
  • Sorry. I think it's OK.
    – JNic
    Jan 10 at 0:12
  • Thanks for your answer. I will still leave this question open for now to wait for other opinions and to see if someone can give a definite answer.
    – reg.cs
    Jan 10 at 0:17
0

To give another angle on the issue: If you need to distribute the DLL together with your Blender plugin, then the DLL can not be regarded as a System Library.

The point of a System Library is that it is such an important part of the target system that it is distributed together with that system and you must be able to assume that the library/driver is present on any system that supports the hardware in question.

And even then, there might be arguments that the DLL is still not covered by the System Library definition of the GPL.

10
  • That was essentially my and the manufacturers viewpoint, I would say. Its an essential component for using this display with any OS. Your second argument is not a contradiction to that, though: The library is a developer tool and any software developer can obtain it for free and include it into its software to make the software work with the display on the specific OS. It's the GPL that prevents me from doing it for the Blender add-on. I know the resolution would be easy for the manufacturer: he could simply install it on the any users system. But that's another point.
    – reg.cs
    Jan 11 at 16:06
  • You seem to be arguing that any code which is essential to making any system peripheral work (ie, any closed device driver for which no open equivalent exists, for a start) can avail itself of System Library status. I don't think this is true, and I think it is a dangerous argument to make, as it enables makers of devices with closed-source drivers to distribute GPL software linked to those drivers without having to open the drivers up.
    – MadHatter
    Jan 11 at 16:39
  • @MadHatter, my argument is actually the other way around: If you can't assume that the driver will be present on a system that uses the hardware, then the driver is definitely not a System Library. Jan 12 at 6:26
  • Which is all very well, except that the OP posts a GNU FAQ entry that explicitly contradicts that. Standardised presence is clearly not the relevant test for System Library status.
    – MadHatter
    Jan 12 at 7:45
  • @MadHatter, That FAQ entry talks about executables containing a library. Would you argue that an executable that dynamically links to a library contains that library? If not, then the FAQ entry is irrelevant for this situation. Jan 12 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.