[lkml]   [2003]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BK PATCH] klibc for 2.5.64 - try 2
Roman Zippel wrote:
> But before it's actually merged, I would slowly really like to know the
> reasoning for license. You completely avoid that question and that makes
> me nervous.

Actually I don't, you just don't like to hear the answer. I believe I
have stated and restated this several times already.

> Why did you choose this license over any GPL variant?
> We could as well integrate dietlibc and if anyone has a problem with it,
> he can still choose your klibc.
> Why should I contribute to klibc instead of dietlibc?

One more time, with feeling...

a) I, as well as the other early userspace developers, feel that the
advantages of allowing linking nonfree applications outweigh the

b) I will personally go batty if I ever have to create yet another
implementation of printf() and the few other things in klibc that is
anything other than a thin shim over the kernel interface. The bottom
line is that klibc is so Linux-specific, that the only way someone would
"steal" code from it is because they want a specific subroutine
somewhere, and as far as I'm concerned, they can have it, and I don't
care in the slightest for what project.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.076 / U:4.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site