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

Chase Venters
2006-06-14T07:58:34Z

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