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
> 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
> 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.
vdsm-devel mailing list