The proper use of EXPORT_SYMBOL

By Jonathan Corbet
October 27, 2018

The kernel, in theory, puts strict limits on which functions and data structures are available to loadable kernel modules; only those that have been explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare a GPL-compatible license will be able to see the symbol. There have been questions about when EXPORT_SYMBOL_GPL() should be used for almost as long as it has existed. The latest attempt to answer those questions was a session run by Greg Kroah-Hartman at the 2018 Kernel Maintainers Summit; that session offered little in the way of general guidance, but it did address one specific case.

The kernel has had EXPORT_SYMBOL_GPL() for fifteen years now, Kroah-Hartman said; its use is not mandatory. It is generally meant to apply to core functions that cannot be used without the user being a derived work of the kernel. But whether that is the case for specific functions is not always obvious.

Andrew Morton was quick to raise the case that has been concerning him, relating to symbols exported for the heterogeneous memory management (HMM) subsystem. In particular, it makes some low-level memory-management functionality available to all modules, rather than just those with a GPL-compatible license. This export, Morton said, is "a big gift to NVIDIA", which needs it to use the HMM functionality in its closed-source modules. This export has upset a number of people including Dan Williams, who has been posting patches to change that export to EXPORT_SYMBOL_GPL().

Morton said that he didn't really want to get into the politics of the situation, but he needed to decide whether to apply Williams's patches, and that means deciding whether a GPL-only export would be more appropriate in this case. Christoph Hellwig was quick to argue that any users of the functionality in question can only be a derived work of the kernel. Linus Torvalds said that the initial point was to let hardware with its own memory-management unit handle its own page-table management, but that is not how the usage has actually turned out.

Hellwig said that there is other NVIDIA-specific code in the kernel that should probably be removed as well; support for NVLink was mentioned in particular. Arnd Bergmann said that there is a smaller pile of patents around AI applications (where NVLink is generally used) than around graphics, so there might be a better chance of getting that code opened eventually. Graphics drivers remain a problem, though.

Returning to the HMM issue, Morton summarized the feeling in the room as being in favor of merging Williams's patches. So, he said as the session (and the summit as a whole) came to a close, that is what he will do.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to the Maintainers Summit.]

Index entries for this article
Kernel	Copyright issues
Kernel	EXPORT_SYMBOL_GPL
Kernel	Memory management/Heterogeneous memory management
Conference	Kernel Maintainers Summit/2018

The proper use of EXPORT_SYMBOL_GPL()

Posted Oct 27, 2018 19:40 UTC (Sat) by mb (subscriber, #50428) [Link] (1 responses)

> Greg Kroah-Hartman at the 2081 Maintainers Summit

Damn it! Time goes by!

The proper use of EXPORT_SYMBOL_GPL()

Posted Nov 1, 2018 19:04 UTC (Thu) by mina86 (guest, #68442) [Link]

Oh my! Cyberpunk 2077 has been out for four years and I haven’t noticed!

Definition of derived work

Posted Feb 20, 2019 14:14 UTC (Wed) by benbu (guest, #130526) [Link] (3 responses)

(I am not a lawyer, and this is not legal advise, just common sense.)

A derived work is based on the base work. A clear and generally accepted indication that something is not a derived work is when the work can exist without the base work, or even clearer, if the work was created independently of the base work and is now only being integrated with the base work. If that is the case, then it's clearly not a derived work, but independent.

For example, a program originally created for BSD Unix is now being ported to Linux. (In addition to, and in line with, the special OS exception in GPL 2.0 clause 3,) that program is clearly not a derived work of Linux.

This reasoning does not apply to most device drivers, because they were written specifically for that kernel and typically even as part of the kernel. Most device drivers cannot exist independently of the OS they were written for, but inherently and deeply depend on it. Thus, it can be said that they are derived works.

The NVIDIA graphics driver was originally developed for Windows. It clearly existed and worked independent of its Linux adaption. From what I understand, large parts of the NVIDIA driver source code are shared between Windows, Linux and Mac. In fact, from what I read, the nVidia team made great efforts to keep as much code of the driver as possible generic and operating system independent.

Any code that depends on the OS and the API functions of the OS is therefore strictly necessary for its operation and optimal performance in terms of features and speed.

For me, that means that the nvidia driver is not a derivative work of the Linux kernel, for the same reason that a BSD Unix application is not a derivate of the Linux kernel. The technical details, that certain interfaces in Linux had to be created specifically to support the nvidia kernel, do not negate this fundamental situation from a legal point of view. That's similar to Linux adding e.g. new crypto interfaces in order to be able to run an already existing BSD application. Even if the BSD app needs additional APIs, the BSD app still existed and worked independent of Linux, just like the NVIDIA driver worked on Windows before it was integrated into Linux, and in fact it made efforts to use as little of the Linux kernel as technically reasonable, and therefore it cannot possibly be a derived work of Linux.

The phrase "any users of the functionality in question can only be a derived work of the kernel" is therefore false on face value.

Something that existed independently of the Linux kernel with the same feature on another OS and was merely ported from another OS to Linux can never be a derived work of the Linux kernel.

Ben

Definition of derived work

Posted Feb 21, 2019 2:39 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

Well, it wasn't when it was first ported. But they can grow towards each other over time and the changes in the driver ending up being derivative. For example, if Linux adds some fancy new API that didn't exist before and then the driver ends up using it, it's hard to argue that the bits *using that API* are not derivative. Those bits may be in the core of the driver. The GPL has some things to say about that.

Also not a lawyer. :)

Definition of derived work

Posted Feb 21, 2019 20:40 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

Continuing the non-lawyer trend, but to me it seems ridiculous that we're even having this discussion. Based on the way "derivative work" is used in every domain other than software, the idea that one piece of source code is "derivative" of another just because it calls or otherwise links with interfaces exposed by the other piece is ludicrous. Copyright covers creative expression, not functionality. The creative elements of a piece of source code are not in any sense a copy, translation, or other transformation of the creative elements of whatever other software the source code refers to, or that the compiled object code may eventually be linked with.

The idea that mere linking make the source code a derivative work is akin to saying that any research paper is a derivative work of every piece of source material listed in its bibliography.

A *binary* distribution is a different matter, since it actually incorporates elements from all the different sources which are linked together. That wouldn't include any shared libraries, but it might include code in header files (e.g. macros or inline functions).

Definition of derived work

Posted Sep 1, 2021 8:43 UTC (Wed) by R0b0t1 (guest, #151886) [Link]

Or maybe the NVIDIA driver derived all OSes. It can't exist in its current form without all three.