[Qemu-devel] SoftFloat licensing in Linux kernel

[Qemu-devel] SoftFloat licensing in Linux kernel

[Stefan Hajnoczi]

http://lwn.net/Articles/546840/

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.

Something to keep an eye on.

Stefan

Re: [Qemu-devel] SoftFloat licensing in Linux kernel

[Peter Maydell]

On 11 April 2013 07:49, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> http://lwn.net/Articles/546840/
>
> 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?

thanks
-- PMM

Re: [Qemu-devel] SoftFloat licensing in Linux kernel

[Peter Maydell]

On 29 April 2013 11:37, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 11 April 2013 07:49, Stefan Hajnoczi <stefanha@gmail.com> 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.)

-- PMM

Re: [Qemu-devel] SoftFloat licensing in Linux kernel

[Anthony Liguori]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 29 April 2013 11:37, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 11 April 2013 07:49, Stefan Hajnoczi <stefanha@gmail.com> 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

Re: [Qemu-devel] SoftFloat licensing in Linux kernel

[Peter Maydell]

On 29 April 2013 14:04, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> ...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.

We don't necessarily need to switch to the kernel's code
and then unpick all the changes they've made over the years --
we could start with upstream v2 instead I guess.

(Ideally where there have been changes we've made since,
like the fused-multiply-add support and NaN handling
changes we could try to get those contributors to relicense
so we can just reapply that bit. I don't know how you do
the mechanics of this in a legally solid way, though.)

-- PMM