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

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/

Relevant Pages

  • Re: FC4 or FC5
    ... If you want to opt out of GPL and use open source, BSD is most ... of vendor-provided drivers seem more likely. ... There isn't any 'taint' from GPL license on BSD. ...
    (Fedora)
  • Re: Dear Fedora Community, what do you want?
    ... > I've said that people should use Free Software, ... > you don't need to use the GNU GPL. ... I will be happy with Free Software drivers that use a Free Software ... > license that is compatible both with xorg x11 and the GNU GPL. ...
    (Fedora)
  • Re: Java problem
    ... use the drivers from the hardware manufacture. ... under the GPL. ... is a fair amount of code licensed under more then one license. ... I'm not interested in hijacking anything. ...
    (Fedora)
  • Re: Content searching in kernel mode
    ... If you use GPL code in your product you have to provide access to the source ... The Microsoft DDK's license says you can't use their stuff if it ... > As this pertains to writing and distributing drivers, ...
    (microsoft.public.development.device.drivers)
  • RE: Additional clauses to GPL in network drivers
    ... > licensing condition/clarification, in addition to being placed under ... > entire operating system is licensed under the GPL". ... 'license' is not compatible with the GPL. ... > drivers were based on, and include, other developer's purely GPL'ed ...
    (Linux-Kernel)