Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters <chase.venters@clientec.com>]

On Wednesday 14 June 2006 01:06, Brian F. G. Bidulock wrote:
>
> The interface currently under discussion is ultimately derived from the BSD
> socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of
> EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and
> can be defeated with 3 or 4 obvious (and probably existing) lines of code. 
> I wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of
> using pointers directly quite a few years ago.  I doubt I was the first.
> There is nothing really so novel here that it deserves _GPL.

I mentioned that I don't have any particular opinion on the BSD socket API in 
this discussion. All that I'm speaking of here is a property of licensing. 

I've watched a lot of what has happened with binary drivers. You'll find in 
the LKML archives plenty of lengthy discussions about whether or not binary 
drivers are allowed under the GPL. If I were to guess, there is still 
disagreement. Although some hardware support could improve, we thankfully 
seem to have some kind of an equilibrium capable of supporting lots of users.

One point I remember coming up in the discussion was that the 
EXPORT_SYMBOL()/EXPORT_SYMBOL_GPL() split was a compromise of sorts. 
Interfaces that were needed to support users would reasonably be placed under 
EXPORT_SYMBOL(). By contrast, EXPORT_SYMBOL_GPL() would indicate 
functionality that would only seem to be used by derived works. It implies 
that any code using it should probably be GPL as well.

I don't raise this in an attempt to belittle anything people are working on. 
It's an observation about the ecosystem - Linux in the 2.6 series has seen a 
great amount of corporate contribution in terms of enhancing what the kernel 
is capable of doing. GPL, I believe, encourages this.

Thanks,
Chase