Linked by Thom Holwerda on Tue 1st Aug 2006 17:50 UTC, submitted by Moulinneuf
Novell and Ximian In a change of heart, Novell has ceased distributing proprietary software modules such as 3D video drivers that plug into the Linux kernel. The change came with Novell's Suse Linux Enterprise Server 10, released in July. With the move, Novell is aligning itself with the Free Software Foundation, which shuns proprietary software in general but in particular loathes proprietary modules that run as a component of the open-source Linux kernel.
Thread beginning with comment 148332
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: LGPL
by G. W. on Wed 2nd Aug 2006 03:23 UTC in reply to "RE[4]: LGPL"
G. W.
Member since:
2006-03-17

Please let's try to keep the confusion at a minimum.

> In nVidia's case specifically, the binary "blob" is
> OS-agnostic, they use the same binary for Win and
> BSD.

NVidia's blob is not a kernel module, it is an object file which cannot be loaded into the kernel. It is technically impossible to load this blob into the kernel.

This object file is totally useless to a consumer, the consumer needs a kernel module. kernel module = blob + source wrapper. The kernel module can then be loaded into the kernel.

What you are currently trying to do is saying, the blob is not a kernel module and therefore not a derived work of the kernel.

The interesting point here is that you are right, but the even more interesting point is that it doesn't matter. What Novell would have to do in order to provide a usable driver is distributing the kernel module, not just the object file, and in the moment when you link the blob and the source wrapper together, it becomes a derived work of Linux.

There is no way out: Distributing Non-GPL kernel modules is in violation of the GPL. We can discuss workarounds like source wrappers and such until the end of our lives, it does not make any difference.

Read:

"Some companies try to skirt the license of the law on how they redistribute their closed source code, forcing the end user of it to do the building and linking, which then causes them to violate the GPL if they want to give that prebuilt module to anyone else. These companies are just plain unethical and wrong."

Quoted from http://www.kroah.com/log/linux/ols_2006_keynote.html

It's exactly that: NVidia's source wrapper approach is just a cheap attempt to pass all the legal problems to the users. Well, OK: If users like it that way, they can always compile and link the proprietary modules themselves, which is legal as long as they don't distribute it, but this scenario is something that a company can definetely not support commercially, it simply doesn't scale. I don't know any Linux distributor that provides commercial support for custom kernel modules.

The only long-term viable solution is: These drivers must be implemented in user space. Once that happens, all the legal problems are resolved and there would be nice side effects: User space drivers can't crash the kernel and the kernel <-> user space interfaces are stable.

Reply Parent Score: 3

RE[6]: LGPL
by mkone on Wed 2nd Aug 2006 07:18 in reply to "RE[5]: LGPL"
mkone Member since:
2006-03-14

"Some companies try to skirt the license of the law on how they redistribute their closed source code, forcing the end user of it to do the building and linking, which then causes them to violate the GPL if they want to give that prebuilt module to anyone else. These companies are just plain unethical and wrong."

Quoted from http://www.kroah.com/log/linux/ols_2006_keynote.html

It's exactly that: NVidia's source wrapper approach is just a cheap attempt to pass all the legal problems to the users. Well, OK: If users like it that way, they can always compile and link the proprietary modules themselves, which is legal as long as they don't distribute it, but this scenario is something that a company can definetely not support commercially, it simply doesn't scale. I don't know any Linux distributor that provides commercial support for custom kernel modules.


As far as I understand, companies can't make end users violate the GPL because GPL affects distribution. As long as one is not distributing, one cannot violate the GPL. So end users are not distributing (by assumption), so they do not violate the GPL. If the end user distributes, then they become a distributor and the rules apply. But then again, I do not see the FSF going after those people, but I have been wrong before.

So it is actually an effective of skirting around the GPL and keeping to the letter of the law. Personally, I do not see the problems with NVidia's approach.

Reply Parent Score: 1

RE[6]: LGPL
by grat on Wed 2nd Aug 2006 15:50 in reply to "RE[5]: LGPL"
grat Member since:
2006-02-02

The only long-term viable solution is: These drivers must be implemented in user space. Once that happens, all the legal problems are resolved and there would be nice side effects: User space drivers can't crash the kernel and the kernel <-> user space interfaces are stable.

Ok, I'll bite. From your comments, you're involved high up enough that you should have a fair idea of what it would take, so I ask...

What would it take in terms of coding, from both the linux community, and the hardware vendors, to make this happen?

Seriously. What would it take (preferably in layman's terms-- I have years of experience as a programmer, but have virtually ignored OS kernel code because it's not that important to my job), to implement a methodolgy for high performance, user-space drivers? Preferably ones that don't have to be rewritten each time the kernel updates.

Ideally, I'm picturing some form of kernel module that acts as an interface for user space drivers. That module could have a stable "external" API, and be adapted to "internal" API changes.

I have no idea what the performance tradeoffs would be, or if it's even a viable concept, but the driver/GPL issues are getting more and more press, and should soon start showing up in anti-linux FUD.

Reply Parent Score: 1

RE[7]: LGPL
by Legend on Wed 2nd Aug 2006 16:18 in reply to "RE[6]: LGPL"
Legend Member since:
2006-07-27

Interestingly enough, what he means is basically a http://en.wikipedia.org/wiki/Microkernel !

Reply Parent Score: 1

RE[7]: LGPL
by draethus on Thu 3rd Aug 2006 12:27 in reply to "RE[6]: LGPL"
draethus Member since:
2006-08-02

Seriously. What would it take (preferably in layman's terms-- I have years of experience as a programmer, but have virtually ignored OS kernel code because it's not that important to my job), to implement a methodolgy for high performance, user-space drivers? Preferably ones that don't have to be rewritten each time the kernel updates.

libusb already lets you send and receive control, bulk and interrupt USB packets from user space, by using the kernel's /proc/bus/usb interface. It doesn't do isochronous packets, which are real-time packets with no error checking - but those are only needed for real-time hardware, like audio and video, and should be relatively easy to add anyway. It is already entirely feasible to write a closed-source user-space scanner or printer driver with libusb - the SANE project takes this approach for scanners. libusb is fast too.

There was/is a kernel module called pcidev (anyone know more?) that lets a user-space program access PCI hardware - not sure how well it works or how efficient it is (interrupt latency must be pretty long, if you write interrupt handlers in user-space), but it's definitely possible.

The thing is, a lot of the time, to do anything useful you need to interact with the kernel. A user-space TV card driver still needs to interact with video4linux, which is in the kernel. A user-space RAID array driver still needs to interact with the kernel block device infrastructure. But, some of the time you could cheat by using a kernel-to-user-space proxy - something like fusd - though that's pretty slow.

None of this is technically infeasible or very complicated - but you need to convince people to do it...

Reply Parent Score: 1