The second part of the interview with James from Linux Australia is available for anyone interested.

Episode 24:
("Chris Smart from the Kororaa project about his adventures in the land of GPL; Noven from South Australia about how he uses FOSS to help remote indigenous communities; and Rusty Russell, IP Policy Advisor for Linux Australia, about the new petition Linux Australia has launched calling on the federal government to "Ban Piracy, Not Competition")
OGG;
MP3.

Enjoy!
Chris

No-one is probably interested in this anymore, however if anyone out there is curious (like me) then here's an update!

I received a reply from the Free Software Foundation in regards to the GPL issue.

However because I have not heard back since my reply, I thought I may as well post my reply back to FSF so you can read both. It will be hard to read, but the lines with ">" are the original FSF email (bolded), and the other text is my reply to them (italicised).

In essence, FSF believes that the drivers ARE a violation but that there are special considerations for Linux. Once again, no actual evidence was provided, so I replied asking for some :)

I have also emailed the original kernel developer who contacted me to ask him primarily for two things:
1) Evidence to support his claim
2) What part of the kernel is under his copyright that it is violating

I have not heard back yet, but hope to soon.

Here's the FSF email:

> Dear Chris,
Hi [name taken out],
Thank you very much for taking the time to get back to me.

I have some questions below I am hoping you, or someone, can answer for me so that I can get some clearer understanding as to why they are a violation.

> I'm very glad to see that you're taking licensing issues seriously, and
> I understand your frustration at getting clear answers in this regard.
> It's unfortunate that legal housekeeping can do so much to hinder good
> development work.
It sure can :) But I do want to make sure that I am doing the right thing.

> Let me address some of your concerns as they regard the GNU GPL
> generally. Later, I'll discuss some complications that are specific to
> Linux -- I'm afraid they make it impossible to provide you with a
> definitive answer to your questions.
OK

> We believe that kernel modules are derivative works of Linux.
Can you explain WHY you believe the kernel modules are derivative works of Linux? What actually makes them a derivative work?

>If there
> weren't any special licensing considerations for Linux, we would say
> that those modules must adhere to the requirements set forth in the GPL.
So is this due to your understanding that they ARE derivative works, and therefore also have to be GPL? I would certainly agree that if they ARE derivative works then they need to be under the GPL too.

> In particular, this means that they, too, would be licensed under the
> GPL, and users would be able to obtain source when the work is
> distributed in binary form. In such a case, if there were binary-only
> modules, we would say they were violating Linux's license, along with
> anybody who was distributing them.
Would you be able explain why a binary-only module violates the license? Or is this assuming that the binary modules are a derivative work (and therefore linked to the question above?).

