[Qemu-devel] Add support for new image type

[Qemu-devel] Add support for new image type

[Kai Meyer]

Is it possible to extend qemu to support a new image type? I have an 
image type that is ready for consumption and I'm looking for the 
integration point between qemu and the new image format.

-Kai Meyer

Re: [Qemu-devel] Add support for new image type

[Brian Jackson]

On Wed, 29 Feb 2012 15:52:49 -0600, Kai Meyer <kai.meyer@storagecraft.com>  
wrote:

> Is it possible to extend qemu to support a new image type? I have an  
> image type that is ready for consumption and I'm looking for the  
> integration point between qemu and the new image format.


The last new image format that was added to Qemu was probably qed.
You could look through the list archives to see the patches that added
that support. Alternatively look through the gitweb interface for the
commit. Part of it is at:

http://git.qemu.org/?p=qemu.git;a=commit;h=75411d236d93d79d8052e0116c3eeebe23e2778b



>
> -Kai Meyer
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: [Qemu-devel] Add support for new image type

[Kevin Wolf]

Am 29.02.2012 22:52, schrieb Kai Meyer:
> Is it possible to extend qemu to support a new image type? I have an 
> image type that is ready for consumption and I'm looking for the 
> integration point between qemu and the new image format.

Which image format do you want to get integrated?

Have a look at block/qcow2.c to get an idea of what a qemu block driver
looks like. At the bottom of the file there is a struct that contains
function pointers to all exported functions, so this is usually a good
place to start exploring a driver.

Kevin

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 03/01/2012 08:03 AM, Kevin Wolf wrote:
> Am 29.02.2012 22:52, schrieb Kai Meyer:
>> Is it possible to extend qemu to support a new image type? I have an
>> image type that is ready for consumption and I'm looking for the
>> integration point between qemu and the new image format.
> Which image format do you want to get integrated?
>
> Have a look at block/qcow2.c to get an idea of what a qemu block driver
> looks like. At the bottom of the file there is a struct that contains
> function pointers to all exported functions, so this is usually a good
> place to start exploring a driver.
>
> Kevin

Great, this is exactly what we're after. I work for StorageCraft, and we 
would like to figure out some way to allow qemu to directly consume our 
image-based backups. It would provide us with user-space mounting (via 
libguestfs) as well as booting VMs directly from Backup images. We 
already have a proprietary image access library that provides block-wise 
access to our image files. I have been able to scratch together a proof 
of concept already, which I am really pleased with.

I see only two roadblocks for which I don't have immediate answers for.

1) Licensing
Is it possible to license our contributions in such a way that we do not 
need to open the source code of our image access library?
2) External dependency on our image access library.
We do not want to force qemu to require our image access library to be 
present to build. Would it be better to do a conditional build 
(./configure --with-spf) or a run-time check for our image access library?

Re: [Qemu-devel] Add support for new image type

[Stefan Weil]

Am 01.03.2012 20:45, schrieb Kai Meyer:
> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>> Is it possible to extend qemu to support a new image type? I have an
>>> image type that is ready for consumption and I'm looking for the
>>> integration point between qemu and the new image format.
>> Which image format do you want to get integrated?
>>
>> Have a look at block/qcow2.c to get an idea of what a qemu block driver
>> looks like. At the bottom of the file there is a struct that contains
>> function pointers to all exported functions, so this is usually a good
>> place to start exploring a driver.
>>
>> Kevin
>
> Great, this is exactly what we're after. I work for StorageCraft, and 
> we would like to figure out some way to allow qemu to directly consume 
> our image-based backups. It would provide us with user-space mounting 
> (via libguestfs) as well as booting VMs directly from Backup images. 
> We already have a proprietary image access library that provides 
> block-wise access to our image files. I have been able to scratch 
> together a proof of concept already, which I am really pleased with.
>
> I see only two roadblocks for which I don't have immediate answers for.
>
> 1) Licensing
> Is it possible to license our contributions in such a way that we do 
> not need to open the source code of our image access library?

This is not possible if you want to link your image access library 
statically.

QEMU uses GPL v2. You can use a patched QEMU internally,
but as soon as you want to give it to customers (or get it integrated
in the official source tree), you must publish all code which is needed
under an open license.

If your image access library is a shared library (linked at runtime),
the situation is more difficult. The intention of the GPL is still
that you have to publish your code (this is also what the FSF says),
but there are different opinions for GPL v2. See
http://en.wikipedia.org/wiki/GNU_General_Public_License for
more information.

I personally don't like the idea of QEMU supporting closed source
shared libraries.

> 2) External dependency on our image access library.
> We do not want to force qemu to require our image access library to be 
> present to build. Would it be better to do a conditional build 
> (./configure --with-spf) or a run-time check for our image access 
> library?

You'll need the conditional build for those people who don't want support
for your image type.

Regards,

Stefan Weil

Re: [Qemu-devel] Add support for new image type

[Stefan Weil]

Am 01.03.2012 21:10, schrieb Stefan Weil:
> Am 01.03.2012 20:45, schrieb Kai Meyer:
>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>> Is it possible to extend qemu to support a new image type? I have an
>>>> image type that is ready for consumption and I'm looking for the
>>>> integration point between qemu and the new image format.
>>> Which image format do you want to get integrated?
>>>
>>> Have a look at block/qcow2.c to get an idea of what a qemu block driver
>>> looks like. At the bottom of the file there is a struct that contains
>>> function pointers to all exported functions, so this is usually a good
>>> place to start exploring a driver.
>>>
>>> Kevin
>>
>> Great, this is exactly what we're after. I work for StorageCraft, and 
>> we would like to figure out some way to allow qemu to directly 
>> consume our image-based backups. It would provide us with user-space 
>> mounting (via libguestfs) as well as booting VMs directly from Backup 
>> images. We already have a proprietary image access library that 
>> provides block-wise access to our image files. I have been able to 
>> scratch together a proof of concept already, which I am really 
>> pleased with.
>>
>> I see only two roadblocks for which I don't have immediate answers for.
>>
>> 1) Licensing
>> Is it possible to license our contributions in such a way that we do 
>> not need to open the source code of our image access library?
>
> This is not possible if you want to link your image access library 
> statically.
>
> QEMU uses GPL v2. You can use a patched QEMU internally,
> but as soon as you want to give it to customers (or get it integrated
> in the official source tree), you must publish all code which is needed
> under an open license.
>
> If your image access library is a shared library (linked at runtime),
> the situation is more difficult. The intention of the GPL is still
> that you have to publish your code (this is also what the FSF says),
> but there are different opinions for GPL v2. See
> http://en.wikipedia.org/wiki/GNU_General_Public_License for
> more information.
>
> I personally don't like the idea of QEMU supporting closed source
> shared libraries.
>
>> 2) External dependency on our image access library.
>> We do not want to force qemu to require our image access library to 
>> be present to build. Would it be better to do a conditional build 
>> (./configure --with-spf) or a run-time check for our image access 
>> library?
>
> You'll need the conditional build for those people who don't want support
> for your image type.
>
> Regards,
>
> Stefan Weil


I forgot to mention a possible solution: instead of using your image 
access library
(which is closed source), you could write new access code (maybe with 
reduced
functionality) and publish that code under an open source license.

QEMU uses this approach for some image types where we don't have the
original source code (for example block/vpc.c or block/vmdk.c).

Regards,
Stefan Weil

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 03/01/2012 01:18 PM, Stefan Weil wrote:
> Am 01.03.2012 21:10, schrieb Stefan Weil:
>> Am 01.03.2012 20:45, schrieb Kai Meyer:
>>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>>> Is it possible to extend qemu to support a new image type? I have an
>>>>> image type that is ready for consumption and I'm looking for the
>>>>> integration point between qemu and the new image format.
>>>> Which image format do you want to get integrated?
>>>>
>>>> Have a look at block/qcow2.c to get an idea of what a qemu block 
>>>> driver
>>>> looks like. At the bottom of the file there is a struct that contains
>>>> function pointers to all exported functions, so this is usually a good
>>>> place to start exploring a driver.
>>>>
>>>> Kevin
>>>
>>> Great, this is exactly what we're after. I work for StorageCraft, 
>>> and we would like to figure out some way to allow qemu to directly 
>>> consume our image-based backups. It would provide us with user-space 
>>> mounting (via libguestfs) as well as booting VMs directly from 
>>> Backup images. We already have a proprietary image access library 
>>> that provides block-wise access to our image files. I have been able 
>>> to scratch together a proof of concept already, which I am really 
>>> pleased with.
>>>
>>> I see only two roadblocks for which I don't have immediate answers for.
>>>
>>> 1) Licensing
>>> Is it possible to license our contributions in such a way that we do 
>>> not need to open the source code of our image access library?
>>
>> This is not possible if you want to link your image access library 
>> statically.
>>
>> QEMU uses GPL v2. You can use a patched QEMU internally,
>> but as soon as you want to give it to customers (or get it integrated
>> in the official source tree), you must publish all code which is needed
>> under an open license.
>>
>> If your image access library is a shared library (linked at runtime),
>> the situation is more difficult. The intention of the GPL is still
>> that you have to publish your code (this is also what the FSF says),
>> but there are different opinions for GPL v2. See
>> http://en.wikipedia.org/wiki/GNU_General_Public_License for
>> more information.
>>
>> I personally don't like the idea of QEMU supporting closed source
>> shared libraries.
>>
>>> 2) External dependency on our image access library.
>>> We do not want to force qemu to require our image access library to 
>>> be present to build. Would it be better to do a conditional build 
>>> (./configure --with-spf) or a run-time check for our image access 
>>> library?
>>
>> You'll need the conditional build for those people who don't want 
>> support
>> for your image type.
>>
>> Regards,
>>
>> Stefan Weil
>
>
> I forgot to mention a possible solution: instead of using your image 
> access library
> (which is closed source), you could write new access code (maybe with 
> reduced
> functionality) and publish that code under an open source license.
>
> QEMU uses this approach for some image types where we don't have the
> original source code (for example block/vpc.c or block/vmdk.c).
>
> Regards,
> Stefan Weil
>
I haven't planned on pitching that as a solution, but I will keep it in 
mind.

