This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: A proposal - binary

To: Zachary Amsden <zach@xxxxxxxxxx>
Subject: [Xen-devel] Re: A proposal - binary
From: Adrian Bunk <bunk@xxxxxxxxx>
Date: Sat, 5 Aug 2006 12:42:55 +0200
Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Greg KH <greg@xxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, pazke@xxxxxxxxx, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 07 Aug 2006 02:28:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44D42E7D.70101@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44D1CC7D.4010600@xxxxxxxxxx> <20060803190605.GB14237@xxxxxxxxx> <44D24DD8.1080006@xxxxxxxxxx> <20060803200136.GB28537@xxxxxxxxx> <20060804183448.GE11244@xxxxxxxxxxxxxxxxxxxx> <44D3B0F0.2010409@xxxxxxxxxx> <1154726800.23655.273.camel@xxxxxxxxxxxxxxxxxxxxx> <1154740485.3683.161.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <44D42E7D.70101@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
On Fri, Aug 04, 2006 at 10:37:01PM -0700, Zachary Amsden wrote:
> James Bottomley wrote:
> >2) A gateway page or vDSO provided by the hypervisor to the kernel.
> >This is the problematic piece, because the vDSO is de-facto linked into
> >the kernel and as such becomes subject to the prevailing developer
> >interpretation as being a derivative work by being linked in.  As Arjan
> >pointed out, this can be avoided as long as the gateway page itself is
> >GPL ... we could even create mechanisms like we use today for module
> >licensing by having a tag in the VMI describing the licensing of the
> >gateway page, so the kernel could be made only to load gateway pages
> >that promise they're available under the GPL.
> Yes, this is what prompted my whole module rant.  The interesting thing 
> is - Linux may link to the hypervisor vDSO.  But it may not link back 
> into Linux.  This is where the line becomes very gray, as Theodore 
> mentioned earlier.  Is it a license violation for a GPL app to link 
> against a non-GPL library?  Surely, the other way around is a problem, 

I don't see the grey area.

Assuming non-GPL and not GPL compatible (e.g. 3 clause BSD is non-GPL 
but compatible):

Unless all people holding a copyright on the GPL app agreed that this 
linking is OK, it is considered a licence violation.

That's why you often see licence statements like the following:

"In addition, as a special exception, the Free Software Foundation
gives permission to link the code of its release of Wget with the
OpenSSL project's "OpenSSL" library (or with modified versions of it
that use the same license as the "OpenSSL" library), and distribute
the linked executables.  You must obey the GNU General Public License
in all respects for all of the code used other than "OpenSSL".  If you
modify this file, you may extend this exception to your version of the
file, but you are not obligated to do so.  If you do not wish to do
so, delete this exception statement from your version."

> unless the library has been made explicitly LGPL.  But if GPL apps can 
> link to non-GPL libraries, what stops GPL kernels from linking to 
> non-GPL modules?  This is where I think things become more interpretive 
> than well defined.  And that is why it is important for us to get kernel 
> developers feedback on exactly what that definition is.

Some kernel developers (and some lawyers) consider all kernel modules 
with not GPL compatible licences illegal - similar to the case of 
linking a GPL app with a non-GPL library.

Quoting Novell [1]:

"Most developers of the kernel community consider non-GPL kernel
modules to be infringing on their copyright. Novell does respect this
position, and will no longer distribute non-GPL kernel modules as part 
of future products. Novell is working with vendors to find alternative
ways to provide the functionality that was previously only available
with non-GPL kernel modules."

And considering the number of people having a copyright on parts of the 
kernel, there's noone except a court who can tell what is OK and what is 
not (and even a court decision is not binding for courts in other 

> Zach


[1] http://lists.opensuse.org/archive/opensuse-announce/2006-Feb/0004.html


    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>