From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWnma-000896-IS for qemu-devel@nongnu.org; Mon, 29 Apr 2013 09:06:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWnmY-0007li-Vn for qemu-devel@nongnu.org; Mon, 29 Apr 2013 09:06:16 -0400 Received: from mail-ob0-x235.google.com ([2607:f8b0:4003:c01::235]:40973) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWnmY-0007lQ-Pn for qemu-devel@nongnu.org; Mon, 29 Apr 2013 09:06:14 -0400 Received: by mail-ob0-f181.google.com with SMTP id ta17so5310724obb.40 for ; Mon, 29 Apr 2013 06:06:13 -0700 (PDT) From: Anthony Liguori In-Reply-To: References: Date: Mon, 29 Apr 2013 08:04:32 -0500 Message-ID: <87y5c1mqsf.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] SoftFloat licensing in Linux kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Stefan Hajnoczi Cc: qemu-devel Peter Maydell writes: > On 29 April 2013 11:37, Peter Maydell wrote: >> On 11 April 2013 07:49, Stefan Hajnoczi wrote: >>> QEMU uses the John Hauser's SoftFloat library. It seems the matter >>> isn't settled yet in Linux but the FSF says the license is >>> incompatible with GPLv2. >> >> So the resolution determined for the kernel is that they actually >> took the softfloat code at a version before the indemnification >> clause appeared in upstream-softfloat's license: >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163904.html >> >> Given that that change only happened ~2010 it seems pretty >> likely that QEMU's softfloat code also predates it; has >> anybody done the necessary digging in our version control >> history to confirm? > > ...rats, looks like (a) the license change was earlier, at > the upstream version 2->2b boundary and (b) QEMU's softfloat > is based on 2b, not 2 (as the kernel's is.) The kernel code is quite different than the QEMU code too. Looks like it would be quite a lot of work to switch to the kernel implementation. That said, I think it's our best long term option... Regards, Anthony Liguori > > -- PMM