From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM call agenda for 2013-05-28 Date: Fri, 31 May 2013 10:43:46 -0500 Message-ID: <87mwrbqhn1.fsf@codemonkey.ws> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <51A88D73.1090302@redhat.com> <87bo7rmhbp.fsf@codemonkey.ws> <1370009305.5141.95.camel@i7.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Laszlo Ersek , Jordan Justen , Kevin O'Connor , Juan Quintela , KVM devel mailing list , qemu-devel qemu-devel , seabios@seabios.org, ddutile@redhat.com, "Michael S. Tsirkin" To: David Woodhouse Return-path: Received: from mail-qa0-f54.google.com ([209.85.216.54]:47230 "EHLO mail-qa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751746Ab3EaPnu convert rfc822-to-8bit (ORCPT ); Fri, 31 May 2013 11:43:50 -0400 Received: by mail-qa0-f54.google.com with SMTP id hu16so570211qab.6 for ; Fri, 31 May 2013 08:43:49 -0700 (PDT) In-Reply-To: <1370009305.5141.95.camel@i7.infradead.org> Sender: kvm-owner@vger.kernel.org List-ID: David Woodhouse writes: > On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote: >>=20 >> >>=20 >> Fork OVMF, drop the fat module, and just add GPL code. It's an easi= ly >> solvable problem. > > Heh. Actually it doesn't need to be a fork. It's modular, and the FAT > driver is just a single module. Which is actually included in *binary= * > form in the EDK2 repository, I believe, and its source code is > elsewhere. > > We could happily make a GPL=C2=B9 or LGPL implementation of a FAT mod= ule and > build our OVMF with that instead, and we wouldn't need to fork OVMF a= t > all. So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module. I would propose more of a virtual fork. It could consist of a git repo= with the GPL modules + a submodule for edk2. Ideally, there would be no nee= d to actually fork edk2. My assumption is that edk2 won't take GPL code. But does ovmf really need to live in the edk2 tree? If we're going to get serious about supporting OVMF, it we need something that isn't proprietary. > --=20 > dwmw2 > > =C2=B9 If it's GPL, of course, then we mustn't include any *other* bi= nary > blobs in our OVMF build. But the whole point in this conversation is > that we don't *want* to do that. So that's fine. It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. Without even tackling the issue of GPL code sharing, that is a fundamental problem that needs to be solved if we're going to serious about making changes to QEMU to support it. I think solving the general problem will also enable GPL code sharing though. Regards, Anthony Liguori From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiRUd-0006tR-4z for qemu-devel@nongnu.org; Fri, 31 May 2013 11:43:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiRUb-00074b-Oz for qemu-devel@nongnu.org; Fri, 31 May 2013 11:43:51 -0400 Received: from mail-qc0-x233.google.com ([2607:f8b0:400d:c01::233]:53337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiRUb-00074X-KL for qemu-devel@nongnu.org; Fri, 31 May 2013 11:43:49 -0400 Received: by mail-qc0-f179.google.com with SMTP id e1so918020qcx.10 for ; Fri, 31 May 2013 08:43:49 -0700 (PDT) From: Anthony Liguori In-Reply-To: <1370009305.5141.95.camel@i7.infradead.org> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <51A88D73.1090302@redhat.com> <87bo7rmhbp.fsf@codemonkey.ws> <1370009305.5141.95.camel@i7.infradead.org> Date: Fri, 31 May 2013 10:43:46 -0500 Message-ID: <87mwrbqhn1.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Woodhouse Cc: "Michael S. Tsirkin" , KVM devel mailing list , Juan Quintela , Laszlo Ersek , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , ddutile@redhat.com, Jordan Justen David Woodhouse writes: > On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote: >>=20 >> >>=20 >> Fork OVMF, drop the fat module, and just add GPL code. It's an easily >> solvable problem. > > Heh. Actually it doesn't need to be a fork. It's modular, and the FAT > driver is just a single module. Which is actually included in *binary* > form in the EDK2 repository, I believe, and its source code is > elsewhere. > > We could happily make a GPL=C2=B9 or LGPL implementation of a FAT module = and > build our OVMF with that instead, and we wouldn't need to fork OVMF at > all. So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module. I would propose more of a virtual fork. It could consist of a git repo with the GPL modules + a submodule for edk2. Ideally, there would be no need to actually fork edk2. My assumption is that edk2 won't take GPL code. But does ovmf really need to live in the edk2 tree? If we're going to get serious about supporting OVMF, it we need something that isn't proprietary. > --=20 > dwmw2 > > =C2=B9 If it's GPL, of course, then we mustn't include any *other* binary > blobs in our OVMF build. But the whole point in this conversation is > that we don't *want* to do that. So that's fine. It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. Without even tackling the issue of GPL code sharing, that is a fundamental problem that needs to be solved if we're going to serious about making changes to QEMU to support it. I think solving the general problem will also enable GPL code sharing though. Regards, Anthony Liguori