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

[Brian F. G. Bidulock]

Chase,

On Tue, 13 Jun 2006, Chase Venters wrote:
> 
> Look out for that word (stable). Judging from history (and sanity), 
> arguing /in favor of/ any kind of stable module API is asking for it.

I was really just using Daniel's words.  I am all too aware that kernel
APIs are unstable.  To some it is a serious failing of Linux
(particularly those involved in porting kernel modules from branded UNIX
or embedded RTOS).  To those whatever stability that can be offered is a
boon.  To those, even worse is the lack of an ABI (even for a single
kernel version).

> 
> At least some of us feel like stable module APIs should be explicitly 
> discouraged, because we don't want to offer comfort for code 
> that refuses to live in the tree (since getting said code into the tree is 
> often a goal).

And that would be fine if we were completely agnostic toward what was
included in mainline, but we are not.  A particular case in point that
I deal with are STREAMS modules.  STREAMS continues to be forbidden from
the tree.  Nevertheless, STREAMS has historically provided one of the
most widespread mechanisms for providing value-added drivers to branded
UNIX or embedded RTOS offerings.  As a result, a large body of existing
drivers are cut off from the tree regardless of their licensing terms.

(Note that these is seldom a question of derivation for these drivers as
they are fully functioning on other operating systems: branded UNIX or
embedded RTOS.)

> 
> I'm curious now too - can you name some non-GPL non-proprietary modules we 
> should be concerned about? I'd think most of the possible examples (not 
> sure what they are) would be better off dual-licensed (one license 
> being GPL) and in-kernel.

Any open-source license not compatible with the GPL.  One that comes to
mind is OpenSolaris drivers.  I'm sure that there are others because there
are many license that qualify as open source licenses that are incompatible
with the GPL.  For example, pure BSD is incompatible with GPL.

Another thing to consider is that the first step for many organizations in
opening a driver under GPL is to release a proprietary module that at least
first works.  The second step is to jump through the hoops and over the
hurdles necessary to open what has been to date proprietary code that may
contain intellectual property issues across a number of organizations.

In adopting a policy that hinders this process, we, instead, discourage
opening of drivers and inclusion in mainline, rather than promoting it.

Sorry for the rant.
-
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/