xen-devel
[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
opinon.
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).
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|