[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kai Meyer
Subject: Re: [Qemu-devel] Add support for new image type
Date: Thu, 17 May 2012 11:53:04 -0600

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]