Firstly, let me say thank you to everyone who has responded to this issue, either for or against. This issue has certainly kicked up a stir among the Linux world, primarily, I feel, because no-one has definite answers.

Secondly, I DO have the email of the person who contacted me and I understand they are a Linux kernel developer. I suppressed the name and email address because a) it wasn't relevant; and b) so they didn't get lots of flame emails - c'mon, we all know Linux people are passionate! :)

Thirdly, I did not announce this email through fear of being sued, but because I wanted to know the truth and what the options are. I want it to be clear that Kororaa, being a GPL project, must fully comply with the GPL. The question is whether including the nVidia and ATI drivers constitutes a violation and as we have all seen, it's not an easy answer. It appears everyone has their own opinion on whether this is or isn't a violation and are quick to draw conclusions. No-one has really looked at this objectively, however.

Now, onto the update.
I have been receiving lots of information which I have been sorting through, thank you to everyone who has emailed me (although I would have also thanked you personally via email). I contacted both ATI and nVidia for some clarification on particular issues, however neither have answered my questions. Nevertheless, this is what I have found so far.

Essentially, if any program takes code from a GPL work and uses that code in its own program, then it must also be licensed under the GPL. Not only this, but a non-GPL program cannot link to a GPL program / library. If the nVidia and or ATI drivers do either of these two things, then they are in violation of the GPL if they themselves are not licensed under the GPL (which they are not).

As I understand it, in short there are a few issues (once again I am not a lawyer or an expert):

1. a) Whether the nVidia / ATI drivers contain any GPL Linux kernel code
1. b) Whether any non-GPL code has been linked with GPL Linux kernel code
2. Whether I can include non-GPL components together with those under GPL

Let me explain.

Issue 1. a):
The problem with number 1 is that it is a grey area and because it has not been taken to court yet no-one actually has a legal answer. Some Linux kernel devs (including the one who emailed me the letter) believe it IS a violation because they claim it is a derived work. Apparently Linus and others do not consider it a derived work, so long as the program was not specifically written for Linux (which in the case of nVidia and ATI it apparently is not).

