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

Chase,

On Tue, 13 Jun 2006, Chase Venters wrote:

It depends on what you mean by "pure-BSD". If you're talking about the 
4-clause license with the advertising clause, then you are correct. Otherwise 
(IANAL) but my understanding is that BSD code can even be relicensed GPL by a 
third party contribution (though it is perhaps kind to ask for relicensing 
permission anyway).

Yes, and the long list of open source licenses listed on the FSF website
as incompatible with the GPL.

Then would offering a 'stable API in disguise' not be a disaster and an 
irritation to these people? If the kernel doesn't specify that an in-kernel 
interface is stable, then there is no reason to expect it to be. It might not 
change, but there won't be too much sympathy for out-of-tree users if it 
does. The kernel comes with big warnings about the lack of a stable API for a 
reason.

In fact most core kernel facilities (spin lock, memory caches, character and
block device interface, even core file system) have had a very stable API
(way back to early 2.4 kernels).  An in fact most of them are derived from
some variant or precursor to UNIX.  For example, memory caches are a Sun
Solaris concept.

It is the lack of an ABI that is most frustrating to these users.

quoted

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.  

If the driver is an old-tech Linux port, then it seems there isn't too much 
stopping them from doing this today (aside from the fact that some people 
think proprietary modules are murky anyway). In this case, we don't want a 
stable API/ABI, because then we leave them with little incentive to open the 
code.

"old-tech"?  No, these are high-tech drivers supported by commercial RTOS,
from which Linux stands to benefit.  And, by not allowing these organizations
to take the first step (generate a workable Linux driver) such a policy
provides them little incentive to ever move the driver to Linux, and cuts
them off from opening it.

I don't think that it is fair to say that an unstable API/ABI, in of itself,
provides an incentive to open an existing proprietary driver.

We're not as perfect as I wish we were. But the lack of stable API (dead 
horse) is something that is fairly well established and understood. I think 
most people feel that the cost-benefit analysis, for Linux anyway, strongly 
favors no stable API.

Well, the lack of a stable ABI is well known.  The API is largely stable (but
not sacrosanctly so) for the major reason that changing it within a large
code base is difficult and error prone at best.