[lkml]   [2003]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BK PATCH] klibc for 2.5.64 - try 2

On Thu, 6 Mar 2003, H. Peter Anvin wrote:

> Actually, it's the MIT license, which differs from the (new) BSD license
> only in the no-endorsement clause, which seemed superfluous.
> It was chosen because klibc is a non-dynamic library, and it would
> otherwise be extremely awkward to link proprietary code against it if
> someone would like to do so.

Why would it be awkward? libgcc has the same problem, so they added this

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file. (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine

Why can't we do something similiar?

> Furthermore, I'm the author of most of the
> code in there, and if someone really wants to rip it off it's not a huge
> deal to me.

If it becomes part of the kernel (and a core part, not just some driver),
it would be awkward to have a completely different license, so this should
not be done without a very good reason.

bye, Roman

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.069 / U:2.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site