lkml.org 
[lkml]   [2005]   [Feb]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Please open sysfs symbols to proprietary modules
FromZan Lynx <>
DateWed, 02 Feb 2005 21:54:02 -0700
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?

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.
--
Zan Lynx <zlynx@acm.org>
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:10    [from the cache]
©2003-2008