Re: [Qemu-devel] Add support for new image type

[Anthony Liguori]

On 03/01/2012 02:18 PM, Stefan Weil wrote:
> Am 01.03.2012 21:10, schrieb Stefan Weil:
>> Am 01.03.2012 20:45, schrieb Kai Meyer:
>>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>>> Is it possible to extend qemu to support a new image type? I have an
>>>>> image type that is ready for consumption and I'm looking for the
>>>>> integration point between qemu and the new image format.
>>>> Which image format do you want to get integrated?
>>>>
>>>> Have a look at block/qcow2.c to get an idea of what a qemu block driver
>>>> looks like. At the bottom of the file there is a struct that contains
>>>> function pointers to all exported functions, so this is usually a good
>>>> place to start exploring a driver.
>>>>
>>>> Kevin
>>>
>>> Great, this is exactly what we're after. I work for StorageCraft, and we
>>> would like to figure out some way to allow qemu to directly consume our
>>> image-based backups. It would provide us with user-space mounting (via
>>> libguestfs) as well as booting VMs directly from Backup images. We already
>>> have a proprietary image access library that provides block-wise access to
>>> our image files. I have been able to scratch together a proof of concept
>>> already, which I am really pleased with.
>>>
>>> I see only two roadblocks for which I don't have immediate answers for.
>>>
>>> 1) Licensing
>>> Is it possible to license our contributions in such a way that we do not need
>>> to open the source code of our image access library?
>>
>> This is not possible if you want to link your image access library statically.
>>
>> QEMU uses GPL v2. You can use a patched QEMU internally,
>> but as soon as you want to give it to customers (or get it integrated
>> in the official source tree), you must publish all code which is needed
>> under an open license.
>>
>> If your image access library is a shared library (linked at runtime),
>> the situation is more difficult. The intention of the GPL is still
>> that you have to publish your code (this is also what the FSF says),
>> but there are different opinions for GPL v2. See
>> http://en.wikipedia.org/wiki/GNU_General_Public_License for
>> more information.
>>
>> I personally don't like the idea of QEMU supporting closed source
>> shared libraries.
>>
>>> 2) External dependency on our image access library.
>>> We do not want to force qemu to require our image access library to be
>>> present to build. Would it be better to do a conditional build (./configure
>>> --with-spf) or a run-time check for our image access library?
>>
>> You'll need the conditional build for those people who don't want support
>> for your image type.
>>
>> Regards,
>>
>> Stefan Weil
>
>
> I forgot to mention a possible solution: instead of using your image access library
> (which is closed source), you could write new access code (maybe with reduced
> functionality) and publish that code under an open source license.

If the "image access library" is solely for use in a proprietary system, I would 
be opposed to merging it.

The only real work around here is to make use of open standard like iSCSI (which 
is already supported natively by QEMU).

Regards,

Anthony Liguori

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 03/01/2012 02:05 PM, Anthony Liguori wrote:
> On 03/01/2012 02:18 PM, Stefan Weil wrote:
>> Am 01.03.2012 21:10, schrieb Stefan Weil:
>>> Am 01.03.2012 20:45, schrieb Kai Meyer:
>>>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>>>> Is it possible to extend qemu to support a new image type? I have an
>>>>>> image type that is ready for consumption and I'm looking for the
>>>>>> integration point between qemu and the new image format.
>>>>> Which image format do you want to get integrated?
>>>>>
>>>>> Have a look at block/qcow2.c to get an idea of what a qemu block 
>>>>> driver
>>>>> looks like. At the bottom of the file there is a struct that contains
>>>>> function pointers to all exported functions, so this is usually a 
>>>>> good
>>>>> place to start exploring a driver.
>>>>>
>>>>> Kevin
>>>>
>>>> Great, this is exactly what we're after. I work for StorageCraft, 
>>>> and we
>>>> would like to figure out some way to allow qemu to directly consume 
>>>> our
>>>> image-based backups. It would provide us with user-space mounting (via
>>>> libguestfs) as well as booting VMs directly from Backup images. We 
>>>> already
>>>> have a proprietary image access library that provides block-wise 
>>>> access to
>>>> our image files. I have been able to scratch together a proof of 
>>>> concept
>>>> already, which I am really pleased with.
>>>>
>>>> I see only two roadblocks for which I don't have immediate answers 
>>>> for.
>>>>
>>>> 1) Licensing
>>>> Is it possible to license our contributions in such a way that we 
>>>> do not need
>>>> to open the source code of our image access library?
>>>
>>> This is not possible if you want to link your image access library 
>>> statically.
>>>
>>> QEMU uses GPL v2. You can use a patched QEMU internally,
>>> but as soon as you want to give it to customers (or get it integrated
>>> in the official source tree), you must publish all code which is needed
>>> under an open license.
>>>
>>> If your image access library is a shared library (linked at runtime),
>>> the situation is more difficult. The intention of the GPL is still
>>> that you have to publish your code (this is also what the FSF says),
>>> but there are different opinions for GPL v2. See
>>> http://en.wikipedia.org/wiki/GNU_General_Public_License for
>>> more information.
>>>
>>> I personally don't like the idea of QEMU supporting closed source
>>> shared libraries.
>>>
>>>> 2) External dependency on our image access library.
>>>> We do not want to force qemu to require our image access library to be
>>>> present to build. Would it be better to do a conditional build 
>>>> (./configure
>>>> --with-spf) or a run-time check for our image access library?
>>>
>>> You'll need the conditional build for those people who don't want 
>>> support
>>> for your image type.
>>>
>>> Regards,
>>>
>>> Stefan Weil
>>
>>
>> I forgot to mention a possible solution: instead of using your image 
>> access library
>> (which is closed source), you could write new access code (maybe with 
>> reduced
>> functionality) and publish that code under an open source license.
>
> If the "image access library" is solely for use in a proprietary 
> system, I would be opposed to merging it.
>
> The only real work around here is to make use of open standard like 
> iSCSI (which is already supported natively by QEMU).
>
> Regards,
>
> Anthony Liguori
Ok, pushing support upstream for our image format is looking unlikely, 
which is understandable. I'll hold off on doing more work then until I 
can hear from our legal department on whether or not we could distribute 
a modified version of qemu with out requiring publication of our 
proprietary source code. If we can't use qemu in general use-cases 
(since we can't push support for our images up stream), we could still 
really benefit from a targeted use-cases (like a Rescue Environment.)

However, I should say I'm very pleased with how simple (code wise) it 
was to add support for the image format to qemu.

-Kai Meyer

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 01/03/2012 22:14, Kai Meyer ha scritto:
> If we can't use qemu in general use-cases (since we can't push support
> for our images up stream), we could still really benefit from a targeted
> use-cases (like a Rescue Environment.)

It does not matter whether it is upstream or not.

When you distribute your modified QEMU binary, anyone who receives it
has the right to ask you for the complete corresponding source code.

I also suggest that you write a wrapper around your library that exports
the contents as iSCSI or NBD.

Paolo

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

________________________________________
From: Paolo Bonzini [pbonzini@redhat.com]
Sent: Thursday, March 01, 2012 11:54 PM
To: Kai Meyer
Cc: Anthony Liguori; Stefan Weil; qemu-devel@nongnu.org; Nate Bushman
Subject: Re: Add support for new image type

Il 01/03/2012 22:14, Kai Meyer ha scritto:
> If we can't use qemu in general use-cases (since we can't push support
> for our images up stream), we could still really benefit from a targeted
> use-cases (like a Rescue Environment.)

It does not matter whether it is upstream or not.

When you distribute your modified QEMU binary, anyone who receives it
has the right to ask you for the complete corresponding source code.

I also suggest that you write a wrapper around your library that exports
the contents as iSCSI or NBD.

Paolo


Well, yes. I was assuming that there was potential for us to be able to distribute qemu modifications that would not require us opening up our library. The more we look at it, and some past precedence we've experienced, it looks like it's not going to happen.

I think I agree that iSCSI is really our only option (legally). Too bad. The code was so simple to integrate directly into qemu. I have to give you guys kudos again for already having such a simple integration point.

-Kai Meyer

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 02/03/2012 19:38, Kai Meyer ha scritto:
> Well, yes. I was assuming that there was potential for us to be able
> to distribute qemu modifications that would not require us opening up
> our library. The more we look at it, and some past precedence we've
> experienced, it looks like it's not going to happen.
> 
> I think I agree that iSCSI is really our only option (legally). Too
> bad. The code was so simple to integrate directly into qemu. I have
> to give you guys kudos again for already having such a simple
> integration point.

