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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:35 EST