From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiQpu-00038S-2A for qemu-devel@nongnu.org; Fri, 31 May 2013 11:01:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiQpr-0002O6-FG for qemu-devel@nongnu.org; Fri, 31 May 2013 11:01:45 -0400 Received: from mail-qa0-x232.google.com ([2607:f8b0:400d:c00::232]:37824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiQTu-0003Jf-2C for qemu-devel@nongnu.org; Fri, 31 May 2013 10:39:02 -0400 Received: by mail-qa0-f50.google.com with SMTP id ci6so528410qab.2 for ; Fri, 31 May 2013 07:39:01 -0700 (PDT) From: Anthony Liguori In-Reply-To: <51A8AD52.3070901@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <51A88D73.1090302@redhat.com> <87bo7rmhbp.fsf@codemonkey.ws> <51A8AD52.3070901@redhat.com> Date: Fri, 31 May 2013 09:38:58 -0500 Message-ID: <87k3mfxlh9.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: Laszlo Ersek Cc: "Michael S. Tsirkin" , KVM devel mailing list , Juan Quintela , David Woodhouse , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , ddutile@redhat.com, Jordan Justen Laszlo Ersek writes: > On 05/31/13 15:04, Anthony Liguori wrote: >> Laszlo Ersek writes: >>=20 >>> On 05/31/13 09:09, Jordan Justen wrote: >>> >>> Due to licensing differences I can't just port code from SeaBIOS to >>> OVMF >>=20 >> > > :) > >> Fork OVMF, drop the fat module, and just add GPL code. It's an easily >> solvable problem. > > It's not optimal for the "upstream first" principle; OVMF is not Open Source so "upstream first" doesn't apply. At least, the FAT module is not Open Source. Bullet 8 from the Open Source Definition[1] "8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution." License from OVMF FAT module[2]: "Additional terms: In addition to the forgoing, redistribution and use of the code is conditioned upon the FAT 32 File System Driver and all derivative works thereof being used for and designed only to read and/or write to a file system that is directly managed by: Intel=E2=80=99s Extensi= ble Firmware Initiative (EFI) Specification v. 1.0 and later and/or the Unified Extensible Firmware Interface (UEFI) Forum=E2=80=99s UEFI Specifica= tions v.2.0 and later (together the =E2=80=9CUEFI Specifications=E2=80=9D); only = as necessary to emulate an implementation of the UEFI Specifications; and to create firmware, applications, utilities and/or drivers." [1] http://opensource.org/osd-annotated [2] http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=3DEdk2-= fat-driver AFAIK, for the systems that we'd actually want to use OVMF for, a FAT module is a hard requirement. > we'd have to > backport upstream edk2 patches forever (there's a whole lot of edk2 > modules outside of direct OvmfPkg that get built into OVMF.fd -- OvmfPkg > "only" customizes / cherry-picks the full edk2 tree for virtual > machines), or to periodically rebase an ever-increasing set of patches. > > Independently, we need *some* FAT driver (otherwise you can't even boot > most installer media), which is where the already discussed worries lie. > Whatever solves this aspect is independent of forking all of edk2. It's either Open Source or it's not. It's currently not. I have a hard time sympathesizing with trying to work with a proprietary upstream. >> Rewriting BSD implementations of everything is silly. Every other >> vendor that uses TianoCore has a proprietary fork. > > Correct, but they (presumably) keep rebasing their ever accumulating > stuff at least on the periodically refreshed "stable edk2 subset" > (UDK2010, which BTW doesn't include OvmfPkg). This must be horrible for > them, but in exchange they get to remain proprietary (which may benefit > them commercially). > >> Maintaining a GPL >> fork seems just as reasonable. > > Perhaps; diverging from "upstream first" would hurt for certain. Well I'm suggesting creating a real upstream (that is actually Open Source). Then I'm all for upstream first. In terms of creating a FAT module, the most likely source would seem to be the kernel code and since that's GPL, I don't think it's terribly avoidable to end up with a GPL'd uefi implementation. If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license. Regards, Anthony Liguori > >> > > Thanks for the suggestion :) > Laszlo