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.
On Tuesday 13 June 2006 19:30, Brian F. G. Bidulock wrote:
Yes, and the long list of open source licenses listed on the FSF website
as incompatible with the GPL.
Conceded, I suppose. The usage of EXPORT_SYMBOL() though tends to be for the
reason of enabling drivers to offer functionality to the kernel -- not for
people who want to turn the kernel into applications. (Consider for example
how netfilter is exposed as GPL. You can build applications [routers] out of
it, but in that case you're doing a work derived off of Linux, and you should
be abiding by its GPL licensing terms)
quoted
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.
I'm not advocating changing the API for no reason / just to piss off out of
tree developers. I'm just trying to make clear that in these cases, 'stable'
is just an observation -- not something you can count on.
It is the lack of an ABI that is most frustrating to these users.
And the presence of an ABI would be _very_ frustrating to core developers. Not
only would these people suffer, everyone would -- developer time would be
wasted dealing with cruft, and forward progress would be slowed.
quoted
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.
Perhaps another term may have been more appropriate. What I mean by 'old tech'
is more 'existing code' -- ie, something you would port.
And these organizations _are_ afforded the opportunity to take the first step
-- that's why interfaces critical to drivers are currently EXPORT_SYMBOL().
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.
Sure it does, depending on your perspective and what you're willing to
consider. The lack of a stable API/ABI means that if you don't want to have
to do work tracking the kernel, you should push to have your drivers merged.
quoted
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.
Perhaps, but calling it 'stable' in any sense other than idle observation is a
disaster, because the idea leads to pain and suffering when you do have a
major reason to change the API.
Thanks,
Chase
On Tue, Jun 13, 2006 at 07:53:19PM -0500, Chase Venters wrote:
quoted
It is the lack of an ABI that is most frustrating to these users.
And the presence of an ABI would be _very_ frustrating to core
developers. Not only would these people suffer, everyone would --
developer time would be wasted dealing with cruft, and forward
progress would be slowed.
Note that just because an interface is EXPORT_SYMBOL doesn't mean that
the interface is guaranteed to be stable. So folks who are aruging
that an interface shouldn't be usable by non-GPL applications because
we are therefore guaranteeing a stable API are making an unwarranted
assumption.
- Ted