Apparently Linus thinks this is just the FSF nitpicking.
My initial thought was the same as recent posts above, ie that the disclaimers were similar to X11 or BSD license text, but I suspect the key issue is use of the word "indemnification".
IANAL but "indemnification" seems to imply something a lot stronger than the usual "it's not my fault, man" license text -- eg responsibility for covering the indemnified party's costs if something goes really wrong.
Either way this has nothing to do with FSF, they can't tell Linus what licence to use or whether or not he allows 'or later'. He made this choice, he (and the other copyright holders of Linux) are the only ones who can change the licencing should they want to (very doubtful). Also FSF can't force the Linux devs to do anything in this regard should they think this is not a real licence issue.
Of course this doesn't have to be an issue either way, if the kernel devs are fine with this licence then there's really nothing else to say. They set the rules for how to enforce the licencing as they are the copyright holders, gpl-violations which reported this licence incompability has no sway and neither does FSF, again it's up to the copyright holders (Linux devs).
Beyond that, judging by the mailing-list exchange this floating point emulation is mostly being done in user-space these days and as such it seems likely this in-kernel library will be deprecated anyway, so very much a storm in a teacup. The real action in the mailing list was the angry spat between Russel King and Måns Rullgård, what was that about?
There is a difference between saying (paraphrased) "If you use this code, you agree to indemnify XYZ..." and (paraphrased) "Use of this software is restricted to people who will indemnify XYZ...". One makes the implicit assumption that if you use the code, you have already agreed to indemnify the original authors. The other states that you cannot use it unless you do so. This is probably what the FSF is having issues with.
Damn, I run a Globalscale Dreamplug as my main fileserver.
I'd recently just spent some time learning how to update the u-boot and configure & compile a new linux 3.8 kernel. It's a Marvell Kirkwood - running a Feroceon 88FR131 - an ARMv5te processor. It doesn't have a hardware FPU and any FP ops are currently done with emulation. Until now, I was looking forward to the 3.9 kernel release as I heard changes had been merged to provide CPU frequency stepping for this processor so it would use a tiny bit less power and give off slightly less heat when it's idle.
Assuming I did upgrade to the 3.9 kernel when it's out of RC, does anyone know what I could expect would break without software FP emulation?
I noticed that RealNC stated somewhere in this thread:
I know before I updated the kernel to 3.8 it was running a custom version of 2.6.33-7. I upgraded mainly because the default install consistently segfaulted when I was trying to use file encryption (I remember trying at least eCryptFS, encFS and one other). I would imagine encryption algorithms are likely to use FP operations and I'm wondering if that custom 2.6.33-7 didn't have software fp emulation compiled in which caused the issue? Does that sound plausible?This is handled by userspace FP library nowadays, so the change doesn't really break anything in the long run.
As for the kernel support -- Ubuntu ARM is based on Debian ARMHf (hard float) and so would I guess work with 3.8 but not 3.9. Debian's normal armel support is softfloat, and I'd guess most ARM distros are softfloat. I assume there's basically 2 differences: 1) Some GCC flags (whether to shoot out FPU instructions or the equivalent softlib calls). 2) A few apps like ffmpeg probably have VFP and FPU on/off flags.
Last edited by hwertz; 04-10-2013 at 10:25 PM.
Well recently hardware support for old i386 were dropped.
Does anyone really use ARMv4 and ARMv5?
Everyone is using ARMv7, except Raspberry Pi which is using old ARMv6.
So does this really affect anyone?
And those affected can continue run Linux kernel 3.8 for quite a while.