From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQgMJ-0005l5-I9 for qemu-devel@nongnu.org; Wed, 16 Nov 2011 09:21:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQgMF-0006DT-1C for qemu-devel@nongnu.org; Wed, 16 Nov 2011 09:21:03 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:64549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQgME-0006DE-Ut for qemu-devel@nongnu.org; Wed, 16 Nov 2011 09:20:58 -0500 Received: by ggnr4 with SMTP id r4so3262955ggn.4 for ; Wed, 16 Nov 2011 06:20:57 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4EC3C6C3.1020208@redhat.com> Date: Wed, 16 Nov 2011 15:20:51 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4EC3BC67.6030005@codemonkey.ws> <4EC3BD12.9000508@redhat.com> <4EC3BDCC.3050102@codemonkey.ws> In-Reply-To: <4EC3BDCC.3050102@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converging around a single guest agent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ghammer@redhat.com, vdsm-devel-TuqUDEhatI7GMZAyRF5v151Ccm5ICvs9@public.gmane.org, Dor Laor , qemu-devel , arch-dEQiMlfYlSzYtjvyW6yDsg@public.gmane.org On 11/16/2011 02:42 PM, Anthony Liguori wrote: > On 11/16/2011 07:39 AM, Dor Laor wrote: >> On 11/16/2011 03:36 PM, Anthony Liguori wrote: >>> We have another requirement. We need to embed the source for the guest >>> agent in the QEMU release tarball. This is for GPL compliance since we >>> want to include an ISO (eventually) that contains binaries. >>> >>> This could be as simple as doing a git submodule but it would mean that >>> the guest agent would have to live in its own git repository. Do you all >>> see a problem with this? >> >> Not that I object of placing the code within qemu but I doubt this is a >> requirement, we can settle w/ GPL license for the code. >> >> A requirement of having the agent code reside within qemu is similar to some >> neighbors idea about kvm-tool and the kernel ... > > It can just be a submodule (like we do with SeaBIOS, etc.). The only request is > that we split guest agent out of vdsm so we don't have to also include all of > vdsm in the release tarballs. That would make the guest agent an independent > git repository and presumably project. It is already (git://gerrit.ovirt.org/ovirt-guest-agent). Barak, is there a gitweb/cgit instance? > We can't ship a binary without including the source in the release. The way we > handle this for things that are external to QEMU (SeaBIOS, OpenBIOS, etc.) are > git submodules. ovirt-guest-agent is licensed under GPLv3, so you do not need to; the options in GPLv3 include this one: d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. Of course having a separate repo, and mirroring to qemu.org both remain nice things to have. Paolo