Re: [Qemu-devel] converging around a single guest agent

[Paolo Bonzini]

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