GPL-only symbols and ndiswrapper

Posted Oct 25, 2006 18:22 UTC (Wed) by sfeam (subscriber, #2841)
Parent article: GPL-only symbols and ndiswrapper

"There does not seem to be any particular interest in the kernel community in backing down on this change"

If true, I find this a very troubling symptom of an increasingly politicized stance on the part of some kernel developers, possibly exascerbated by the ongoing GPL2 vs. GPL3 flame-fests.

I do not know whether ndiswrapper truly needs these GPL symbols; let us assume that it does. Modifying the kernel to forbid access to them appears to me a purely punitive action, with no grounding in fairness, copyright, or technical justification. It goes well beyond any concern of compliance with the re-distribution clauses of the GPL, since its primary effect is on the end-user, who can no longer load and run legally obtained, independent pieces of software.

Tainting? - OK, that is justifiable for technical reasons. But to outright forbid running non-GPL code is a sad retreat from what I have up until now seen as the overall spirit of linux development - one of inclusiveness, helpfulness, practicality, and a general aversion to hard-line politics.

I am hopeful, however, that you have mis-read the mood of the lkml response. It seemed to me that an alternative proposal to make ndiswrapper an officially-blessed kernel component was not rejected outright. This would allow more finely-considered restrictions on use to be implemented in ndiswrapper itself, with input and review from developers with legitimate concerns.

Runtime restrictions

Posted Oct 25, 2006 18:53 UTC (Wed) by man_ls (guest, #15091) [Link] (5 responses)

Speaking of GPLv3, suddenly end use restrictions are good? Whatever happened to:

our belief in the essential freedoms of section 3 forbids us from ever accepting any licence which contains end use restrictions.

It will be a good change if it ends up in more free drivers. But to limit users' possibilities to load modules at runtime is a different thing, IMHO. After all ndiswrapper was always meant as an interim solution.

Runtime restrictions

Posted Oct 25, 2006 20:32 UTC (Wed) by cventers (guest, #31465) [Link] (4 responses)

The even greater irony is that the document you link is wrong about end
use restrictions in the first place. GPL's terms don't even apply to the
end user. It only restricts what you do when you make copies.

Runtime restrictions

Posted Oct 30, 2006 14:23 UTC (Mon) by liljencrantz (guest, #28458) [Link] (3 responses)

Isn't a distributor also usually an end user? Shouldn't the rights granted to a distributor also be granted to an end user?

For example, many GPL:ed pieces of software are licendes under GPL2 or later. So the end user may choose if he accepts the license terms of GPL2, GPL3 or GPL4. But does that mean that any user may download the source of a package, accept the license terms of GPL2, modify the package and then release the resulting derivative work under GPL2 only?

Runtime restrictions

Posted Oct 30, 2006 14:45 UTC (Mon) by cventers (guest, #31465) [Link]

A distributor may also be an end user, but calling restrictions on
distribution 'end use restrictions' is wrong and/or intellectually
dishonest, because the restrictions in question don't apply to mere end
users and only apply to distributors.

And yes, the end user can relicense within the GPL depending on the "or
any later version" clause or lack of version specification.

Runtime restrictions

Posted Nov 2, 2006 12:05 UTC (Thu) by forthy (guest, #1525) [Link] (1 responses)

Yes, any user/distributor can do that. And actually that's what Linus Torvalds did, when he put his "GPLv2 only" comment on top of COPYING in 2.4.0-test-something.

Runtime restrictions

Posted Nov 2, 2006 12:25 UTC (Thu) by arcticwolf (guest, #8341) [Link]

No, that's definitely not what he did.

If you read the GPL, you will find that the whole "any later version" thing is not actually part of the license. It's being used in the example of how to apply the GPL to your work, but the license itself does not contain any clause like that. (In fact, if it did, the whole "GPL v2 or later" vs. "GPL v2 only" distinction would be meaningless; the GPL v2 would already say that any later version is also acceptable, and declaring a program to be licensed under "the GPL v2 only" would make no sense, just like saying "licensed under the GPL, but you may not make copies or modify it" doesn't make sense, either.)

It's important to keep this in mind. Linus licensed Linux under the GPL, but he never used the "any later version" language, so Linux[1] was *always* licensed under the GPL v2 only. The change you mention merely made this explicit to combat confusion.

1. That is, the parts he holds the copyright to, as well as Linux as a whole; individual parts contributed by others may well be available under additional licenses, such as later versions of the GPL, of course.

GPL-only symbols and ndiswrapper

Posted Oct 25, 2006 19:04 UTC (Wed) by uravanbob (guest, #4050) [Link]

Well said.

GPL-only symbols and ndiswrapper

Posted Oct 25, 2006 20:34 UTC (Wed) by proski (subscriber, #104) [Link] (5 responses)

I do not know whether ndiswrapper truly needs these GPL symbols; let us assume that it does.

USB support cannot be implemented without them. The message is quite misleading, by the way:

Symbol usb_register_driver is being used by a non-GPL module, which will 
not be allowed in the future

GPL-only symbols and ndiswrapper

Posted Oct 26, 2006 1:18 UTC (Thu) by i3839 (guest, #31386) [Link] (4 responses)

USb drivers can be written in userspace anyway, so that shouldn't be a problem.

GPL-only symbols and ndiswrapper

Posted Oct 26, 2006 17:38 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

Yeah, but how are those userspace drivers supposed to talk to the rest
of the kernel and the non-GPLONLY functions and services it provides?

What if you need other kernel services? What if you have tight timing requirements?

From what I can tell, the userspace usb stuff basically sets you up to
do URB tx/rx, but nothing more. It's useless if you need to hook into the rest of the kernel.

For many types of devices, userspace drivers make sense, but that should be a *technical* decision.

GPL-only symbols and ndiswrapper

Posted Oct 28, 2006 0:26 UTC (Sat) by i3839 (guest, #31386) [Link] (2 responses)

I thought we were talking about binary only modules and ndiswrapper? In that light I don't see how that construction could be in anyway better than when pushed to userspace. Currently closed source kernel modules from ATI and Nvidia should also be put into userspace with no more than a tiny kernel module handling the necessary, IMHO.

Those drivers want to talk to their hardware, not to the rest of the kernel which they shouldn't know or care about.

GPL-only symbols and ndiswrapper

Posted Oct 31, 2006 2:17 UTC (Tue) by proski (subscriber, #104) [Link] (1 responses)

I thought we were talking about binary only modules and ndiswrapper? In that light I don't see how that construction could be in anyway better than when pushed to userspace.

I think many people would prefer not to run closed source Windows driver with the kernel permissions (in "ring 0" in x86 terminology). Of course, having a network driver in userspace can have its drawbacks.

Currently closed source kernel modules from ATI and Nvidia should also be put into userspace with no more than a tiny kernel module handling the necessary, IMHO.

Sorry, that's getting off-topic, and I'm in now way a video card expert, but how are you going to emulate Linux API expected by those modules (provided you are talking about Linux modules)? Are you going to reimplement it in userspace? I think that's going to be the hard part, and not the "tiny kernel module".

GPL-only symbols and ndiswrapper

Posted Oct 31, 2006 13:38 UTC (Tue) by i3839 (guest, #31386) [Link]

The few extra milliseconds latency is well worth it, if it's even that high.

> how are you going to emulate Linux API expected by those modules (provided you are talking about Linux modules)?
> Are you going to reimplement it in userspace?

Well, you'd hope they don't expect Linux specific API functions, or keeping them closed source makes it even more questionable than it already is. So I assume they only need general hardware interaction functions, like setting up interrupt handlers and things like that. In the case of graphic cards they have a way to send data and commands to the card, they might need a bit help with DMA and stuff from the kernel, but other than that not much more needs to be done by the kernel and the rest can be done by the userspace driver.

The userspace driver will not be easy to make and most likely be slightly slower, but even if that's 10% it's worth it to get the 4MB big unknown blob out of kernel space.