Messages in this thread | | | Date | Fri, 07 Mar 2003 16:46:29 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [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 disadvantages.
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.
-hpa
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |