The proper use of EXPORT_SYMBOL_GPL()
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 |
Posted Oct 27, 2018 14:46 UTC (Sat)
by ken (subscriber, #625)
[Link]
I saw some really weird code around that in some DSL driver and did not understand why until I saw it was exported as GPL.
Posted Oct 27, 2018 19:40 UTC (Sat)
by mb (subscriber, #50428)
[Link] (1 responses)
Damn it! Time goes by!
Posted Nov 1, 2018 19:04 UTC (Thu)
by mina86 (guest, #68442)
[Link]
Posted Feb 20, 2019 14:14 UTC (Wed)
by benbu (guest, #130526)
[Link] (3 responses)
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
Posted Feb 21, 2019 2:39 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Also not a lawyer. :)
Posted Feb 21, 2019 20:40 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
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).
Posted Sep 1, 2021 8:43 UTC (Wed)
by R0b0t1 (guest, #151886)
[Link]
The proper use of EXPORT_SYMBOL_GPL()
The proper use of EXPORT_SYMBOL_GPL()
The proper use of EXPORT_SYMBOL_GPL()
(I am not a lawyer, and this is not legal advise, just common sense.)
Definition of derived work
Definition of derived work
Definition of derived work
Definition of derived work