Message-ID: <44D42E7D.70101@vmware.com>
Date:	Fri, 04 Aug 2006 22:37:01 -0700
From:	Zachary Amsden <zach@...are.com>
To:	James Bottomley <James.Bottomley@...elEye.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Wright <chrisw@...s-sol.org>, Greg KH <greg@...ah.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Christoph Hellwig <hch@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jack Lo <jlo@...are.com>, virtualization@...ts.osdl.org,
	xen-devel@...ts.xensource.com, pazke@...pac.ru,
	Andi Kleen <ak@...e.de>
Subject: Re: A proposal - binary

James Bottomley wrote:
> My take is that the VMI proposal breaks down into two pieces:
>   

This is a very accurate description of our interface.

> 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.
>   

This I think is an absolute must for any sane interpretation of the 
GPL.  Otherwise, running GPL apps on any proprietary operating system 
falls into the same situation, and you wouldn't be able to run them 
without violating the GPL.  Nor would you be able to run non-GPL 
applications on a GPL kernel.  It's really a matter of whether you 
interpret the intent of the GPL to prevent someone deriving work from 
your open source software and distributing that in binary form without 
providing the dervied work - or if you interpret the GPL as saying that 
all code must be open sourced.  The latter is a very extreme position, 
and I don't believe it is even correct with the current wording of GPL 
v2 (IANAL).

> 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, 
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.

> 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).
>   

Tagging is interesting.  You can tag modules by license.  I can't say 
today what license we will be able to use for it - it could be 
completely proprietary, some new license, BSD, or GPL.  This is the 
essence of my original rant - it would be nice to have a way to tag the 
license in the "blob" so the kernel can choose the appropriate course of 
action.  In that case, the pressure is off me to specify what the 
license is - it's there for everyone to see, and then it is just a 
matter of coming to a consensus as to what an acceptable license is for 
Linux to link to it.  What license(s) we provide is really not up to me, 
although I personally would very much like to see an open source license 
that allows everyone to see the code, fix any problems they have with 
it, and distribute those fixes (purely my own personal opinion, and in 
no way a statement, promise, or supposition in any legal or corporate 
sense for any past, present, or future work by VMware, EMC, or any other 
entity, wholly or partially owned by said corporations, and in no way 
should this be interpreted as constituting a legal opinion for the 
purposes of advice or rendering of any court decision, now, in the 
future, or in the past for legal arbiters with access to time travel 
equipment). <Now I'm covered better than Alan>.

Binary blob has been a PR disaster.  I don't know if I first said it 
unprompted, or if Cristoph cleverly baited me into using the phrase ;)  
But lets be clear on one thing - blob implies some kind of shapeless, 
fat thing.  The VMI fits in two pages of memory, and has a well defined 
interface, which gives it shape.  So I prefer binary redirection 
interface, or vDSO, or anything without the disparaged word "blob" in it.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists