|| ||Linus Torvalds <firstname.lastname@example.org>|
|| ||Roman Zippel <email@example.com>|
|| ||Re: [BK PATCH] klibc for 2.5.64 - try 2|
|| ||Fri, 7 Mar 2003 15:05:32 -0800 (PST)|
|| ||"H. Peter Anvin" <firstname.lastname@example.org>, Greg KH <email@example.com>,
On Fri, 7 Mar 2003, Roman Zippel wrote:
> > Put the two together, and the GPL really doesn't look like a very good
> > license for klibc. Yeah, you can disagree about what the actual exceptions
> > are, but clearly there has to be _some_ exception to the license.
> This really doesn't speak against the GPL, if we do something similiar as
Sure. GPL with restrictions might work fine.
> Well, there wasn't much to argue against yet so far :), I'm still trying
> to find the reason for Peters decision.
That I can't answer. I don't personally think that BSD/MIT is any better
than GPL with restriction, and the real issue boils down to "what license
do people want to work on". Since Peter so far has been one of the major
developers, his opinion (regardless of _why_ he holds that opinion)
matters more than most to me.
Of course, some people have said that _they_ would want to work on it only
if it's GPL, but hey, the proof is in the pudding, and "A bird in the hand
is worth two in the bush". In other words, talk is cheap, and code rules.
Right now that means that hpa rules, methinks.
However, I also have to say that klibc is pretty late in the game, and as
long as it doesn't add any direct value to the kernel build the whole
thing ends up being pretty moot right now. It might be different if we
actually had code that needed it (ie ACPI in user space or whatever).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)