qemu-devel
[Top][All Lists]
Advanced

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

Re: Why we should avoid new submodules if possible


From: Thomas Huth
Subject: Re: Why we should avoid new submodules if possible
Date: Fri, 1 Jul 2022 05:34:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

On 29/06/2022 08.28, Ani Sinha wrote:
On Tue, Jun 28, 2022 at 11:30 PM Michael S. Tsirkin <mst@redhat.com> wrote:

On Tue, Jun 28, 2022 at 05:15:05PM +0100, Daniel P. Berrangé wrote:
FYI, the reason much of this is intentionally NOT under the /qemu-project
gitlab namespace is that we did not want to be responsible for distributing
arbitrary binary blobs/images. That in turn makes the QEMU project responsible
for license compliance, which is non-trivial todo correctly for much of this
stuff. As such it is highly desirable to delegate both the hosting the
binaries and source to the third party who builds it.

This might be understadable for random guest OS images which include tons of 
stuff
and are thus hard to audit.  But not to biosbits which has its own
license (more or less bsd) + gpl for grub:
https://github.com/biosbits/bits/blob/master/COPYING

These are all the dependencies:
https://github.com/biosbits/bits/tree/master/deps

We can go through the licenses for each and make a determination. The
audit would be lost easier because there is a bounded number of
dependencies for bits.

That's quite a bit of dependencies already ... I don't think that we should put the burden of keeping up with the licenses of those projects to the QEMU project. So just make sure that the binaries are available somewhere and then include your test into the avocado framework or download via curl/wget as suggested in other mails.

 Thomas




reply via email to

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