Messages in this thread | | | Date | Fri, 7 Mar 2003 02:23:43 +0100 (CET) | From | Roman Zippel <> | Subject | Re: [BK PATCH] klibc for 2.5.64 - try 2 |
| |
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/
| |