LWN: Comments on "The proper use of EXPORT_SYMBOL_GPL()"

Definition of derived work

R0b0t1 — Wed, 01 Sep 2021 08:43:25 +0000

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

Definition of derived work

nybble41 — Thu, 21 Feb 2019 20:40:43 +0000

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

mathstuf — Thu, 21 Feb 2019 02:39:43 +0000

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

benbu — Wed, 20 Feb 2019 14:14:03 +0000

(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

The proper use of EXPORT_SYMBOL_GPL()

mina86 — Thu, 01 Nov 2018 19:04:13 +0000

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

The proper use of EXPORT_SYMBOL_GPL()

mb — Sat, 27 Oct 2018 19:40:05 +0000

> Greg Kroah-Hartman at the 2081 Maintainers Summit

Damn it! Time goes by!

The proper use of EXPORT_SYMBOL_GPL()

ken — Sat, 27 Oct 2018 14:46:48 +0000

EXPORT_SYMBOL_GPL(sched_setscheduler) is a bit strange as its set to GPL but at the same time its a syscall.

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.