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

Roman Zippel
2003-03-08T16:45:02Z

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