[pksadiq]

> 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.

[vetinari]

> 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]

> 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.

[vetinari]

> 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.

And yet, it is the users who have the ultimate power over developers of such hw/sw. No, not courts, that's the entirely wrong solution.

Their wallets.

Such solutions are being developed only because there's money in it. It is only up to the users, whether this factor is true or not. If they care about sources, they would not purchase hardware that requires blobs. If they don't care, and reward the developers with their money for the blobs, whose fault it is?

[jhasse]

> 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]

> 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 [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

[jhasse]

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.