4 ms·

> That's one reason I'm still hoping for a Linux/Firefox phone. You should rather hope for GNU/Linux phones. Linux devices (without the GNU part) is most of th

> That's one reason I'm still hoping for a Linux/Firefox phone. You should rather hope for GNU/Linux phones. Linux devices (without the GNU part) is most of the time, just another locked device (see your Android phone, router, TV, etc). The presence of GNU software pieces (or any software licensed under GNU [LA]GPL v3+) ensures the device is free of locks (or with user breakable locks).

jhasse 9y ago
> The presence of GNU software pieces (or any software licensed under GNU [LA]GPL v3+) ensures the device is free of locks (or with user breakable locks). That's not true, as the Linux kernel is still GPLv2. So while you could swap out the userspace GNU utils, the device manufacturer can still lock the bootloader which is perfectly fine with the GPLv2. Even if the bootloader is unlockable (e.g. LG allows this btw), you will most likely be stuck to a specific kernel version due to proprietary binary blobs which nearly every phone uses. So instead of a GNU/Linux phone, you should rather hope for a phone with complete open source drivers (or a GPLv3 kernel).
- pksadiq 9y ago
  > That's not true, as the Linux kernel is still GPLv2. So while you could swap out the userspace GNU utils, the device manufacturer can still lock the bootloader which is perfectly fine with the GPLv2. Yeah, probably. But the presence of packages like GNU libc can make it harder for the manufacturer to lock the device. > ... kernel version due to proprietary binary blobs which nearly every phone uses. Sadly, binary blobs are always an issue. In the case of Linux, this happened because many Linux developers don't care about binary blobs. If they did, you won't see any binary blobs (as it is a violation of GNU GPL). > ... with complete open source drivers My main point was to quote that 'open source' doesn't solve these issues. We should take software freedom more seriously. > ... (or a GPLv3 kernel). I wish we will not have to wait until the human civilization end in fire to see this.
  - jhasse 9y ago
    > Yeah, probably. But the presence of packages like GNU libc can make it harder for the manufacturer to lock the device. glibc is LGPL, so I don't see how that should change anything? > (as it is a violation of GNU GPL). IIRC it's a gray area.
    - pksadiq 9y ago
      > glibc is LGPL, so I don't see how that should change anything? glibc requires libgcc[0], which is GPLv3 (with runtime exception). The same for libstdc++[1]. [0] https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
      - jhasse 9y ago
        The runtime exception makes it possible that everything else is proprietary, locked and unchangeable. Which actually is okay for apps IMHO, because I would want to run proprietary software like games (sandboxed of course). The kernel really is the problem here and where there's no GPLv3 code used at all.
  - vetinari 9y ago
    > this happened because many Linux developers don't care about binary blobs. It is mostly users, not developers, who don't care about binary blobs. The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them. See also the Nvidia binary driver. Who is the advocate for that? Users (hey, never had a problem and it runs my apps very well) or developers (whoa, we cannot develop Wayland/etc with this)?
    - pksadiq 9y ago
      > It is mostly users, not developers, who don't care about binary blobs. Partly yes, but mostly No. You are right that most people don't care about binary blobs. But the people who can enforce this are the developers. If all developers agree and enforce this, no on can include binary blobs in Linux kernel. Also it would be wrong for a mere user to try to enforce it by law, because it might piss off the developers, which is really bad. Also, it might not withstand in court because the developers don't care. > The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them. "pragmatic"? Most of us are concerned about our immediate problems, and thus we end up with temporary solutions (most of the time), sometimes because we don't have choice, sometimes because that's easier. I recently got an ASUS eeepc which doesn't have graphics support, because when it was first released, the only support was a binary blob, which is now abandoned. We will eventually face issues with these binary blobs, for sure. As we know, each day, new vulnerabilities are being surfaced. But yeah, most of us won't care, until and unless something happen. But by then, it will be too late. Just like how many of us consider the importance of time only when we know we don't have enough. So I don't think it is "pragmatic" in long term.

jhasse 9y ago

> The presence of GNU software pieces (or any software licensed under GNU [LA]GPL v3+) ensures the device is free of locks (or with user breakable locks). That's not true, as the Linux kernel is still GPLv2. So while you could swap out the userspace GNU utils, the device manufacturer can still lock the bootloader which is perfectly fine with the GPLv2. Even if the bootloader is unlockable (e.g. LG allows this btw), you will most likely be stuck to a specific kernel version due to proprietary binary blobs which nearly every phone uses. So instead of a GNU/Linux phone, you should rather hope for a phone with complete open source drivers (or a GPLv3 kernel).

pksadiq 9y ago
> That's not true, as the Linux kernel is still GPLv2. So while you could swap out the userspace GNU utils, the device manufacturer can still lock the bootloader which is perfectly fine with the GPLv2. Yeah, probably. But the presence of packages like GNU libc can make it harder for the manufacturer to lock the device. > ... kernel version due to proprietary binary blobs which nearly every phone uses. Sadly, binary blobs are always an issue. In the case of Linux, this happened because many Linux developers don't care about binary blobs. If they did, you won't see any binary blobs (as it is a violation of GNU GPL). > ... with complete open source drivers My main point was to quote that 'open source' doesn't solve these issues. We should take software freedom more seriously. > ... (or a GPLv3 kernel). I wish we will not have to wait until the human civilization end in fire to see this.
- jhasse 9y ago
  > Yeah, probably. But the presence of packages like GNU libc can make it harder for the manufacturer to lock the device. glibc is LGPL, so I don't see how that should change anything? > (as it is a violation of GNU GPL). IIRC it's a gray area.
  - pksadiq 9y ago
    > glibc is LGPL, so I don't see how that should change anything? glibc requires libgcc[0], which is GPLv3 (with runtime exception). The same for libstdc++[1]. [0] https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
    - jhasse 9y ago
      The runtime exception makes it possible that everything else is proprietary, locked and unchangeable. Which actually is okay for apps IMHO, because I would want to run proprietary software like games (sandboxed of course). The kernel really is the problem here and where there's no GPLv3 code used at all.
- vetinari 9y ago
  > this happened because many Linux developers don't care about binary blobs. It is mostly users, not developers, who don't care about binary blobs. The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them. See also the Nvidia binary driver. Who is the advocate for that? Users (hey, never had a problem and it runs my apps very well) or developers (whoa, we cannot develop Wayland/etc with this)?
  - pksadiq 9y ago
    > It is mostly users, not developers, who don't care about binary blobs. Partly yes, but mostly No. You are right that most people don't care about binary blobs. But the people who can enforce this are the developers. If all developers agree and enforce this, no on can include binary blobs in Linux kernel. Also it would be wrong for a mere user to try to enforce it by law, because it might piss off the developers, which is really bad. Also, it might not withstand in court because the developers don't care. > The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them. "pragmatic"? Most of us are concerned about our immediate problems, and thus we end up with temporary solutions (most of the time), sometimes because we don't have choice, sometimes because that's easier. I recently got an ASUS eeepc which doesn't have graphics support, because when it was first released, the only support was a binary blob, which is now abandoned. We will eventually face issues with these binary blobs, for sure. As we know, each day, new vulnerabilities are being surfaced. But yeah, most of us won't care, until and unless something happen. But by then, it will be too late. Just like how many of us consider the importance of time only when we know we don't have enough. So I don't think it is "pragmatic" in long term.