From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV4sy-0005Jx-2E for qemu-devel@nongnu.org; Thu, 17 May 2012 13:53:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SV4sw-0006Dq-5w for qemu-devel@nongnu.org; Thu, 17 May 2012 13:53:11 -0400 Received: from webmail.storagecraft.com ([199.101.231.144]:33302 helo=STC-EXCH.stc.local) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV4sv-0006DO-UP for qemu-devel@nongnu.org; Thu, 17 May 2012 13:53:10 -0400 Message-ID: <4FB53B00.1090402@storagecraft.com> Date: Thu, 17 May 2012 11:53:04 -0600 From: Kai Meyer MIME-Version: 1.0 References: <4F4E9E31.50903@storagecraft.com> <4F4F8FCD.7010106@redhat.com> <4F4FD1C9.8050006@storagecraft.com> <4F4FD7C7.7030001@mail.berlios.de> <4F4FD9A6.9060308@mail.berlios.de> <4F4FE4AA.20902@codemonkey.ws> <4F4FE6C6.1070302@storagecraft.com> <4F506E92.9080902@redhat.com> <4FB3DE79.9090504@storagecraft.com> <4FB3E86B.7020206@redhat.com> <4FB3FE16.3000608@storagecraft.com> <4FB4C7D8.4010609@redhat.com> In-Reply-To: <4FB4C7D8.4010609@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Add support for new image type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Stefan Weil , qemu-devel@nongnu.org, Artyom Tarasenko , Nate Bushman 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 co= de >>> (or rather what file) can I see this distinction? It seems like somethi= ng >>> critical to be aware of, and I'd like to avoid missing something like t= his >>> 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 testi= ng >>> the filesystem integrity inside a backup image by using guestmount to m= ount >>> 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 =93distribution=94? (#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=20 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,=20 there is really no practical reason to have this functionality. The=20 image format is intended to be write-once, so we can benefit from a=20 sequential write. Deltas to the base image are stored in incremental=20 chains, which are also individually write-once. We have support for=20 creating new incremental images in various cases where modifying the=20 filesystem represented by the image chain is required (like P2V), but=20 it's not meant to run for extended periods of time. In cases where one=20 would want to run a Virtual Machine from a backup image, we would use=20 the image file as a read-only media backing store, and have qemu use a=20 separate (ie: qcow2) backing file for writes. This is essentially what=20 we do with our current VirtualBoot product that is based on VirtualBox.=20 (Personally, I'm just a much bigger fan of libvirt + qemu-kvm than I am=20 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=20 using modified versions of qemu internally at StorageCraft is morally=20 wrong? Or do you mean that a run-time linking version would not be in=20 violation of the GPL legally, but it would be morally wrong? It is=20 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=20 iSCSI is a good solution for us. As far as the intersection with the=20 things I would use qemu for, iSCSI is overly complicated and requires a=20 non-trivial understanding of how iSCSI works in order to point qemu at=20 the result, for both the developers and the users. Unfortunately not all=20 Linux distributions have rebased their qemu packages to a version where=20 iscsi support has been added, but when they do it will help alleviate=20 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,=20 as interesting as this sounds :). Again, thanks for the clarity on these issues. It's definitely a=20 learning curve for many of us. -Kai Meyer