Zan Lynx wrote:
On Wed, 2005-02-02 at 16:30 -0800, Greg KH wrote:
On Wed, Feb 02, 2005 at 07:07:21PM -0500, Pavel Roskin wrote:
On Wed, 2 Feb 2005, Greg KH wrote:It is. And as such, it is not allowed.
On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:There will be a GPL'd layer, and it's likely that sysfs interaction will be on the GPL'd side anyway, for purely technical reasons. But it does feel like circumvention of the limitations set in the kernel.
What is wrong with creating a (GPL'd) abstraction layer that exports
symbols to the proprietary modules?
Ick, no!
Please consult with a lawyer before trying this. I know a lot of them
consider doing this just as forbidden as marking your module
MODULE_LICENSE("GPL"); when it really isn't.
[snip]
So, what's the magic amount of redirection and abstraction that cleanses the GPLness, hmm? Who gets to wave the magic wand to say what interfaces are GPL-to-non-GPL and which aren't?
For example, the IDE drivers use GPL symbols but the VFS does not. So
anyone can write a proprietary filesystem which eventually gets around
to driving the IDE layer. That is okay, but this isn't?
Well, it is ok because the proprietary FS in question does not access anything in the IDE layer. The VFS does not reexport ide symbols and interfaces. It is not a "workaround" for proprietary fs'es - someone who writes proper GPL code cannot simply take a shortcut, skip the VFS layer and have his GPL'ed fs drive the IDE layer directly. He'd end up with a stupid fs this way, one with artifical limitations such as being unable to work on SCSI too, and unable to cooperate properly with the VFS.
If skipping some GPL glue layer is possible, technically convenient, better for
performance but unfortunately illegal, then that is a strong hint that
the glue layer itself may be an illegal circumvention device. In some countries,
at least. The VFS however, is not a mere glue layer, it is an important
subsystem of its own. Sitting between block devices and filesystems
makes it a middle-man of course, but it is much more than that.
There is another alternative, which is to provide open drivers. The money isIf the trend of making everything _GPL continues, I don't see any choice for binary module vendors but to join together to develop a stable driver API and build it as a GPL/BSD module. Do the same API for BSD systems to prove modules using it are not GPL derived. Watch Greg foam. It'd be fun.
in pushing _hardware_, not drivers! And linux users are more likely to buy
the hardware device with the open driver, rather than the device with the
proprietary driver. So this is good for sales too. See the recent thread
about a open hw graphichs card. Lots of people got interested, because of
the "no secrets - *fully* documented" approach.
Nobody really needs to be a "binary vendor".
Helge Hafting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
