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