Re: Please open sysfs symbols to proprietary modules

[Helge Hafting]

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:
> > >      
> > >
> > > > On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
> > > >        
> > > >
> > > > > 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.
> > > >        
> > > 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.
> > >      
> > It is.  And as such, it is not allowed.
> >    
> [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.

> If 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.
There is another alternative, which is to provide open drivers.  The 
money is
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/