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

["Brian F. G. Bidulock" <bidulock@openss7.org>]

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.

> 
> > 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.