Linus (source http://kerneltrap.org/node/1735):

"But one gray area in particular [in regards to binary modules] is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

[...] THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

[...] These days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there..."

To quote another kernel developer:

"There _isn't_ a real answer to this until/unless it's actually tested in court. It's just unknown -- anyone doing it is taking a risk, and should consider that risk for themselves."

So issue 1.a is shaky, but apparently not certain of a violation. The important question is, I guess, whether the nVidia and ATI drivers ARE derived works or not. Some say yes, others no.

But let's look at the GPL itself (http://www.gnu.org/licenses/gpl.html).

What is a derived work?

GPLv2 section 0:

..a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it

A derivative work must contain "the Program or a portion of it". If a work does not contain "the Program or a portion of it", then it is not a derived work. Therefore IF the ATI or nVidia drivers DO contain the Linux kernel ("the Program") or a portion of it, then they must be considered a derived work. However, if they do NOT, then they are not a derived work. Sounds simple enough.

GPLv2 section 2:

"You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program"

A "work based on the Program" means a modified copy of the Program or any portion of it. Therefore if a work does not contain the Linux kernel ("the Program"), or a portion of it, then it is not a "work based on the Program", it is a separate work. Sections 2a, 2b and 2c are requirements of a "work based on the Program" and "apply to the modified work as a whole". If part 2 does not implicate the drivers in question, then sections a, b and c do not apply.


According to the kernel devs who contacted me, even if the drivers are not a derived work, they are a collective work. They claim that the driver is a collective work because it is linked to the GPL kernel on the CD. Therefore including the non-GPL binary with a GPL kernel on the same CD is a violation, because according to the GPL the binary also needs to be GPL, which it isn’t. Make sense?

GPLv2 section 2:

"Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program."

So logically, the question must be asked "are the drivers linked to the Linux kernel?".

Kernel dev:

"Now, what you're doing when you combine the binary-only modules and the kernel together into a distribution or LiveCD is _not_ "mere aggregation". That's clearly a coherent whole; a collective work and not just a bunch of stuff which happens to be sharing the same disk. [...] So while the binary-only modules _themselves_ are only 'questionable' on their own, the distribution of them _with_ a kernel is clearly a violation of the licence of the kernel."

But it is only a violation of the kernel IF the driver contain GPL code from the kernel, or if they are linked.

The whole point is whether the drivers take code from (or link to) the Linux kernel, which is licensed under the GPL. However, according to information from nVidia and from others who have contacted me, the drivers do NOT take any code from the kernel and they are also not linked to the kernel in any way. If this is the case, then they are aggregate work and not required to be licensed under the GPL.

So how do the drivers actually work?
Well the drivers are split into two sections, the source component that talks to the kernel and builds the module that you load (i.e. modprobe nvidia). According to my sources, this component is not actually linked to the kernel in anyway, but uses public interfaces to talk to the kernel. It also contains zero Linux kernel code.

The other component is the binary part of the driver. This component does not contain any Linux kernel code, is not operating system specific and is also not linked to the kernel, nor even the module component of the driver. In fact you can build the source component (the module) and load it, even without the binary component anywhere on your system. The binary portion of the driver has nothing to do with the module. The binary portion of the driver is a library that is used with a binary X driver. These libraries use functionality provided by the kernel module (through public interfaces), and are exported via device files in /dev to the system. Basically, the driver uses calls to a device file to talk to the module. The module will still load without the libraries. They will still produce files in /dev. You can still, if you write a program capable of doing so, get information from the card and even have the card perform tasks that are only available via the kernel interface.

Loading something that is not GPL does not mean the license on the loader is not GPL-compatible. Take ndiswrapper as an example. While you cannot redistribute the Windows drivers, the modules themselves are 100% GPL. What they do do, is load non-GPL components. So even a GPL package can load non-GPL code. It cannot link to it in the manner of providing actual static linking, but it can load it.

The binary portions of both the NVIDIA and ATI drivers are never linked to any part of the kernel modules. Instead, the drivers use interfaces exported by the kernel modules to emulate the kernel's DRI/DRM support. Let me give an example. Let's say that I create my Linux kernel and it has a system call, "create_page_table". My program/driver/whatever wants to create a page table in memory, so I call "create_page_table" because it is an exported interface from the kernel. This does not mean my program is linked or contains any kernel code, but simply making use of an interface exported by the kernel. It is like how connecting to a web server works, there is an interface (port 80) that is open to the public.

Using a public interface is not linking. To link, it would have to use functions within a library or binary specifically, not an externally exported interface.

The nVidia and ATI drivers do not use any of the GPL-only kernel interfaces. That is why it claims the kernel is tainted when you load them. The module does not export the GPL information, because it is not GPL, nor does it have to be. The module is not a part of the kernel. It is not built as a part of the kernel. It is not linked into the kernel. It uses the kernel's publicly exported interfaces, and exports its own interfaces, via device nodes, for a binary set of libraries and X driver to use.

If I looked at the Linux kernel source code and read about "proc" and then go and write a program that grabs information from /proc and prints it on the screen, it is not a derived work. Similarly, I can compile an application that is capable of talking to MySQL. This application could use exactly zero MySQL code. It could also use none of the MySQL libraries, provided I used standard SQL calls to talk to MySQL, either over TCP or via the socket interface. This program could be built and run on a machine with no MySQL code. The program is obviously not linked to any MySQL components.

In essence these drivers are the same. If they are not taking any code from the kernel or linking to the kernel then they are not a derived or collective work.

Number 2:
Which leads me to point number 2. The GPL does allow you to combine non-GPL components on the same CD, so long as they are "mere aggregation" (i.e. If they are NOT derived or collective works).

GPLv2 section 2:

"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."

If the drivers are derived or collective works, then they would need to also be under the GPL. However, according to the information above, the drivers are not derived works and they are not "a work based on the Program", they are not linked to any GPL code, therefore they are "mere aggregation" and do not fall under the GPL.

GPLv2 section 2:

"But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

However if the drivers are not "a work based on the Program" then they are not required to be under the GPL here either.

Having a non-GPL package like "acrobat reader" on the same CD as the GPL kernel is fine, even though they will be automatically installed into the same system as the GPL kernel (because it is NOT a derived work of the kernel, it is not linked to the kernel and it does not contain any kernel code). Naturally, if you do include derived or collective works they must also be under the GPL.

In Summary:
Well, has this made it any clearer? I'm not sure. I think we need some proof showing how these drivers violate the GPL. Anything else is really speculation.

I do wish nVidia and ATI would release their drivers entirely GPL, but I doubt this is ever going to happen. Some would argue that it never will if we allow their current non-GPL drivers to be bundled with a Linux distribution, why should they release their code? But this is really a side issue. The point is whether including the drivers does or doesn't violate the GPL. I hate the fact that I have to include non-GPL components on a GPL project, but sometimes you have to.

Mind you, there are hundreds of packages that come with a "Linux distribution" that are NOT licensed under the GPL. There are some 50+ open source licenses out there that are used with these packages and are not GPL compatible (see http://www.opensource.org/licenses/index.php). So if we can include these other packages that are not GPL, why can't we include these drivers too? (Naturally assuming there is no GPL violation.)

For people to claim that these driver do breach the GPL, one would need proof that they either take code from the Linux kernel and compile it into the resulting binary module, OR that the modules are linked to the kernel or other GPL software.

The source code for the respective module components of the drivers is available from nVidia and ATI. If anyone believes that the created modules do use code from the kernel, or link to the kernel I would be very happy receive some evidence of this.

Of course, once this is all proved in court someday we will have our answer. For me, with the information at hand, I cannot see how the drivers constitute a GPL violation. Naturally, if the drivers are a collective or derived work then they would be, and therefore cannot be distributed with the kernel, but I have yet to receive any actual evidence of this.

What does this mean for the Kororaa Xgl Live CD?
I would really like to see evidence of these drivers actually violating the GPL. At this stage everyone seems to just shout an opinion without backing it up with any evidence and it still seems a bit of an unknown.

We could just ignore it and continue distributing the drivers. Or we could, as a number of people have mentioned, let the end user install the drivers themselves (this way no-one could argue that Kororaa is violating the GPL by distributing the said drivers).

If we did not distribute the drivers, then end users would need to download the drivers from the internet and build themselves. This would mean all computers on which the livecd is run will need access to the internet. Not only this, but it will require user interaction to install the drivers (because as far as I am aware it cannot all be scripted), and I'll also need to make room for the Linux kernel source, AND make the livecd environment read write.

In short, this all seems like too much bother for a Live CD. At this stage I will not be releasing the Kororaa Xgl Live CD 0.3, but will continue to make 0.2 available.

Kororaa 2006 will not be affected, as it is not a Live CD and does not bundle the nVidia or ATI drivers.

Hope this helps people in some understanding of the issue, it has certainly helped me. If anyone sees problems in my analysis, or can provide evidence where the drivers use kernel code, please let me know.

Thanks again,
Chris Smart