Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 4 Apr 2002 10:39:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 4 Apr 2002 10:38:57 -0500 Received: from brooklyn-bridge.emea.veritas.com ([62.172.234.2]:15215 "EHLO einstein.homenet") by vger.kernel.org with ESMTP id ; Thu, 4 Apr 2002 10:38:41 -0500 Date: Thu, 4 Apr 2002 16:35:33 +0100 (BST) From: Tigran Aivazian X-X-Sender: To: Ingo Molnar cc: Alan Cox , Keith Owens , Marcelo Tosatti , Andrea Arcangeli , Arjan van de Ven , Hugh Dickins , Stelian Pop , Linus Torvalds , Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 4 Apr 2002, Ingo Molnar wrote: > The GPL right now protects our work from being abused in such a way - it's > illegal to provide a binary-only sched.o and compile a kernel product from > that, because the resulting kernel is still one work and the whole work > must still be under the GPL. It's equally illegal to recover the location > of sched.o in the final kernel image and runtime relink it with a > binary-only sched.o. It's equally illegal to accomplish the same over the > internal module interface. > > Think about it, every separate .o in the Linux kernel can be equivalently > expressed in terms of a EXPORT-ed module interface, GPL-ed header files > and a closed-source module. There is a good reason why the GPL forbids > such freely defined 'module interfaces' to be added. Think of the GPL as > the price you pay for being able to use the Linux kernel's source code or > being allowed to link to it - you are not forced in any way to do that. > > and no, you have no *right* to link a binary-only sched.o to the Linux > kernel - even if you develop a sched.c 'separately' - and intuitively feel > that it's somehow a separate work, the end result is still a derivative of > the kernel. And this violation of the license is illegal in most > countries, it's even a crime in some countries. After thinking about it for a while (and careful reading of your explanation) I must conclude that your view is probably safer, i.e. in the long term it is probably better for the Linux kernel to protect its status along the lines you described, even if it is not as "smooth" or "convenient to everyone" as the scheme I was talking about. On the issue of what should be considered a derivative and what shouldn't, from your email it seems (and it's not a bad thing, imho) that the Linux kernel is protecting itself to make sure that "interesting" functionality is either already in the kernel or exists as a GPL'd module. To make this thought clearer, let's say that there is no GPL'd journalling filesystem for Linux (i.e. reiserfs, ext3 and others suddenly disappeared). Then, to make your thoughts consistent you would need to disable the exported interfaces required for development of a journalling filesystem. Because, otherwise, you would be working on a "lite" OS and "interesting stuff will happen behind the closed doors". As I said, it is not necesserily "bad", i.e. it may well be necessary for Linux's survival and therefore I am all for it. I only thought that there is something _technically_ unpleasant or "wrong" about it... Maybe "wrong" is the wrong word, but you know what I mean. Regards, Tigran - 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/