I'm about to publish a GPL3 piece of software I wrote. That software uses OpenCL, and in its normal use one typically links the software against the Khronos OpenCL ICD. The ICD lets the user then select an OpenCL backend (such as Intel, AMD, Nvidia, …) at runtime and in a streamlined fashion depending on the locally available compute resources and needs. The Khronos OpenCL ICD is permissively licensed (BSD-2-clause). As is Intel's backend (MIT). However, Nvidia's backend is proprietary.

My intention is to distribute my software, and for modifications to it to be covered, under the GPL. Depending on one's view of linking and GPL, one might consider linking as modification. The license specifically allows linking to "proprietary system libraries", but specifically disallows the use of "GPL-compatible wrappers" to indirectly utilize proprietary non-system libraries. I would not want to restrict a user from distributing a version of my code that he or she intends to be used with for example Nvidia's OpenCL backend.

My instinct is that the OpenCL ICD is not "just a wrapper". It has at least one reasonably useful GPL-compatible backend. I therefore conclcude that my software really does link with just the ICD, and any further choice of backend from there on is the user's choice and not relevant for my software's licensing terms. Am I correct?

PS: While this question is relevant, I don't think it covers my situation.

  • Suppose someone takes your code, the OpenCL ICD, and Nvidia's proprietary backend, and distributes all three of them bundled into a single installation for convenience (assume for the sake of argument that Nvidia is OK with this). Do you want to prohibit that? – Kevin Dec 9 '20 at 7:32
  • @Kevin: No, I do not want to prohibit that. I would, in fact, very much like to allow it, but preferably without having to add an explicit, and probably poorly phrased, GPL-section-7 exception (this out of fear of crayon license proliferation, cf. your highly upvoted answer on that topic). – gspr Dec 9 '20 at 14:34
  • 1
    Why do you want to use the GPL instead of the LGPL? What, specifically, does the LGPL permit that you want to prohibit? – Kevin Dec 9 '20 at 17:37
  • @Kevin: I never thought of it like that. I always thought that placing software X under the LGPL instead of the GPL eases the restrictions on other software Y that for example link with X. I never thought about how it pertains to people linking X to other software Y (the reverse relationship). We may be digressing a bit here, but would you have time to elaborate? – gspr Dec 9 '20 at 17:58

Whenever anything shares address space with a GPL'd component, whether it was linked statically or dynamically, the whole binary falls under the GPL unless there's a specific exception for it (such as the system library exception, or the Linux kernel's syscall clarification), and you have to provide GPL'd source for everything whenever you distribute those binaries. This is clearly stated in section 1 of the GPL:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

(Emphasis added.)

So if someone makes a binary which dynamically (or statically) links to the Nvidia backend, that backend is subject to GPL requirements, including source code and GPL licensing. Since the Nvidia backend is proprietary, it will not be possible to comply with those requirements, and consequently the binary cannot be distributed at all.

The easiest way around this is to use a different license. There are at least two good options:

  • The Lesser General Public License, which is largely identical to the GPL, but may permit this sort of linking depending on how your program is structured. For example, the LGPL might not permit linking to libraries which you call into. However, if the external library calls into your code, even just from a slim wrapper main() function, then this would probably be acceptable (as it would "make use of an interface provided by the Library, but [not be] otherwise based on the Library"). Any other code which the external library links to could then be considered an extension of "the Application."
  • The Mozilla Public License, which is similar to the LGPL, but explicitly operates at the level of files rather than programs. Some users may find this clearer to reason about, and it does not suffer from the complexities of the LGPL.

A third, less preferable option, is to use the exception mechanism in section 7 of the GPL to permit linking with proprietary backends and only proprietary backends. These exceptions are difficult to write well and can create legal uncertainty, so I would only recommend that as a last resort. The main advantage of this approach is that you get to specify the exact set of linking you want to allow, whereas LGPL and MPL permit essentially unlimited linking (albeit the former may require minor program restructuring).

  • The LGPL does not allow unlimited linking. The license is written in such a way that authors of proprietary code can link an LGPL library into their codebase, but the authors of the LGPL code can not link LGPL-incompatible code into their project. – Bart van Ingen Schenau Dec 10 '20 at 10:28
  • @BartvanIngenSchenau: I have read through the entire LGPLv3 and cannot find the specific line you are talking about. – Kevin Dec 10 '20 at 17:39
  • Take a good look at how the terms "Library", "Application" and "Combined Work" are defined in the LGPL. In particular, note how a library used by the LGPL code does not fit in the definition of Application. – Bart van Ingen Schenau Dec 11 '20 at 6:52
  • @BartvanIngenSchenau: I've clarified this, but I tend to imagine this is absurdly easy to work around if absolutely necessary, for the reasons I've explained in the answer. – Kevin Dec 11 '20 at 8:35

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.