Adding a small, open source version of the image access code would be
another possibility; you probably have a public spec of the format, and
including support for your format in a QEMU block driver doesn't change
much.  Who knows, it may even bring cheap advertising. :)

QEMU has several entry points for the block driver, and the once with
lower performance are extremely easy to implement (see block/bochs.c).
In theory it could even be read-only, though we would have problems
testing it and this may mean bitrot.

Paolo

Re: [Qemu-devel] Add support for new image type

[Stefan Hajnoczi]

On Fri, Mar 2, 2012 at 6:38 PM, Kai Meyer <kai.meyer@storagecraft.com> wrote:
>
> ________________________________________
> From: Paolo Bonzini [pbonzini@redhat.com]
> Sent: Thursday, March 01, 2012 11:54 PM
> To: Kai Meyer
> Cc: Anthony Liguori; Stefan Weil; qemu-devel@nongnu.org; Nate Bushman
> Subject: Re: Add support for new image type
>
> Il 01/03/2012 22:14, Kai Meyer ha scritto:
>> If we can't use qemu in general use-cases (since we can't push support
>> for our images up stream), we could still really benefit from a targeted
>> use-cases (like a Rescue Environment.)
>
> It does not matter whether it is upstream or not.
>
> When you distribute your modified QEMU binary, anyone who receives it
> has the right to ask you for the complete corresponding source code.
>
> I also suggest that you write a wrapper around your library that exports
> the contents as iSCSI or NBD.
>
> Paolo
>
>
> Well, yes. I was assuming that there was potential for us to be able to distribute qemu modifications that would not require us opening up our library. The more we look at it, and some past precedence we've experienced, it looks like it's not going to happen.
>
> I think I agree that iSCSI is really our only option (legally). Too bad. The code was so simple to integrate directly into qemu. I have to give you guys kudos again for already having such a simple integration point.

If iSCSI is too much effort, I suggest looking at NBD which Paolo
mentioned earlier.  It's a small and simple protocol and QEMU already
has the "glue code" to speak it.  In other words, you would write an
NBD server that understands your image format and QEMU would use its
existing block/nbd.c driver to talk to it over a standard protocol.
That even opens the possibility of attaching the image file as a Linux
block device using the nbd driver in Linux.

Stefan

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 03/01/2012 11:54 PM, Paolo Bonzini wrote:
>
> It does not matter whether it is upstream or not.
>
> When you distribute your modified QEMU binary, anyone who receives it
> has the right to ask you for the complete corresponding source code.
>
> I also suggest that you write a wrapper around your library that exports
> the contents as iSCSI or NBD.
>
> Paolo
I simply can't get over how simple it was to integrate our closed-source 
block-wise access library with qemu, or how many uses there are from 
other projects like libguestfs that would automatically gain support for 
our format. Since we last spoke, we've been working on iSCSI, but I've 
also received some conflicting interpretations on the GPL. As I learn 
more about the GPL, it is clear that the intent is to help the owners 
retain as many rights as they choose to retain. In the spirit of 
pleasing the owners of qemu, I'd like to ask two questions. We are not 
interested in playing in legal "grey" areas, so unless there is a clear 
"sure go for it" answer, we're only too happy to comply with your wishes.

1) It's been suggested to me that since we have the rights to distribute 
our closed source shared library, there is a precedence for being able 
to distributed a modified version of qemu that does run-time linking 
against our shared library. The absence or presence of our shared 
library simply enables or disables support for our file format. We are 
happy to make available all changes to the qemu source code, but we are 
not in a position to re-license our shared library's source code to a 
compatible GPL license. This seems to be in contradiction to Paolo's 
statement above, so while I can't resist asking if this is possible, I 
don't have any realistic expectation that this is acceptable.

2) The GPL has provisions for you to create an exception where you have 
specified a controlled interface. Am I right that qemu has not added 
this controlled interface exception for file format access? What are 
your thoughts on adding this exception if it is not present? I would 
think that "struct BlockDriver" would make an excellent candidate for this.

On a personal note, I am an open source enthusiast, so the last thing I 
would want to do is to help alienate the relationship between qemu and 
storagecraft. I'm not asking these questions to look for a legal corner 
to worm my way into, but because I love open source software, and I want 
to learn how to play nicely. (Plus there's that virtualization 
"coolness" factor to this solution that I can't resist.)

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 16/05/2012 19:06, Kai Meyer ha scritto:
> 1) It's been suggested to me that since we have the rights to distribute
> our closed source shared library, there is a precedence for being able
> to distributed a modified version of qemu that does run-time linking
> against our shared library. The absence or presence of our shared
> library simply enables or disables support for our file format. We are
> happy to make available all changes to the qemu source code, but we are
> not in a position to re-license our shared library's source code to a
> compatible GPL license. This seems to be in contradiction to Paolo's
> statement above, so while I can't resist asking if this is possible, I
> don't have any realistic expectation that this is acceptable.

That's really getting into grey areas.  IANAL, so I cannot answer this
question.

But as an aside, the GPL _does_ give you rights to distribute any
modification you make to QEMU.  The right questions to ask are:

1) a practical question: would the QEMU community accept that
contribution?  The answer here is "most likely not".

2) a legal question (i.e. the question that a court would answer): what
are the rights of the _recipients_ of your version (and especially of
the copyright holders of QEMU)?  Do they have rights to ask you for the
source code to the shared library, and to receive it under the GPL?
Again I cannot answer here (and I couldn't even if I were a lawyer).

(Remember that however what we proposed was not just relicensing your
library source code, but alternatively to rewrite it from scratch with
no particular attention to performance.  That would be a completely
different story, probably also for your lawyers.  You could also share
any internal spec you have and hire someone to write the QEMU interface
for you, basically a form of clean-room reverse engineering).

> 2) The GPL has provisions for you to create an exception where you have
> specified a controlled interface. Am I right that qemu has not added
> this controlled interface exception for file format access? What are
> your thoughts on adding this exception if it is not present? I would
> think that "struct BlockDriver" would make an excellent candidate for this.

