Re: A proposal - binary
From: Zachary Amsden
Date: Sat Aug 05 2006 - 01:35:10 EST
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/