Steam Machines Prototypes: Intel CPU, NVIDIA GPU

[johnc]

Android driver stacks normally have an open source kernel driver.

Aren't just about all the drivers closed-source blobs? Touchscreen drivers, wi-fi drivers, camera drivers, GPU drivers... ? All closed?

[bridgman]

Aren't just about all the drivers closed-source blobs? Touchscreen drivers, wi-fi drivers, camera drivers, GPU drivers... ? All closed?

The most common approach seems to be using a small-as-possible kernel driver in source code form with everything else done in userspace (and closed source), although now that Intel is using GPUs derived from their PC graphics in small-footprint parts you might see relatively more open source drivers appearing.

[Bathroom Humor]

VALVE WON'T BE MAKING THEM

Yea they will. They even have a webpage saying they are. Look for the steam machine announcement.
Even before this point, they have talked about how they are making their own version, probably targeted in the price range of console users. OEMS can make their own steam machines, but that doesn't stop Valve from doing so.

Titan? GTX-780? Nvidia is considered the poor company by linux community due to its drivers and attitude, and Valve choose Nvidia for linux box?

We're talking about their non-free graphics drivers. This is exactly why Valve is choosing that hardware for their reference boxes. Nvidia makes the highest quality non-free GPU driver available for Linux. If AMD were a better choice, they would have used their GPU's instead but good drivers go a LONG way toward making games play better. Everyone would love to see them step up the Linux driver game though.

[jsa1983]

Hey, Mr. Corpus,

do some smart stuff - kill fglrx already and overclock the opensource driver development. IF you trust your own understanding of "open ecosystem". Because in closed source, there will be no agnosticism, ever. You know how maximum profits a.k.a. cartels work, right?

Hahaha... I think they need adding extra cores to their opensource team, not "overclocking" Alex, Michel, Marek,... Im sure those guys are quite busy

[juanrga]

We're talking about their non-free graphics drivers.

I also was talking about them. Linus criticism was because Nvidia refuses to answer kernel developers questions.

[pingufunkybeat]

Sigh, it would be nice if you would at least attempt to read through the GPL and understand the basics of how the kernel operates before you decide to regurgitate the same old nonsense about them. There is nothing in the GPL that prevents GPL'd programs from being distributed along side closed source programs. The GPL says that closed source programs can't link to GPL'd shared libraries, it says nothing at all about loading a closed source binary module at run-time into a GPL'd program. Binary blobs are basically self-contained plug-ins and neither they nor the kernel do any linking, dynamic or static, against each other and are therefore not within the scope of the GPL.

You are very much missing the point. The GPL does not mention linking at all, it mentions "derivative works" and there is discussion about what makes something a derivative work.

It is possible to distribute GPL and proprietary software together, true. As long as the proprietary software is not a derivative work of the GPL software and you distribute a combination of the two, in which case you are breaking the GPL.

The question is whether binary drivers like Nvidia's actually break the GPL. You are right, there is the GPL-shim workaround, but many kernel hackers question it's legality and claim that the Nvidia binary driver is in fact a derivative work of the kernel, because it cannot function without it. It's not a black-and-white thing, it's very much a grey zone and there is no consensus. The assertion that a Linux kernel module which does not function in any way without a working GPL-ed Linux kernel is not "derivative work" is somewhat questionable in the eyes of many.

So what happens is that distributions do not distribute the blob (risking a GPL lawsuit), but let their users download it and install it themselves. If a user downloads and combines GPL and non-GPL software on their own, there is no violation.

[brosis]

You are very much missing the point. ..

Nvidia driver is clearly not derivate work. Being derivate means taking something and expanding it. Nvidia driver on the contrary is a bridge between nvidia GPU and $kernel. Could be any $kernel. The driver without GPU is nothing. This also distinguishes DRI, Gallium and nvidia, and puts some specific light on the latter. For the bridge to work, it needs some open interfaces. GPL does not want those interfaces start acting like octopus tentacles, sucking many parts of free code into blob - thats about it. Whether one use/ship nvidia or not, is not questioned. That aspect and backdoor/dependence/trap one, ofc. The problem is - modern programming profits from intensive interoperability very much, but management wants to sell it as proprietary parts instead. The day nvidia realizes its position on the proprietary is its own major income hinderer, it will be a big leap forward.

So what happens is that distributions do not distribute the blob (risking a GPL lawsuit), but let their users download it and install it themselves. If a user downloads and combines GPL and non-GPL software on their own, there is no violation.

Thats never going to happen. FSF is not *evil* organisation, but strictly on side of users. Distributions makers, doing this are also not risking anything from side of FSF. The only one risking would be nvidia or its daughter company, if they take kernel, put it inside or glue it hard with their proprietary creme and then release it as stand alone application, ie not a driver (which has plug-in feature, is not critical and acts as a support bridge with their hardware).

[pingufunkybeat]

Nvidia driver is clearly not derivate work. Being derivate means taking something and expanding it. Nvidia driver on the contrary is a bridge between nvidia GPU and $kernel. Could be any $kernel. The driver without GPU is nothing. This also distinguishes DRI, Gallium and nvidia, and puts some specific light on the latter. For the bridge to work, it needs some open interfaces. GPL does not want those interfaces start acting like octopus tentacles, sucking many parts of free code into blob - thats about it. Whether one use/ship nvidia or not, is not questioned. That aspect and backdoor/dependence/trap one, ofc. The problem is - modern programming profits from intensive interoperability very much, but management wants to sell it as proprietary parts instead. The day nvidia realizes its position on the proprietary is its own major income hinderer, it will be a big leap forward.

I understand this position, I'm just telling you that it's not the only position out there.

Here, for example, is what Linus Torvalds has to say about GPL and kernel drivers:

There is nothing in the kernel license that allows modules to be non-GPLd.

The only thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is not protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

The module interface has never been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to install them, but the actual interfaces are not.

The original binary-only modules were for things that were pre-existing works of code, i.e., drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance.

In short, Crispin: I'm going to apply the patch, and, if you as a copyright holder of that file disagree, I will simply remove all of he LSM code from the kernel. I think it's very clear that an LSM module is a derived work, and thus copyright law and the GPL are not in any way unclear about it.

If people think they can avoid the GPL by using function pointers, they are wrong. And they have always been wrong.

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

Alan Cox is even more strict on this, IIRC.

Frankly, I'm surprised that people STILL don't know this and go on about linking, which is not in the GPL at all. The only thing that matters is whether the driver is derivative of the kernel.

FSF is not *evil* organisation, but strictly on side of users.

The FSF does not hold the copyright on the Linux kernel so it's not their battle.

Any single one of Linux copyright holders could sue a company which violated the kernel's license.

Most Linux distros do not ship binary blobs, but provide software to make downloading and installing them easier. There's a reason for this.

[Mike Frett]

Maybe I'll buy an Nvidia card, maybe. But I'm definitely NOT going to buy an overpriced Intel CPU. Sorry Valve, I'm sticking with AMD on the CPU part.

[Bathroom Humor]

I also was talking about them. Linus criticism was because Nvidia refuses to answer kernel developers questions.

That doesn't change the matter of those being the best drivers to go with.
If they were being ideological, they'd slap in some AMD cards with FOSS drivers, and I'm sure they would right now if it were the practical solution. But it's not.
Fortunately, it's not like using their non-free drivers is going to stop users from doing or using whatever hardware or software they want to, and won't stop Valve from making this a success. They are just shooting for the best-case scenario.