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

[Artyom Tarasenko]

On Wed, May 16, 2012 at 9:20 PM, Kai Meyer kai.me...@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 

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

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

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

[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

[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 kw...@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:kw...@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

[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 pbonz...@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

[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:kw...@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

[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:kw...@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 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.me...@storagecraft.com wrote:

 
 From: Paolo Bonzini [pbonz...@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]

From: Paolo Bonzini [pbonz...@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

[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: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

[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

[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

[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

[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.me...@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/