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

Roman Zippel
2003-03-07T01:13:20Z

Hi,

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
paragraph:

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
executable.)

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