Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 56

Thread: "Very Disruptive" Change Hurts ARM Linux Support

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    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.

  2. #22
    Join Date
    Nov 2011
    Posts
    301

    Default

    http://lists.infradead.org/pipermail...il/162339.html

    Apparently Linus thinks this is just the FSF nitpicking.

  3. #23
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by droidhacker View Post
    You're obviously stupid, because it is almost a given that it is NECESSARY to fork the GPL to ALLOW COMPATIBILITY with licenses that indemnify persons or organizations.
    You are obviously stupid, the problem here (if there is any) is that Linus chose to licence Linux under 'GPL v2 ONLY' rather than often used 'GPLv2 or later'. He did this because he thinks GPLv2 is a perfect licence as is, which is fine. I seriously doubt that Torvalds will change the licencing because of this library being licenced incompatible with GPLv2 which is the licence he again think is 'perfect'.

    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.

    Quote Originally Posted by droidhacker View Post
    In fact, you may want to look up the reason why Torvalds REJECTED v3. I'll give you a hint: It has NOTHING to do with indemnification.
    The reason he objected to GPLv3 was about the anti-tivoization clause.

  4. #24
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by XorEaxEax View Post
    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)..
    I can't imagine Linux license ever changing. According to Ohloh.net Linux has had contributions from almost 11000 developers. Getting approval from even a fraction of that would take ages... not to mentiont that most of the copyright is owned by companies (500+) and who knows what kind of deals they have made with each others. People have died, are unavailable, companies have went under and so on and so forth. So even if they wanted to change the license it would be almost impossible.

  5. #25
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by Teho View Post
    I can't imagine Linux license ever changing.
    Me neither, I've seen no indication of Linus or any other core Linux devs have expressed any interest in re-licencing. Quite the opposite, every chance Linus gets he seems to highlight his choice of GPLv2 as a key aspect of Linux success.

    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?

  6. #26
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,920

    Default

    Quote Originally Posted by XorEaxEax View Post
    Me neither, I've seen no indication of Linus or any other core Linux devs have expressed any interest in re-licencing. Quite the opposite, every chance Linus gets he seems to highlight his choice of GPLv2 as a key aspect of Linux success.

    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?
    Linux License CANT change. EVERY single contributor EVER would have to okay the license change and any licensee who refused or couldnt be contacted would have to have every commit they ever did redone by someone else who DID agree to the license change. Thats one of the upsides of a CLA (i dont really agree with them over all, just pointing out that a license change is easy for CLA projects). For that same reason its why im leery of linus' attitude of "GPL v2 and only." because a better license may come along that addresses a real problem with the GPLv2 and then its a giant pain in the ass to move to that new license.

  7. #27
    Join Date
    Jan 2011
    Posts
    164

    Default

    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.

  8. #28
    Join Date
    Mar 2009
    Posts
    130

    Default What does this mean for me?

    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:
    This is handled by userspace FP library nowadays, so the change doesn't really break anything in the long run.
    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?

  9. #29
    Join Date
    Apr 2008
    Posts
    34

    Default

    Quote Originally Posted by Kamikaze View Post
    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?
    I would assume between 2.6.33 incorrectly used some ARM6 or ARM7 instruction or FP or something, and the 3.9 will still correctly avoid those instructions when built for FPUless ARM.

    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 11:25 PM.

  10. #30
    Join Date
    Dec 2011
    Posts
    2,159

    Default Drop older hardware

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •