Re: [BK PATCH] klibc for 2.5.64 - try 2

[Roman Zippel]

Hi,

On Fri, 7 Mar 2003, David Lang wrote:

> > There is still the possibility to support multiple libc implementation, if
> > you don't like dietlibc, you're still free to use klibc.
> 
> along the same lines if you don't like klibc you are free to use or
> implement dietlibc or anything else.

Ok, it seems this requires a larger explanation.
It doesn't matter what you or I like. As long as dietlibc or klibc and 
linux are separate projects, I don't care much about the license. I have 
little problems to contribute to a BSD project, if you look at the m68k 
fpu emulator you will find a dual license. I hope this makes it clear that 
I'm not against the BSD license.

The problem starts as soon as klibc becomes part of the linux kernel, as 
it would give a clear preference to similiar projects as dietlibc. It's 
hard to imagine, that this will not cause any problem. The easiest 
solution would be relicense klibc under a license which is closer to the 
kernel license, but on the other hand meets the requirements the current 
license was choosen for. AFAICS a libgcc like license would do this job, 
but Peter made it very clear, that he does not want a different license, 
although it's unfortunately unclear why, but I have to respect that.

This means now we have to come back to the original problem: what problems 
might occur, if klibc is integrated and distributed with the kernel? Will 
it be possible to use dietlibc? What does that mean for other early 
userspace code, has to be licensed under the klibc license? Can I take 
source from a GPL project and integrate that into klibc?
I think it's important to discuss such questions now, as long as still 
possible without a lawyer, is the module story not warning enough?
My opinion at this point is, as long as Peter avoids to dicuss these 
issues, we should also consider to avoid integrating klibc in the kernel.

bye, Roman