This would have to be applied to all files (not just block/*.c say) and
agreed upon by all QEMU copyright holders.  The second condition is
quite obvious, the first I'll spend a few more words on.

The first condition is because the code overall can be distributed as
long as it fulfills all existing licenses.  QEMU right now has files
under BSD, GPLv2, GPLv2-or-later, LGPLv2.1-or-later and perhaps some
more licenses.  You can take code from individual files (or complete
files) and reuse it under the license indicated in the header of that
file.  However, you can only distribute QEMU as a whole under the
intersection of those licenses, which is GPLv2.  If you add another
license to the mix ("GPL+controlled interface") for block/*.c, QEMU as a
whole could still only be distributed under GPLv2.

> On a personal note, I am an open source enthusiast, so the last thing I
> would want to do is to help alienate the relationship between qemu and
> storagecraft. I'm not asking these questions to look for a legal corner
> to worm my way into, but because I love open source software, and I want
> to learn how to play nicely. (Plus there's that virtualization
> "coolness" factor to this solution that I can't resist.)

Sure, personally I appreciate your honesty even though I disagree with
your goal. :)

Paolo

Re: [Qemu-devel] Add support for new image type

[Anthony Liguori]

On 05/16/2012 12:48 PM, Paolo Bonzini wrote:
> Il 16/05/2012 19:06, Kai Meyer ha scritto:
>> 1) It's been suggested to me that since we have the rights to distribute
>> our closed source shared library, there is a precedence for being able
>> to distributed a modified version of qemu that does run-time linking
>> against our shared library. The absence or presence of our shared
>> library simply enables or disables support for our file format. We are
>> happy to make available all changes to the qemu source code, but we are
>> not in a position to re-license our shared library's source code to a
>> compatible GPL license. This seems to be in contradiction to Paolo's
>> statement above, so while I can't resist asking if this is possible, I
>> don't have any realistic expectation that this is acceptable.
>
> That's really getting into grey areas.  IANAL, so I cannot answer this
> question.

It's not morally grey though.  The GPL is designed to attempt to prohibit this 
and as a copyright holder in QEMU, I choose[1] to use the GPL specifically to 
prevent this.

QEMU only exists because people have contributed back their improvements to the 
project.  Not contributing back means that you are only taking from the 
community withing returning anything back.  Only your lawyer can tell you 
whether this is legal or not, but it's certainly unkind.

[1] I == Anthony Liguori, not IBM.  I began my involvement in QEMU long before 
IBM paid me to be.

Regards,

Anthony Liguori

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 05/16/2012 12:21 PM, Anthony Liguori wrote:
> On 05/16/2012 12:48 PM, Paolo Bonzini wrote:
>> Il 16/05/2012 19:06, Kai Meyer ha scritto:
>>> 1) It's been suggested to me that since we have the rights to 
>>> distribute
>>> our closed source shared library, there is a precedence for being able
>>> to distributed a modified version of qemu that does run-time linking
>>> against our shared library. The absence or presence of our shared
>>> library simply enables or disables support for our file format. We are
>>> happy to make available all changes to the qemu source code, but we are
>>> not in a position to re-license our shared library's source code to a
>>> compatible GPL license. This seems to be in contradiction to Paolo's
>>> statement above, so while I can't resist asking if this is possible, I
>>> don't have any realistic expectation that this is acceptable.
>>
>> That's really getting into grey areas.  IANAL, so I cannot answer this
>> question.
>
> It's not morally grey though.  The GPL is designed to attempt to 
> prohibit this and as a copyright holder in QEMU, I choose[1] to use 
> the GPL specifically to prevent this.
>
> QEMU only exists because people have contributed back their 
> improvements to the project.  Not contributing back means that you are 
> only taking from the community withing returning anything back.  Only 
> your lawyer can tell you whether this is legal or not, but it's 
> certainly unkind.
>
> [1] I == Anthony Liguori, not IBM.  I began my involvement in QEMU 
> long before IBM paid me to be.
>
> Regards,
>
> Anthony Liguori
Even though it makes it clear that I will not be able to have the tight 
integration with QEMU that I would like, I appreciate learning that you 
are a copyright holder, and intended to use the GPL to prevent what I'm 
trying to do. StorageCraft is new to Linux, and I am a fairly young 
software engineer, so our interaction with GPL software is fairly low. 
This has been very insightful and instructive.

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 05/16/2012 11:48 AM, Paolo Bonzini wrote:
> Il 16/05/2012 19:06, Kai Meyer ha scritto:
>> 1) It's been suggested to me that since we have the rights to distribute
>> our closed source shared library, there is a precedence for being able
>> to distributed a modified version of qemu that does run-time linking
>> against our shared library. The absence or presence of our shared
>> library simply enables or disables support for our file format. We are
>> happy to make available all changes to the qemu source code, but we are
>> not in a position to re-license our shared library's source code to a
>> compatible GPL license. This seems to be in contradiction to Paolo's
>> statement above, so while I can't resist asking if this is possible, I
>> don't have any realistic expectation that this is acceptable.
> That's really getting into grey areas.  IANAL, so I cannot answer this
> question.
>
> But as an aside, the GPL _does_ give you rights to distribute any
> modification you make to QEMU.  The right questions to ask are:
>
> 1) a practical question: would the QEMU community accept that
> contribution?  The answer here is "most likely not".
>
> 2) a legal question (i.e. the question that a court would answer): what
> are the rights of the _recipients_ of your version (and especially of
> the copyright holders of QEMU)?  Do they have rights to ask you for the
> source code to the shared library, and to receive it under the GPL?
> Again I cannot answer here (and I couldn't even if I were a lawyer).
>
> (Remember that however what we proposed was not just relicensing your
> library source code, but alternatively to rewrite it from scratch with
> no particular attention to performance.  That would be a completely
> different story, probably also for your lawyers.  You could also share
> any internal spec you have and hire someone to write the QEMU interface
> for you, basically a form of clean-room reverse engineering).
>
>> 2) The GPL has provisions for you to create an exception where you have
>> specified a controlled interface. Am I right that qemu has not added
>> this controlled interface exception for file format access? What are
>> your thoughts on adding this exception if it is not present? I would
>> think that "struct BlockDriver" would make an excellent candidate for this.
> This would have to be applied to all files (not just block/*.c say) and
> agreed upon by all QEMU copyright holders.  The second condition is
> quite obvious, the first I'll spend a few more words on.
>
> The first condition is because the code overall can be distributed as
> long as it fulfills all existing licenses.  QEMU right now has files
> under BSD, GPLv2, GPLv2-or-later, LGPLv2.1-or-later and perhaps some
> more licenses.  You can take code from individual files (or complete
> files) and reuse it under the license indicated in the header of that
> file.  However, you can only distribute QEMU as a whole under the
> intersection of those licenses, which is GPLv2.  If you add another
> license to the mix ("GPL+controlled interface") for block/*.c, QEMU as a
> whole could still only be distributed under GPLv2.
>
>> On a personal note, I am an open source enthusiast, so the last thing I
>> would want to do is to help alienate the relationship between qemu and
>> storagecraft. I'm not asking these questions to look for a legal corner
>> to worm my way into, but because I love open source software, and I want
>> to learn how to play nicely. (Plus there's that virtualization
>> "coolness" factor to this solution that I can't resist.)
> Sure, personally I appreciate your honesty even though I disagree with
> your goal. :)
>
> Paolo
I want to respect the lines that the GPL draws, and this helps clarify 
for me where some of those lines are. To help me better understand, what 
would be the terminology used for the explanation between what I would 
call "source code" licensing, and "project" licensing? Also, where in 
the code (or rather what file) can I see this distinction? It seems like 
something critical to be aware of, and I'd like to avoid missing 
something like this in the future as I give advice on what software we 
can use.

Thanks for being patient with me.

If you would help clarify a separate point, I would be grateful. As I 
understand it, I am able to modify qemu for my own purposes (like 
testing the filesystem integrity inside a backup image by using 
guestmount to mount it). How much of that work (source code, principles, 
explanations, ect) can I share, and with whom can I share it with? For 
instance, would qemu be opposed to a StorageCraft wiki article on "How 
to add support for our Backup Images to qemu"? And would it make a 
difference if it was a publicly accessible wiki vs a private wiki? I am 
interested in respecting the spirit and purpose of the GPL license for 
the qemu project. The header file for our image library is open, and we 
encourage our customers to do interesting things with the library. It is 
unfortunate for this project (and any other GPL project we may 
encounter) that the library itself can't be opened.

-Kai Meyer

Re: [Qemu-devel] Add support for new image type

[Artyom Tarasenko]

On Wed, May 16, 2012 at 9:20 PM, Kai Meyer <kai.meyer@storagecraft.com> wrote:
> On 05/16/2012 11:48 AM, Paolo Bonzini wrote:
>>
>> Il 16/05/2012 19:06, Kai Meyer ha scritto:
>>>
>>> 1) It's been suggested to me that since we have the rights to distribute
>>> our closed source shared library, there is a precedence for being able
>>> to distributed a modified version of qemu that does run-time linking
>>> against our shared library. The absence or presence of our shared
>>> library simply enables or disables support for our file format. We are
>>> happy to make available all changes to the qemu source code, but we are
>>> not in a position to re-license our shared library's source code to a
>>> compatible GPL license. This seems to be in contradiction to Paolo's
>>> statement above, so while I can't resist asking if this is possible, I
>>> don't have any realistic expectation that this is acceptable.
>>
>> That's really getting into grey areas.  IANAL, so I cannot answer this
>> question.
>>
>> But as an aside, the GPL _does_ give you rights to distribute any
>> modification you make to QEMU.  The right questions to ask are:
>>
>> 1) a practical question: would the QEMU community accept that
>> contribution?  The answer here is "most likely not".
>>
>> 2) a legal question (i.e. the question that a court would answer): what
>> are the rights of the _recipients_ of your version (and especially of
>> the copyright holders of QEMU)?  Do they have rights to ask you for the
>> source code to the shared library, and to receive it under the GPL?
>> Again I cannot answer here (and I couldn't even if I were a lawyer).
>>
>> (Remember that however what we proposed was not just relicensing your
>> library source code, but alternatively to rewrite it from scratch with
>> no particular attention to performance.  That would be a completely
>> different story, probably also for your lawyers.  You could also share
>> any internal spec you have and hire someone to write the QEMU interface
>> for you, basically a form of clean-room reverse engineering).
>>
>>> 2) The GPL has provisions for you to create an exception where you have
>>> specified a controlled interface. Am I right that qemu has not added
>>> this controlled interface exception for file format access? What are
>>> your thoughts on adding this exception if it is not present? I would
>>> think that "struct BlockDriver" would make an excellent candidate for
>>> this.
>>
>> This would have to be applied to all files (not just block/*.c say) and
>> agreed upon by all QEMU copyright holders.  The second condition is
>> quite obvious, the first I'll spend a few more words on.
>>
>> The first condition is because the code overall can be distributed as
>> long as it fulfills all existing licenses.  QEMU right now has files
>> under BSD, GPLv2, GPLv2-or-later, LGPLv2.1-or-later and perhaps some
>> more licenses.  You can take code from individual files (or complete
>> files) and reuse it under the license indicated in the header of that
>> file.  However, you can only distribute QEMU as a whole under the
>> intersection of those licenses, which is GPLv2.  If you add another
>> license to the mix ("GPL+controlled interface") for block/*.c, QEMU as a
>> whole could still only be distributed under GPLv2.
>>
>>> On a personal note, I am an open source enthusiast, so the last thing I
>>> would want to do is to help alienate the relationship between qemu and
>>> storagecraft. I'm not asking these questions to look for a legal corner
>>> to worm my way into, but because I love open source software, and I want
>>> to learn how to play nicely. (Plus there's that virtualization
>>> "coolness" factor to this solution that I can't resist.)
>>
>> Sure, personally I appreciate your honesty even though I disagree with
>> your goal. :)
>>
>> Paolo
>
> I want to respect the lines that the GPL draws, and this helps clarify for
> me where some of those lines are. To help me better understand, what would
> be the terminology used for the explanation between what I would call
> "source code" licensing, and "project" licensing? Also, where in the code
> (or rather what file) can I see this distinction? It seems like something
> critical to be aware of, and I'd like to avoid missing something like this
> in the future as I give advice on what software we can use.
>
> Thanks for being patient with me.
>
> If you would help clarify a separate point, I would be grateful. As I
> understand it, I am able to modify qemu for my own purposes (like testing
> the filesystem integrity inside a backup image by using guestmount to mount
> it). How much of that work (source code, principles, explanations, ect) can
> I share, and with whom can I share it with?

With source code that's easy - if you  distribute qemu you have to
distribute its source code.

> For instance, would qemu be
> opposed to a StorageCraft wiki article on "How to add support for our Backup
> Images to qemu"? And would it make a difference if it was a publicly
> accessible wiki vs a private wiki?

With wiki documentation which is not derived from other sources (like
QEMU wiki or QEMU itself) you can do whatever you like.

> I am interested in respecting the spirit
> and purpose of the GPL license for the qemu project. The header file for our
> image library is open, and we encourage our customers to do interesting
> things with the library. It is unfortunate for this project (and any other
> GPL project we may encounter) that the library itself can't be opened.

IANAL but I think you can have 3 more options:

- you can take an older qemu version. Prior to to release 1.0 qemu
claimed to have LGPL 2 license.
LGPL would allow linking qemu with your library. There is one caveat
though: I don't know how legal this
LGPL label was, because also back at that time there were files under GPL.
On the other hand there was a already a precedence of using a
proprietary library, called FMOD.

- you probably can distribute your library and instructions how to
incorporate it in qemu. Then you are not violating GPL,
but your customers would be: the modified version is not
distributable. Check this with your lawyer.

- the cleanest way. You can fork qemu and remove all GPL code. The
heart of qemu - TCG is licensed under BSD license. A lot of code is
licensed under BSD and LGPL, so maybe if you don't need the whole
functionality of qemu, you can live with the BSD/LGPL subset. Who
knows, you even may find people interested in non-GPL version of qemu.
For example in FreeBSD community, they are trying to build a GNU-less
system.


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 17/05/2012 11:10, Artyom Tarasenko ha scritto:
> To help me better understand, what would
>> be the terminology used for the explanation between what I would call
>> "source code" licensing, and "project" licensing? Also, where in the code
>> (or rather what file) can I see this distinction? It seems like something
>> critical to be aware of, and I'd like to avoid missing something like this
>> in the future as I give advice on what software we can use.

Roughly speaking, each file has its own license.  So you can take for
example vl.c or tcg/* and use it in a proprietary program, because those
are under a non-copyleft license.  You cannot do the same for
event_notifier.c, because it is released under GPLv2 or later.

For the project to be distributable at all, there has to be a license
that is compatible with all the others: such a license has to allow all
restrictions imposed by the other licenses used in the project, and all
other licenses have to allow all restrictions imposed by such a license.
 For QEMU this license is the GPLv2.

>> If you would help clarify a separate point, I would be grateful. As I
>> understand it, I am able to modify qemu for my own purposes (like testing
>> the filesystem integrity inside a backup image by using guestmount to mount
>> it). How much of that work (source code, principles, explanations, ect) can
>> I share, and with whom can I share it with?

Principles, explanations can be shared with whoever you want, however
you want.  Patches are more of a grey area and I suggest you consult a
(good) lawyer.

Remember that the GPL only becomes relevant once you start distributing
code.  As long as you share the changes within your company for example
you are safe.  Here is what the GPL FAQ says:

   Is making and using multiple copies within one organization or
   company “distribution”? (#InternalDistribution)

   No, in that case the organization is just making the copies for
   itself. As a consequence, a company or other organization can
   develop a modified version and install that version through its own
   facilities, without giving the staff permission to release that
   modified version to outsiders.

   However, when the organization transfers copies to other
   organizations or individuals, that is distribution. In particular,
   providing copies to contractors for use off-site is distribution.

What you suggested with run-time linking sounds like you are adding a
functionality that is totally useless to the general public.  Those
people who are able to combine it with the shared library could use it
as in the above answer without distributing the result.

Morally it's wrong, but a copyright holder cannot stop you on moral
grounds.  Legally, you should consult a lawyer.  Practically:

- if you go with iSCSI or something like that you would provide the same
functionality to your customers, keep clear from legal grey areas, and
the QEMU community probably could not care less.

- if you go with a clean reimplementation under the GPL you would
provide the same functionality to your customers, keep clear from legal
grey areas, contribute to QEMU positively, and perhaps get some
advertising for your product.

Paolo

Re: [Qemu-devel] Add support for new image type

[Artyom Tarasenko]

On Thu, May 17, 2012 at 11:41 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> To help me better understand, what would
>>> be the terminology used for the explanation between what I would call
>>> "source code" licensing, and "project" licensing? Also, where in the code
>>> (or rather what file) can I see this distinction? It seems like something
>>> critical to be aware of, and I'd like to avoid missing something like this
>>> in the future as I give advice on what software we can use.
>
> Roughly speaking, each file has its own license.  So you can take for
> example vl.c or tcg/* and use it in a proprietary program, because those
> are under a non-copyleft license.  You cannot do the same for
> event_notifier.c, because it is released under GPLv2 or later.
>
> For the project to be distributable at all, there has to be a license
> that is compatible with all the others: such a license has to allow all
> restrictions imposed by the other licenses used in the project, and all
> other licenses have to allow all restrictions imposed by such a license.
>  For QEMU this license is the GPLv2.

Strictly speaking it must be GPLv2 with exceptions/restrictions. The code
can not be moved freely between GPL and BSD licensed files.
Why the GPL->BSD move is illegal is obvious.
The BSD->GPL move is not allowed because of the :

" * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software."

clause of the BSD license.

So the result of GPL and BSD intersection must be GPL with some files
licensed under BSD.

>>> If you would help clarify a separate point, I would be grateful. As I
>>> understand it, I am able to modify qemu for my own purposes (like testing
>>> the filesystem integrity inside a backup image by using guestmount to mount
>>> it). How much of that work (source code, principles, explanations, ect) can
>>> I share, and with whom can I share it with?
>
> Principles, explanations can be shared with whoever you want, however
> you want.  Patches are more of a grey area and I suggest you consult a
> (good) lawyer.
>
> Remember that the GPL only becomes relevant once you start distributing
> code.  As long as you share the changes within your company for example
> you are safe.  Here is what the GPL FAQ says:
>
>   Is making and using multiple copies within one organization or
>   company “distribution”? (#InternalDistribution)
>
>   No, in that case the organization is just making the copies for
>   itself. As a consequence, a company or other organization can
>   develop a modified version and install that version through its own
>   facilities, without giving the staff permission to release that
>   modified version to outsiders.
>
>   However, when the organization transfers copies to other
>   organizations or individuals, that is distribution. In particular,
>   providing copies to contractors for use off-site is distribution.
>
> What you suggested with run-time linking sounds like you are adding a
> functionality that is totally useless to the general public.  Those
> people who are able to combine it with the shared library could use it
> as in the above answer without distributing the result.
>
> Morally it's wrong, but a copyright holder cannot stop you on moral
> grounds.  Legally, you should consult a lawyer.  Practically:
>
> - if you go with iSCSI or something like that you would provide the same
> functionality to your customers, keep clear from legal grey areas, and
> the QEMU community probably could not care less.
>
> - if you go with a clean reimplementation under the GPL you would
> provide the same functionality to your customers, keep clear from legal
> grey areas, contribute to QEMU positively, and perhaps get some
> advertising for your product.
>
> Paolo



-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 05/17/2012 03:41 AM, Paolo Bonzini wrote:
> Il 17/05/2012 11:10, Artyom Tarasenko ha scritto:
>> To help me better understand, what would
>>> be the terminology used for the explanation between what I would call
>>> "source code" licensing, and "project" licensing? Also, where in the code
>>> (or rather what file) can I see this distinction? It seems like something
>>> critical to be aware of, and I'd like to avoid missing something like this
>>> in the future as I give advice on what software we can use.
> Roughly speaking, each file has its own license.  So you can take for
> example vl.c or tcg/* and use it in a proprietary program, because those
> are under a non-copyleft license.  You cannot do the same for
> event_notifier.c, because it is released under GPLv2 or later.
>
> For the project to be distributable at all, there has to be a license
> that is compatible with all the others: such a license has to allow all
> restrictions imposed by the other licenses used in the project, and all
> other licenses have to allow all restrictions imposed by such a license.
>   For QEMU this license is the GPLv2.
>
>>> If you would help clarify a separate point, I would be grateful. As I
>>> understand it, I am able to modify qemu for my own purposes (like testing
>>> the filesystem integrity inside a backup image by using guestmount to mount
>>> it). How much of that work (source code, principles, explanations, ect) can
>>> I share, and with whom can I share it with?
> Principles, explanations can be shared with whoever you want, however
> you want.  Patches are more of a grey area and I suggest you consult a
> (good) lawyer.
>
> Remember that the GPL only becomes relevant once you start distributing
> code.  As long as you share the changes within your company for example
> you are safe.  Here is what the GPL FAQ says:
>
>     Is making and using multiple copies within one organization or
>     company “distribution”? (#InternalDistribution)
>
>     No, in that case the organization is just making the copies for
>     itself. As a consequence, a company or other organization can
>     develop a modified version and install that version through its own
>     facilities, without giving the staff permission to release that
>     modified version to outsiders.
>
>     However, when the organization transfers copies to other
>     organizations or individuals, that is distribution. In particular,
>     providing copies to contractors for use off-site is distribution.
This is nice because it greatly simplifies some test cases for me as a 
developer.
> What you suggested with run-time linking sounds like you are adding a
> functionality that is totally useless to the general public.  Those
> people who are able to combine it with the shared library could use it
> as in the above answer without distributing the result.
>
This is very accurate. Unless you are already a StorageCraft customer, 
there is really no practical reason to have this functionality. The 
image format is intended to be write-once, so we can benefit from a 
sequential write. Deltas to the base image are stored in incremental 
chains, which are also individually write-once. We have support for 
creating new incremental images in various cases where modifying the 
filesystem represented by the image chain is required (like P2V), but 
it's not meant to run for extended periods of time. In cases where one 
would want to run a Virtual Machine from a backup image, we would use 
the image file as a read-only media backing store, and have qemu use a 
separate (ie: qcow2) backing file for writes. This is essentially what 
we do with our current VirtualBoot product that is based on VirtualBox. 
(Personally, I'm just a much bigger fan of libvirt + qemu-kvm than I am 
of VirtualBox for "enterprise" or "server class" solutions).
> Morally it's wrong, but a copyright holder cannot stop you on moral
> grounds.  Legally, you should consult a lawyer.  Practically:
What you say is morally wrong here is a bit ambiguous to me. Do you mean 
using modified versions of qemu internally at StorageCraft is morally 
wrong? Or do you mean that a run-time linking version would not be in 
violation of the GPL legally, but it would be morally wrong? It is 
important to us to morally interact with GPL projects and code.
> - if you go with iSCSI or something like that you would provide the same
> functionality to your customers, keep clear from legal grey areas, and
> the QEMU community probably could not care less.
There are many reasons outside of the scope of the qemu project that 
iSCSI is a good solution for us. As far as the intersection with the 
things I would use qemu for, iSCSI is overly complicated and requires a 
non-trivial understanding of how iSCSI works in order to point qemu at 
the result, for both the developers and the users. Unfortunately not all 
Linux distributions have rebased their qemu packages to a version where 
iscsi support has been added, but when they do it will help alleviate 
some of this problem.
> - if you go with a clean reimplementation under the GPL you would
> provide the same functionality to your customers, keep clear from legal
> grey areas, contribute to QEMU positively, and perhaps get some
> advertising for your product.
>
> Paolo
I think just plain iSCSI is a more appropriate solution for our needs, 
as interesting as this sounds :).

Again, thanks for the clarity on these issues. It's definitely a 
learning curve for many of us.

-Kai Meyer

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 17/05/2012 19:53, Kai Meyer ha scritto:
>> Morally it's wrong, but a copyright holder cannot stop you on
>> moral grounds.  Legally, you should consult a lawyer.
> What you say is morally wrong here is a bit ambiguous to me. Do you
> mean using modified versions of qemu internally at StorageCraft is
> morally wrong?

No, it's fine.  Internally you can do whatever you want.

> Or do you mean that a run-time linking version would not be in 
> violation of the GPL legally, but it would be morally wrong?

I cannot answer about the legal part; it's possible that it's legal but
anyway you should listen to a lawyer's opinion and not mine.

Anthony explained that, at least for him, it would be morally wrong.
Other people's mileage may vary.

Paolo

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 05/17/2012 01:43 PM, Paolo Bonzini wrote:
> Il 17/05/2012 19:53, Kai Meyer ha scritto:
>>> Morally it's wrong, but a copyright holder cannot stop you on
>>> moral grounds.  Legally, you should consult a lawyer.
>> What you say is morally wrong here is a bit ambiguous to me. Do you
>> mean using modified versions of qemu internally at StorageCraft is
>> morally wrong?
> No, it's fine.  Internally you can do whatever you want.
>
>> Or do you mean that a run-time linking version would not be in
>> violation of the GPL legally, but it would be morally wrong?
> I cannot answer about the legal part; it's possible that it's legal but
> anyway you should listen to a lawyer's opinion and not mine.
>
> Anthony explained that, at least for him, it would be morally wrong.
> Other people's mileage may vary.
>
> Paolo
It's enough for us that prominent members of the qemu community 
(particularly copyright holders) consider it immoral. We'll simply avoid 
it entirely.

I think this will wrap things up for us quite nicely. Thanks again for 
all your help and patience.

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

On 03/01/2012 01:10 PM, Stefan Weil wrote:
> Am 01.03.2012 20:45, schrieb Kai Meyer:
>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>> Is it possible to extend qemu to support a new image type? I have an
>>>> image type that is ready for consumption and I'm looking for the
>>>> integration point between qemu and the new image format.
>>> Which image format do you want to get integrated?
>>>
>>> Have a look at block/qcow2.c to get an idea of what a qemu block driver
>>> looks like. At the bottom of the file there is a struct that contains
>>> function pointers to all exported functions, so this is usually a good
>>> place to start exploring a driver.
>>>
>>> Kevin
>>
>> Great, this is exactly what we're after. I work for StorageCraft, and 
>> we would like to figure out some way to allow qemu to directly 
>> consume our image-based backups. It would provide us with user-space 
>> mounting (via libguestfs) as well as booting VMs directly from Backup 
>> images. We already have a proprietary image access library that 
>> provides block-wise access to our image files. I have been able to 
>> scratch together a proof of concept already, which I am really 
>> pleased with.
>>
>> I see only two roadblocks for which I don't have immediate answers for.
>>
>> 1) Licensing
>> Is it possible to license our contributions in such a way that we do 
>> not need to open the source code of our image access library?
>
> This is not possible if you want to link your image access library 
> statically.
>
> QEMU uses GPL v2. You can use a patched QEMU internally,
> but as soon as you want to give it to customers (or get it integrated
> in the official source tree), you must publish all code which is needed
> under an open license.
It is a shared library.
>
> If your image access library is a shared library (linked at runtime),
> the situation is more difficult. The intention of the GPL is still
> that you have to publish your code (this is also what the FSF says),
> but there are different opinions for GPL v2. See
> http://en.wikipedia.org/wiki/GNU_General_Public_License for
> more information.
My primary concern right now is if it is a reasonable course of action. 
I will eventually rely on our internal processes to determine how to 
remain in compliance with exiting licenses.
http://wiki.qemu.org/License
Portions of qemu (ie the qed block driver) are licensed under the LGPL. 
Can you help me understand the impact of licensing our contributions 
under the LGPL instead of GPL?
>
> I personally don't like the idea of QEMU supporting closed source
> shared libraries.
I'm sorry to hear that, however you are being very helpful, so I 
appreciate that.
>
>> 2) External dependency on our image access library.
>> We do not want to force qemu to require our image access library to 
>> be present to build. Would it be better to do a conditional build 
>> (./configure --with-spf) or a run-time check for our image access 
>> library?
>
> You'll need the conditional build for those people who don't want support
In addition to the conditional build, would it be appropriate (more 
easily accepted) if there was a run-time check for the existence of the 
library instead of at compile time? This would allow us to enable image 
access on existing systems (that are up to date) instead of requiring 
separate maintenance of qemu versions (ie: hosting our own distribution 
of qemu packages for different platforms, or requiring a rebuild on 
every system.)
> for your image type.
>
> Regards,
>
> Stefan Weil
>
>
>
Thanks!

-Kai Meyer

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 01/03/2012 21:26, Kai Meyer ha scritto:
>> QEMU uses GPL v2. You can use a patched QEMU internally,
>> but as soon as you want to give it to customers (or get it integrated
>> in the official source tree), you must publish all code which is needed
>> under an open license.
>
> It is a shared library.
>
>> If your image access library is a shared library (linked at runtime),
>> the situation is more difficult. The intention of the GPL is still
>> that you have to publish your code (this is also what the FSF says),
>> but there are different opinions for GPL v2.

There aren't really different opinions.  Some people *tolerate*
proprietary plugins, but strictly speaking that should be done with a
specific exception to the GPL.  It is not "some people think it's legal,
some people don't".  It is more like "some people don't care, some
people do".

> http://wiki.qemu.org/License
> Portions of qemu (ie the qed block driver) are licensed under the LGPL.
> Can you help me understand the impact of licensing our contributions
> under the LGPL instead of GPL?

No.  The LGPL parts are separate, but when you distribute the
combination you still have to honor _all_ the licenses at the same time.
 In practice this means the most restrictive license, which is the GPL.

Paolo

Re: [Qemu-devel] Add support for new image type

[Stefan Weil]

Am 01.03.2012 21:26, schrieb Kai Meyer:
> On 03/01/2012 01:10 PM, Stefan Weil wrote:
>> Am 01.03.2012 20:45, schrieb Kai Meyer:
>>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>>> Is it possible to extend qemu to support a new image type? I have an
>>>>> image type that is ready for consumption and I'm looking for the
>>>>> integration point between qemu and the new image format.
>>>> Which image format do you want to get integrated?
>>>>
>>>> Have a look at block/qcow2.c to get an idea of what a qemu block 
>>>> driver
>>>> looks like. At the bottom of the file there is a struct that contains
>>>> function pointers to all exported functions, so this is usually a good
>>>> place to start exploring a driver.
>>>>
>>>> Kevin
>>>
>>> Great, this is exactly what we're after. I work for StorageCraft, 
>>> and we would like to figure out some way to allow qemu to directly 
>>> consume our image-based backups. It would provide us with user-space 
>>> mounting (via libguestfs) as well as booting VMs directly from 
>>> Backup images. We already have a proprietary image access library 
>>> that provides block-wise access to our image files. I have been able 
>>> to scratch together a proof of concept already, which I am really 
>>> pleased with.
>>>
>>> I see only two roadblocks for which I don't have immediate answers for.
>>>
>>> 1) Licensing
>>> Is it possible to license our contributions in such a way that we do 
>>> not need to open the source code of our image access library?
>>
>> This is not possible if you want to link your image access library 
>> statically.
>>
>> QEMU uses GPL v2. You can use a patched QEMU internally,
>> but as soon as you want to give it to customers (or get it integrated
>> in the official source tree), you must publish all code which is needed
>> under an open license.
> It is a shared library.
>>
>> If your image access library is a shared library (linked at runtime),
>> the situation is more difficult. The intention of the GPL is still
>> that you have to publish your code (this is also what the FSF says),
>> but there are different opinions for GPL v2. See
>> http://en.wikipedia.org/wiki/GNU_General_Public_License for
>> more information.
> My primary concern right now is if it is a reasonable course of 
> action. I will eventually rely on our internal processes to determine 
> how to remain in compliance with exiting licenses.
> http://wiki.qemu.org/License
> Portions of qemu (ie the qed block driver) are licensed under the 
> LGPL. Can you help me understand the impact of licensing our 
> contributions under the LGPL instead of GPL?

If you use the LGPL for your contributions, you grant other people more 
rights
than they would have with the GPL (which I think is not what you want).

Using GPL for your image access library does _not_ imply that you cannot 
use it
in other closed source projects! You are the copyright owner, so you may do
anything you want with your library, even when you grant others the right to
use it under GPL.

Regards,
Stefan Weil

Re: [Qemu-devel] Add support for new image type

[Anthony Liguori]

On 03/01/2012 01:45 PM, Kai Meyer wrote:
> Great, this is exactly what we're after. I work for StorageCraft, and we would
> like to figure out some way to allow qemu to directly consume our image-based
> backups. It would provide us with user-space mounting (via libguestfs) as well
> as booting VMs directly from Backup images. We already have a proprietary image
> access library that provides block-wise access to our image files. I have been
> able to scratch together a proof of concept already, which I am really pleased
> with.
>
> I see only two roadblocks for which I don't have immediate answers for.
>
> 1) Licensing
> Is it possible to license our contributions in such a way that we do not need to
> open the source code of our image access library?

Hi,

Obviously, you should ask your legal department for advice on licensing, but as 
a policy of the QEMU project, it's unlikely we would accept anything that's sole 
purpose was to enable third party proprietary code regardless of license 
compatibility.  QEMU is an Open Source project and our past and future success 
depends on the collaboration and innovation that comes from having an open code 
base.

Regards,

Anthony Liguori

Re: [Qemu-devel] Add support for new image type

[Kevin Wolf]

(Sorry, missed the rest of this thread as I was expecting to be kept in
the CC list)

Am 01.03.2012 20:45, schrieb Kai Meyer:
> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>> Is it possible to extend qemu to support a new image type? I have an
>>> image type that is ready for consumption and I'm looking for the
>>> integration point between qemu and the new image format.
>> Which image format do you want to get integrated?
>>
>> Have a look at block/qcow2.c to get an idea of what a qemu block driver
>> looks like. At the bottom of the file there is a struct that contains
>> function pointers to all exported functions, so this is usually a good
>> place to start exploring a driver.
>>
>> Kevin
> 
> Great, this is exactly what we're after. I work for StorageCraft, and we 
> would like to figure out some way to allow qemu to directly consume our 
> image-based backups. It would provide us with user-space mounting (via 
> libguestfs) as well as booting VMs directly from Backup images. We 
> already have a proprietary image access library that provides block-wise 
> access to our image files. I have been able to scratch together a proof 
> of concept already, which I am really pleased with.
> 
> I see only two roadblocks for which I don't have immediate answers for.
> 
> 1) Licensing
> Is it possible to license our contributions in such a way that we do not 
> need to open the source code of our image access library?

As other people already said, there's no way that we would accept this.

However, what do you really gain from keeping your file format secret? I
can't imagine that the information required for a (possibly read-only)
properly licensed block driver contains anything of what makes the core
of your products. I can understand that you want to keep sophisticated
source code closed, but I really can't for file formats.

So if you tried to get permission to publish a specification of your
image format and wrote a minimal qemu block driver from scratch, I
believe this would be best for everyone.

> 2) External dependency on our image access library.
> We do not want to force qemu to require our image access library to be 
> present to build. Would it be better to do a conditional build 
> (./configure --with-spf) or a run-time check for our image access library?

A conditional build would be required and I'd consider a run-time check
optional.

Kevin

Re: [Qemu-devel] Add support for new image type

[Nate Bushman]

You make really good points on opening up the image file format.  I see real value there in that it would foster development of other solutions around that format.  The problem in this case is that StorageCraft's backup image format uses proprietary compression and encryption, and so, regrettably, we can't (currently) open up that code.  This is an interesting lesson in retrospect.  We could possibly publish a spec of the format when encryption and compression aren't used, but in practice this doesn't happen (compression speeds up the backups because the CPU time it takes to compress is far less than the time saved by writing the smaller amount of compressed data to the disk), so because compression saves both time and space nearly all of our customers use the compression options at a minimum, and many also use the encryption.

Interesting and educational discussion.  Thanks for your help Kevin!

Nate

-----Original Message-----
From: Kevin Wolf [mailto:kwolf@redhat.com] 
Sent: Thursday, March 08, 2012 8:18 AM
To: Kai Meyer
Cc: qemu-devel@nongnu.org; Nate Bushman
Subject: Re: [Qemu-devel] Add support for new image type

(Sorry, missed the rest of this thread as I was expecting to be kept in the CC list)

Am 01.03.2012 20:45, schrieb Kai Meyer:
> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>> Is it possible to extend qemu to support a new image type? I have an 
>>> image type that is ready for consumption and I'm looking for the 
>>> integration point between qemu and the new image format.
>> Which image format do you want to get integrated?
>>
>> Have a look at block/qcow2.c to get an idea of what a qemu block 
>> driver looks like. At the bottom of the file there is a struct that 
>> contains function pointers to all exported functions, so this is 
>> usually a good place to start exploring a driver.
>>
>> Kevin
> 
> Great, this is exactly what we're after. I work for StorageCraft, and 
> we would like to figure out some way to allow qemu to directly consume 
> our image-based backups. It would provide us with user-space mounting 
> (via
> libguestfs) as well as booting VMs directly from Backup images. We 
> already have a proprietary image access library that provides 
> block-wise access to our image files. I have been able to scratch 
> together a proof of concept already, which I am really pleased with.
> 
> I see only two roadblocks for which I don't have immediate answers for.
> 
> 1) Licensing
> Is it possible to license our contributions in such a way that we do 
> not need to open the source code of our image access library?

As other people already said, there's no way that we would accept this.

However, what do you really gain from keeping your file format secret? I can't imagine that the information required for a (possibly read-only) properly licensed block driver contains anything of what makes the core of your products. I can understand that you want to keep sophisticated source code closed, but I really can't for file formats.

So if you tried to get permission to publish a specification of your image format and wrote a minimal qemu block driver from scratch, I believe this would be best for everyone.

> 2) External dependency on our image access library.
> We do not want to force qemu to require our image access library to be 
> present to build. Would it be better to do a conditional build 
> (./configure --with-spf) or a run-time check for our image access library?

A conditional build would be required and I'd consider a run-time check optional.

Kevin

Re: [Qemu-devel] Add support for new image type

[Kevin Wolf]

Am 08.03.2012 18:16, schrieb Nate Bushman:
> You make really good points on opening up the image file format.  I see real value there in that it would foster development of other solutions around that format.  The problem in this case is that StorageCraft's backup image format uses proprietary compression and encryption, and so, regrettably, we can't (currently) open up that code. 

This is an interesting statement. Not so much for compression, for which
I can't know how much better your solution is than common algorithms.
But I always thought that closed encryption algorithms have to be
considered bad, because using them would mean relying on security by
obscurity. Which probably everyone agrees is a bad idea.

> This is an interesting lesson in retrospect.  We could possibly publish a spec of the format when encryption and compression aren't used, but in practice this doesn't happen (compression speeds up the backups because the CPU time it takes to compress is far less than the time saved by writing the smaller amount of compressed data to the disk), so because compression saves both time and space nearly all of our customers use the compression options at a minimum, and many also use the encryption.

I see. Though it probably depends on your use case for qemu with these
images. If you create an image specifically for use with qemu, it could
make sense to use uncompressed images (or possibly even introduce
another zlib-compressed mode or something). On the other hand, if qemu
was to be used to work with already existing images, it wouldn't help.

Kevin

> -----Original Message-----
> From: Kevin Wolf [mailto:kwolf@redhat.com] 
> Sent: Thursday, March 08, 2012 8:18 AM
> To: Kai Meyer
> Cc: qemu-devel@nongnu.org; Nate Bushman
> Subject: Re: [Qemu-devel] Add support for new image type
> 
> (Sorry, missed the rest of this thread as I was expecting to be kept in the CC list)
> 
> Am 01.03.2012 20:45, schrieb Kai Meyer:
>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>> Is it possible to extend qemu to support a new image type? I have an 
>>>> image type that is ready for consumption and I'm looking for the 
>>>> integration point between qemu and the new image format.
>>> Which image format do you want to get integrated?
>>>
>>> Have a look at block/qcow2.c to get an idea of what a qemu block 
>>> driver looks like. At the bottom of the file there is a struct that 
>>> contains function pointers to all exported functions, so this is 
>>> usually a good place to start exploring a driver.
>>>
>>> Kevin
>>
>> Great, this is exactly what we're after. I work for StorageCraft, and 
>> we would like to figure out some way to allow qemu to directly consume 
>> our image-based backups. It would provide us with user-space mounting 
>> (via
>> libguestfs) as well as booting VMs directly from Backup images. We 
>> already have a proprietary image access library that provides 
>> block-wise access to our image files. I have been able to scratch 
>> together a proof of concept already, which I am really pleased with.
>>
>> I see only two roadblocks for which I don't have immediate answers for.
>>
>> 1) Licensing
>> Is it possible to license our contributions in such a way that we do 
>> not need to open the source code of our image access library?
> 
> As other people already said, there's no way that we would accept this.
> 
> However, what do you really gain from keeping your file format secret? I can't imagine that the information required for a (possibly read-only) properly licensed block driver contains anything of what makes the core of your products. I can understand that you want to keep sophisticated source code closed, but I really can't for file formats.
> 
> So if you tried to get permission to publish a specification of your image format and wrote a minimal qemu block driver from scratch, I believe this would be best for everyone.
> 
>> 2) External dependency on our image access library.
>> We do not want to force qemu to require our image access library to be 
>> present to build. Would it be better to do a conditional build 
>> (./configure --with-spf) or a run-time check for our image access library?
> 
> A conditional build would be required and I'd consider a run-time check optional.
> 
> Kevin

Re: [Qemu-devel] Add support for new image type

[Paolo Bonzini]

Il 09/03/2012 10:23, Kevin Wolf ha scritto:
>> You make really good points on opening up the image file format.
>> I see real value there in that it would foster development of
>> other solutions around that format.  The problem in this case is
>> that StorageCraft's backup image format uses proprietary
>> compression and encryption, and so, regrettably, we can't
>> (currently) open up that code.
>
> This is an interesting statement. Not so much for compression, for
> which I can't know how much better your solution is than common
> algorithms. But I always thought that closed encryption algorithms
> have to be considered bad, because using them would mean relying on
> security by obscurity. Which probably everyone agrees is a bad idea.

And even for compression, having an open decompressor is usually a good
idea.  Some people have no problems with proprietary solutions but do
not like lock in (and wonder what to do with their backups if
StorageCraft disappears).

Paolo

Re: [Qemu-devel] Add support for new image type

[Kevin Wolf]

Am 09.03.2012 11:28, schrieb Paolo Bonzini:
> Il 09/03/2012 10:23, Kevin Wolf ha scritto:
>>> You make really good points on opening up the image file format.
>>> I see real value there in that it would foster development of
>>> other solutions around that format.  The problem in this case is
>>> that StorageCraft's backup image format uses proprietary
>>> compression and encryption, and so, regrettably, we can't
>>> (currently) open up that code.
>>
>> This is an interesting statement. Not so much for compression, for
>> which I can't know how much better your solution is than common
>> algorithms. But I always thought that closed encryption algorithms
>> have to be considered bad, because using them would mean relying on
>> security by obscurity. Which probably everyone agrees is a bad idea.
> 
> And even for compression, having an open decompressor is usually a good
> idea.  Some people have no problems with proprietary solutions but do
> not like lock in (and wonder what to do with their backups if
> StorageCraft disappears).

The lock-in you already get with uncompressed images, but yes, it's a
problem with this file format that would make me avoid it.

Kevin

Re: [Qemu-devel] Add support for new image type

[Nate Bushman]

If storagecraft disappears the customers still have the existing tools, which can, for instance, convert their backup images to vhd or VMDK, so I think this is probably not an issue. 

Sent from a phone

On Mar 9, 2012, at 3:28 AM, "Paolo Bonzini" <pbonzini@redhat.com> wrote:

> Il 09/03/2012 10:23, Kevin Wolf ha scritto:
>>> You make really good points on opening up the image file format.
>>> I see real value there in that it would foster development of
>>> other solutions around that format.  The problem in this case is
>>> that StorageCraft's backup image format uses proprietary
>>> compression and encryption, and so, regrettably, we can't
>>> (currently) open up that code.
>> 
>> This is an interesting statement. Not so much for compression, for
>> which I can't know how much better your solution is than common
>> algorithms. But I always thought that closed encryption algorithms
>> have to be considered bad, because using them would mean relying on
>> security by obscurity. Which probably everyone agrees is a bad idea.
> 
> And even for compression, having an open decompressor is usually a good
> idea.  Some people have no problems with proprietary solutions but do
> not like lock in (and wonder what to do with their backups if
> StorageCraft disappears).
> 
> Paolo

Re: [Qemu-devel] Add support for new image type

[Nate Bushman]

The encryption is speed-optimized AES256. The compression is proprietary, as is common for backup image files, however in hindsight I agree with you. I too would prefer for it to all be open. It's possible we maybe able to make such a shift. Thanks for your thoughts and suggestions. 

Sent from a phone

On Mar 9, 2012, at 2:19 AM, "Kevin Wolf" <kwolf@redhat.com> wrote:

> Am 08.03.2012 18:16, schrieb Nate Bushman:
>> You make really good points on opening up the image file format.  I see real value there in that it would foster development of other solutions around that format.  The problem in this case is that StorageCraft's backup image format uses proprietary compression and encryption, and so, regrettably, we can't (currently) open up that code. 
> 
> This is an interesting statement. Not so much for compression, for which
> I can't know how much better your solution is than common algorithms.
> But I always thought that closed encryption algorithms have to be
> considered bad, because using them would mean relying on security by
> obscurity. Which probably everyone agrees is a bad idea.
> 
>> This is an interesting lesson in retrospect.  We could possibly publish a spec of the format when encryption and compression aren't used, but in practice this doesn't happen (compression speeds up the backups because the CPU time it takes to compress is far less than the time saved by writing the smaller amount of compressed data to the disk), so because compression saves both time and space nearly all of our customers use the compression options at a minimum, and many also use the encryption.
> 
> I see. Though it probably depends on your use case for qemu with these
> images. If you create an image specifically for use with qemu, it could
> make sense to use uncompressed images (or possibly even introduce
> another zlib-compressed mode or something). On the other hand, if qemu
> was to be used to work with already existing images, it wouldn't help.
> 
> Kevin
> 
>> -----Original Message-----
>> From: Kevin Wolf [mailto:kwolf@redhat.com] 
>> Sent: Thursday, March 08, 2012 8:18 AM
>> To: Kai Meyer
>> Cc: qemu-devel@nongnu.org; Nate Bushman
>> Subject: Re: [Qemu-devel] Add support for new image type
>> 
>> (Sorry, missed the rest of this thread as I was expecting to be kept in the CC list)
>> 
>> Am 01.03.2012 20:45, schrieb Kai Meyer:
>>> On 03/01/2012 08:03 AM, Kevin Wolf wrote:
>>>> Am 29.02.2012 22:52, schrieb Kai Meyer:
>>>>> Is it possible to extend qemu to support a new image type? I have an 
>>>>> image type that is ready for consumption and I'm looking for the 
>>>>> integration point between qemu and the new image format.
>>>> Which image format do you want to get integrated?
>>>> 
>>>> Have a look at block/qcow2.c to get an idea of what a qemu block 
>>>> driver looks like. At the bottom of the file there is a struct that 
>>>> contains function pointers to all exported functions, so this is 
>>>> usually a good place to start exploring a driver.
>>>> 
>>>> Kevin
>>> 
>>> Great, this is exactly what we're after. I work for StorageCraft, and 
>>> we would like to figure out some way to allow qemu to directly consume 
>>> our image-based backups. It would provide us with user-space mounting 
>>> (via
>>> libguestfs) as well as booting VMs directly from Backup images. We 
>>> already have a proprietary image access library that provides 
>>> block-wise access to our image files. I have been able to scratch 
>>> together a proof of concept already, which I am really pleased with.
>>> 
>>> I see only two roadblocks for which I don't have immediate answers for.
>>> 
>>> 1) Licensing
>>> Is it possible to license our contributions in such a way that we do 
>>> not need to open the source code of our image access library?
>> 
>> As other people already said, there's no way that we would accept this.
>> 
>> However, what do you really gain from keeping your file format secret? I can't imagine that the information required for a (possibly read-only) properly licensed block driver contains anything of what makes the core of your products. I can understand that you want to keep sophisticated source code closed, but I really can't for file formats.
>> 
>> So if you tried to get permission to publish a specification of your image format and wrote a minimal qemu block driver from scratch, I believe this would be best for everyone.
>> 
>>> 2) External dependency on our image access library.
>>> We do not want to force qemu to require our image access library to be 
>>> present to build. Would it be better to do a conditional build 
>>> (./configure --with-spf) or a run-time check for our image access library?
>> 
>> A conditional build would be required and I'd consider a run-time check optional.
>> 
>> Kevin
>