Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

GNU Linux-libre 3.5-gnu: Free and a half

Posted Jul 25, 2012 5:29 UTC (Wed) by raven667 (subscriber, #5198)
In reply to: GNU Linux-libre 3.5-gnu: Free and a half by jzbiciak
Parent article: GNU Linux-libre 3.5-gnu: Free and a half

> How is ROM you can't access or change more free than RAM that holds a copy of the same bits?

The strict FSF position is that the difference is that it's changeable, in the way that software is, but that you don't have the rights or the tools to do so but the manufacturer does have those rights and tools so it is not an equitable arrangement. At least that's my understanding. In any of the copyleft licenses like the GPL all parties have an equal and high level of rights to the software, rights that usually only the author has, to inspect, modify, distribute, and in the case of the GPLv3, run the result on the target hardware.

(Log in to post comments)

Posted Jul 25, 2012 20:53 UTC (Wed) by khim (subscriber, #9252) [Link]

The strict FSF position is that the difference is that it's changeable, in the way that software is, but that you don't have the rights or the tools to do so but the manufacturer does have those rights and tools so it is not an equitable arrangement.

Right. This is what they preach. Sadly this is not what they do.

Let me remind you one fact, which is vital for the understanding of my ire:
Contemporary CPUs are unusable without microcode. As in: often they can not even boot Linux without this binary blob.

Some CPUs can boot Linux but need blobs to run it correctly. Now we have two choices:

Embed said blob in another, larger blob (BIOS or, recently, EFI/UEFI).
Provide said blob in the OS image and load it from there.

The FSF-advocated solution (hardware without any binary blobs) no longer exist.

Now, in this world, in this reality the solution where OS brings the required blob is obviously more robust (it's easier to update small microcode as compared to the whole firmware: microcode is provided by Intel where BIOS blob is provided by motherboard manufacturer and usually quite old and buggy), easier to hack (format of microcode is unknown, but it's loaded on each reboot anew thus it's safer to experiment with it) and thus better for any user (user who don't care about freedom get more robust system, user who cares about freedom gets more hackable system). But for some reason FSF pushes for the other, worse solution. Why? What's the point?

GNU Linux-libre 3.5-gnu: Free and a half

Posted Jul 27, 2012 0:10 UTC (Fri) by cry_regarder (subscriber, #50545) [Link]

Because by their position, doing otherwise is aiding and abetting? You may not find their position pragmatic, but it is principled.

GNU Linux-libre 3.5-gnu: Free and a half

Posted Jul 27, 2012 0:32 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

> Because by their position, doing otherwise is aiding and abetting? You may not find their position pragmatic, but it is principled.

No, we find their position unprincipled as it specifically demands that the vendors _reduce_ the control the user has over the device (unless the vendor gives complete control)

saying that devices with firmware blobs are bad is very legitimate.

saying that it's better to have devices with firmware blobs that the user cannot replace (or can only replace if they use proprietary software) than to have firmware blobs that the user can replace with free software is crossing a line that gets them called out. This is letting their rules violate the principles they claim to have.