[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.022 / U:8.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site