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: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: A proposal - binary
From: James Bottomley <James.Bottomley@xxxxxxxxxxxx>
Date: Fri, 04 Aug 2006 21:14:45 -0400
Cc: Zachary Amsden <zach@xxxxxxxxxx>, 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
Delivery-date: Mon, 07 Aug 2006 02:14:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1154726800.23655.273.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2006-08-04 at 22:26 +0100, Alan Cox wrote:
> In part thats a legal question so only a lawyer can really tell you
> what
> is and isn't the line for derivative works. 

Actually, this isn't quite true.  In any licensing agreement between two
parties, what each thinks is an important consideration in the
enforcement of the agreement.  This is how we got binary modules in the
first place, and so it also follows that what kernel developers think
about this proposal is an important influence on the eventual legal

My take is that the VMI proposal breaks down into two pieces:

1) A hypervisor ABI.  This is easy: we maintain ABIs today between libc
and the kernel, so nothing about an ABI is inherantly GPL violating.

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.

I think that if we do this tagging to load the VMI vDSO interface, then
I'm happy that all of the legal niceties are safely taken care of.
(Although the onus is now back on VMware to establish if they can GPL
their VMI blob).


Xen-devel mailing list