> Unfortunately, there are special considerations for Linux that muddy the
> waters. Linus Torvalds has made statements which suggest that, for
> whatever reason, he does not believe that modules which use certain
> kernel interfaces are subject to the GPL's requirements.
I believe this is because the drivers were not specifically written for Linux, and make no Linux specific calls (http://kerneltrap.org/node/1735).

> Some kernel
> developers apparently agree with him. Others do not: I was at OSCon
> last year, and I saw Greg Kroah-Hartman give a quick presentation about
> kernel development where he flatly stated that binary modules are
> illegal.
Is this presentation available? I'd love to understand why he says the binary modules are illegal. Everyone has a point of view, but I want to know the reasons why, and am after actual evidence.

>It's not clear whether or not Linus' relaxed restrictions are
> meant to apply to the entire Linux kernel, or just his contributions to
> it.
I would assume that he cannot speak for the copyright of code owned by other developers. But perhaps he does have some sort of overriding power because "Linux" is his trademark, I don't know. Even if he disagrees on behalf of "Linux" I think that individual developers have the right to enforce their own copyright. Of course it would have to be a part against which the violation is occurring. Surely iptables cannot lay claim to a violation from a video driver if it has nothing to do with his code?

>Many people would like clarification in this area, but the
kernel
> developers seem intent on leaving things fuzzy for now. It generally
> seems like they're moving towards prohibiting binary modules, however.
Whether they want to prohibit binary modules or not is up to them I guess, I'm merely interested in a GPL violation. If it's a binary module or not, I'm just interested in HOW the module violates the license.

> As we discuss at
> <http://www.gnu.org/licenses/gpl-faq.html#WhoHasThePower>, when a
> program is GPLed, one who its copyright holder is the can enforce the
> license. This means that if the copyright holder wants to provide
> exceptions to the GPL's terms, they can do that, and it can be legally
> binding. So statements like Linus' have the potential to provide
> developers with permissions they may not have had otherwise.
Thanks for that information. I guess it comes down to how much authority Linus himself has over the entire kernel. If the modules violate the GPL using a part of HIS code, and he has excused it, then I guess that's ok. Strange.

> It also means that for a program with many copyright holders, like
> Linux, it's at least conceivable that any single one of them could hold
> you accountable for license violations, and that they may not intend for
> their work to have exceptions in the GPL's requirements, like Linus
> apparently does.
Surely they can only lay claim to a violation if it is against their code? But I guess it needs some clarification on the copyright of Linux as a whole, and whether one single piece of code entitles that author to have copyright on the entire Linux code. If that is the case, there is bound to be lots of conflicts. If it comes down to whoever has the copyright on a particular piece of code, that might be easier. Who would know the answer to such an issue?

> As such, the kernel developer who wrote to you may be
> within his rights to request that you stop distributing a kernel that
> uses binary modules. It's undeniable that the safest course of action
> for you, as far as license compliance is concerned, is to avoid using
> kernel modules that don't comply with the terms of the plain GPL.
But this is exactly the problem. I need to know whether they indeed DO or DON'T comply. Someone's word that they do cannot hold, there must be evidence. So how do I know that they don't comply with the terms of the plain GPL?

> If
> you can get all the kernel developers to say that you're allowed to
> distribute the work with binary modules, then you're in the clear, but I
> don't think you'll get that.
Sure :) and I'm not even interested. If it is a violation then I won't release another, and I won't seek permission, and I won't try and find a way around it.

> I cannot explain why this developer has not gone after other
> distributors that include binary modules, or after ATI and nVidia
> directly. You would have to ask him yourself. However, legally
> speaking, he is allowed to be as selective as he likes in his copyright
> enforcement, even if it seems like he's choosing poor targets. Perhaps
> he's trying to establish precedent to get the attention of larger
> organizations.
Yes, this is true. No questions he has the right to lay claim to a violation if he is indeed a copyright holder of the Linux kernel. His motives, I'm not quite sure, but I have appreciated him letting me know.

> I hope this at least explains the situation coherently for you, even if
> it doesn't provide any easy answers. Of course, if you still have
> questions or other concerns, don't hesitate to contact me. Please note
> that this is not legal advice. If you need legal advice, please consult
> a lawyer.
Sure, I understand that is it not legal advice. I would appreciate some information / explanation as to WHY the drivers violate the GPL. At this stage everyone seems to have an opinion, but no real evidence. If I can get that, then I can understand and see why it does violate the GPL. Until such a time it is hearsay.

Looking forward to receiving some more information. Thank you very much for your time!

Kind regards,
Chris Smart

I have been interviewed for Linux Australia Podcast (episode 23) in regards to the GPL violation issue.

Which made me realise that I forgot to mention that I was also interviewed for the Linux Australia Podcast episode 22, for the Kororaa project in general. The episode 22 interview was done almost 2 months ago (long before the GPL issues), but published much later on the 13th May.

If you would like to listen to the podcasts they are available here:
Episode 22:
(Kororaa Project and Donna Benjamin from Melbourne about the Melbourne bid for LCA 2008)
OGG;
MP3.

Episode 23:
(Matt Ebb, a lead artist on the recently released Open Source short film "Elephants Dream" and Kororaa GPL issue)
OGG;
MP3.

Enjoy!
Chris

Just a little update to say that on Tuesday 23rd May I contacted the Free Software Foundation asking for their official stance on this issue.

So far I haven't heard anything except the ticket number allocated to the request, but I will provide an update as soon as I hear from them.

Chris

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