It is already treated separately, and has been for a long time. Since
ndiswrapper taints itself when it loads a proprietary NDIS module, I
don't think any special treatment is needed anymore, but that's beyond
my point.
All I'm trying to do it to revert a patch that, as its author
admitted, had unexpected consequences:
http://kerneltrap.org/mailarchive/linux-kernel/2008/1/30/648044
This is not the original intention of GPLONLY. GPLONLY exists to
prevent loading of modules that are proprietary, but can be considered
to be Linux derivatives due to their use of Linux specific API.
In case of ndiswrapper, there is no question that ndiswrapper is a
Linux derivative, but it's under GPL. Yet the proprietary modules are
not Linux derivatives because they don't use Linux API. In fact, they
were never intended to run on Linux.
By using GPLONLY to exclude ndiswrapper, you would give GPLONLY an
additional meaning, namely functions that are not available to
ndiswrapper.
That would mean that I would have to ask those symbols to be opened to
proprietary Linux kernel modules as well, which is not my intention.
Simple re-exporting would be useless. It's a wrapper that isolates
NDIS API from Linux API. Anything Linux specific is in ndiswrapper
itself. The proprietary modules call only NDIS functions.
I believe, the license is a choice of the copyright holders. Apart
from that, I don't feel qualified to discuss any legal matters.
--
Regards,
Pavel Roskin
--
