From: Pavel Roskin <proski@gnu.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: incorrect taint of ndiswrapper
Date: Wed, 25 Oct 2006 16:11:09 -0400 [thread overview]
Message-ID: <1161807069.3441.33.camel@dv> (raw)
Hello, Alan!
>
> > non-GPL-due-to-transitivity going to be checked? Why does module loader mark
> > only couple of modules as non-GPL, when there are other drivers that load
> > some sort of binary code? It is understandable to mark a module as non-GPL if
> > it is lying about its license, but as far as that is concerned, ndiswrapper
> > (alone) is GPL.
>
> Yes. I don't think the current situation is neccessarily correct, but if
> it uses EXPORT_SYMBOL_GPL then the "now taint me" ought to fail and the
> driver ought to refuse to load a non GPL windows driver.
Why is that? I don't see any reasonable argument behind this
requirement. "now taint me" is not an equivalent to "I was lying about
my license". It means "I'm going to to something that kernel developers
don't want to debug".
I don't see any legal reasons behind this restriction. A driver under
GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
technical mechanism of enforcing GPL against non-free code, but
ndiswrapper is free. The non-free NDIS drivers are not using those
symbols.
Neither do I see any technical reasons. Tainting already means that the
kernel developers are not interested in possible problems created by the
driver. Imposing further limits on functionality of ndiswrapper makes
no sense. It only creates problems.
How is this situation different from denying other capabilities to the
drivers that have used GPL symbols? How can I be sure that my driver
will be able to request firmware from userspace even though it uses
sysfs functionality via EXPORT_SYMBOL_GPL? What if somebody decides
that it's immoral or questionable for a GPL driver to do so?
Regardless of whether ndiswrapper can work around the limitations
imposed on it, it sets a very bad precedent when kernel developers are
arbitrarily and deliberately breaking existing functionality of an
external driver without having any excuse whatsoever.
I hope the offending code will be backed from the kernel for 2.6.19. In
my opinion, further changes in that direction (if they are needed)
should be based on more solid reasons.
--
Regards,
Pavel Roskin
next reply other threads:[~2006-10-25 20:11 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 20:11 Pavel Roskin [this message]
2006-10-25 20:30 ` incorrect taint of ndiswrapper Alan Cox
2006-10-25 20:40 ` Kyle Moffett
2006-10-25 21:04 ` Alan Cox
2006-10-25 21:06 ` Pavel Roskin
2006-10-25 21:33 ` David Weinehall
2006-10-25 22:02 ` Pavel Roskin
2006-10-25 22:54 ` Alan Cox
2006-10-25 22:58 ` Alan Cox
2006-10-26 3:23 ` David Weinehall
2006-10-26 13:13 ` Thierry Vignaud
2006-10-26 13:21 ` Gianluca Alberici
2006-10-26 3:59 ` Andrew Morton
2006-10-26 9:03 ` Gianluca Alberici
2006-10-26 10:39 ` Alan Cox
2006-10-26 12:21 ` Giacomo A. Catenazzi
2006-10-26 12:59 ` Gianluca Alberici
2006-10-26 14:41 ` Al Viro
2006-10-26 14:55 ` Alan Cox
2006-10-26 16:00 ` Stephen Hemminger
2006-10-26 16:26 ` Gianluca Alberici
2006-10-27 14:24 ` Arjan van de Ven
2006-10-27 15:14 ` Stephen Hemminger
2006-10-26 19:19 ` Pavel Roskin
2006-10-26 21:46 ` Adrian Bunk
2006-10-26 22:29 ` Pavel Roskin
2006-10-26 23:00 ` Adrian Bunk
2006-10-26 23:36 ` Sven-Haegar Koch
2006-10-27 0:57 ` Adrian Bunk
2006-10-26 23:47 ` Pavel Roskin
2006-10-27 12:52 ` Roland Kuhn
2006-10-27 15:53 ` Pavel Roskin
2006-10-26 17:26 ` [PATCH ??] " Randy Dunlap
2006-10-27 14:23 ` Arjan van de Ven
2006-10-27 15:27 ` Randy Dunlap
2006-10-27 18:26 ` Andrew Morton
2006-10-27 22:56 ` Florin Malita
2006-10-27 22:56 ` Randy Dunlap
2006-10-27 23:05 ` Alan Cox
2006-10-27 23:02 ` Randy Dunlap
2006-10-27 23:12 ` Florin Malita
2006-10-27 23:23 ` Oleg Verych
2006-10-29 11:27 ` Gianluca Alberici
2006-10-27 21:32 ` Florin Malita
2006-10-27 4:32 ` Florin Malita
-- strict thread matches above, loose matches on Subject: below --
2006-10-23 5:41 Giridhar Pemmasani
2006-10-23 5:53 ` Gianluca Alberici
2006-10-23 6:25 ` Chase Venters
2006-10-23 6:41 ` Giridhar Pemmasani
2006-10-23 6:48 ` Gianluca Alberici
2006-10-23 7:12 ` Chase Venters
2006-10-23 11:07 ` Giridhar Pemmasani
2006-10-23 9:10 ` Gianluca Alberici
2006-10-23 9:39 ` Michal Schmidt
2006-10-23 8:24 ` Bernd Petrovitsch
2006-10-23 10:41 ` Alan Cox
2006-10-23 11:35 ` Giridhar Pemmasani
2006-10-23 13:00 ` Alan Cox
2006-10-24 2:43 ` Giridhar Pemmasani
2006-10-24 3:11 ` Randy Dunlap
2006-10-24 12:12 ` Pekka Enberg
2006-10-24 12:22 ` Alan Cox
2006-10-24 14:07 ` Alan Cox
2006-10-23 18:36 ` Zan Lynx
2006-10-24 11:59 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1161807069.3441.33.camel@dv \
--to=proski@gnu.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox