Linus Puts Kibosh On Banning Binary Kernel Modules

microbee writes "On LKML's periodic GPL vs. binary kernel module discussion, Andrew Morton hinted that he favors refusing to load binary modules in 12 months. Greg Kroah-Hartman then posted a patch to do exactly that. Surprisingly Linus chimed in and called it 'stupid' and a 'political agenda,' and even compared it with the RIAA's tactics. Later in the same thread Greg withdrew his patch and apologized for not having thought it through."

Comments

They have a point, but....

[Lumpy]

I understand why those that want to ban binary only modules. It causes hell for everyone on the kernel dev team.

But.... banning them instantly pisses off every single company that is barely putting out a hardware driver for Linux already (nvidia for example) A ban will not make these people go "oh,ok... we'll release the source code." they will simply flip off all Linux users and tell them to pound sand.

Exactly

[rastilin]

I'm already in a situation where most distributions don't even install because the nv drivers they try to load at default won't work on my Geforce 6800. Even the latest vesa drivers seem unbearably slow. If this patch got into the tree, I'd switch to windows the exact same day.

Re:Exactly

[rastilin]

I've always wondered about something. If people can't get or release open-source versions of critical drivers, like the drivers Andrew Moreton was complaining about, what are they going to do? Switch? There HAS to be a balance between idealistic views of how the world should be and attention to how the world really is. There are plenty of examples, mostly involving failed government economic initiatives, where people acted according to an idealized version of what they thought the world should be and the situation spun off in a completely unforeseen direction, never to their benefit. In essence, if they DID stamp out all proprietary drivers, in userspace and kernel space. Then what? I may just be cynical but I can't come up with a scenario where nvidia, ati or any of the other companies would take the risk of billions worth of lawsuits, since a suit against the foundations of their designs (probably patented) would cripple a company if it hit, and actually open source their drivers. The users would lose and the viability of linux as an non-server system would take a plunge.

Re:BSD

[kebes]

No, Linus very much agrees with the "quid pro quo" of the GPL. He believes that if you take his code and extend it, you should have to contribute back. He believes in sharing (even if he's not as concerned as RMS is about fundamental freedom). In the linked post Linus says:

"If people take our code, they'd better behave according to our rules. But we shouldn't have to behave according to the RIAA rules just because we _listen_ to their music. Similarly, nobody should be forced to behave according to our rules just because they _use_ our system."
Clearly Linus does like the GPL restricting those who would distribute code (whereas BSD causes no restrictions). The point Linus is trying to make is that we have to distinguish between limitations to distribution and limitations to the end user. The proposed patch would mostly have limited the end-user (making it annoying for them to run binary modules). Linus is saying that we shouldn't try to limit the freedom of the end-user with technical restrictions. But (as quoted above) he clearly does like the fact that the GPL forces people who "take the code" to "behave according to the rules."

Hence Linus would not be happy with a BSD license.

question... why not LGPL the kernel then?

[cies]

okay in theory one cannot link any binairy blob with the kernel and redistribute it, this is forbidden by the (strong copy-left of the) GPL.
but if Linus wants to allow this why not put Linux under a license with a weaker copyleft, like the LGPL?

at the current situation i think the kernel devs are right when they feel the GPL is violated.

cies breijs.

Re:Backpatching

[a.d.trick]

The point is the message that this brings across. At the moment people are pretty lax about binary dirvers. A ban on them in the vanilla kernel will go a long way in telling the driver vendors to make their specs free or get out of Linux land. Free drivers would be awesome, but I don't know if Linux is strong enough to actually influence the vendors at this point so we might end up with nothing. Plus, implementing this at the code level seems like the wrong place to be doing it. As Linus said, the license ought to control the distribution not the usage.

Re:Not surprising at all

[halivar]

From another perspective, Linus's algorithm for deciding pragmatism is based on a greedy algorithm - it always spits out answers that look reasonable in the short term. He may be an excellent programmer and good project leader, but he seems to lack a sense of perspective.

Well, FSF's sense of "long-term" perspective has given them HURD. Linus's "lack" of perspective gives me Working Software Right Now(tm). In the end, that's all businesses really care about.

Vista

[Z34107]

I believe there is a restriction in 64-bit vista that prevents unsigned drivers.

Nope. There is a restriction in all versions of Vista against using unsigned kernel mode drivers. However, the new Windows Driver Model makes it possible for 99% of drivers (minus graphics drivers) to run in usermode.

So, you can't run unsigned kernel mode drivers. But, unlike XP, you don't have to run kernel mode drivers - they all run in userspace. Interesting, since this will cut heavily into the profits Microsoft makes from driver signing, but it make the OS a billion times more stable - usermode drivers can't bluescreen. (This is also why there's "hardware compatibility" problems with Vista right now - although the user-mode drivers are easier to write, not everyone has ported their drivers yet.)

Re:And of course Linus is right...

[IamTheRealMike]

I'm afraid the days of drivers being programs that tweaked registers is long gone, my friend. Some of them include advanced optimizing compilers. There's a reason the nvidia driver is nearly the same size as the kernel itself - it's an extremely complex piece of code, with many clever things being done in software.