Difference between revisions of "When should firmware be free"

From LibrePlanet
Jump to: navigation, search
(Same firmware on EEPROM or burned in: :Here's more info about this situation: [http://lwn.net/Articles/641282/] (which follows from a [http://lwn.net/Articles/641260/ previous comment]) Here's a)
(Argument for free firmware)
 
(One intermediate revision by one other user not shown)
Line 33: Line 33:
 
==Same firmware on EEPROM or burned in==
 
==Same firmware on EEPROM or burned in==
  
:Here's more info about this situation: [http://lwn.net/Articles/641282/] (which follows from a [http://lwn.net/Articles/641260/ previous comment])
+
:''Here's more info about this situation: [http://lwn.net/Articles/641282/] (which follows from a [http://lwn.net/Articles/641260/ previous comment])''
  
 
Here's a not completely accurate summary:
 
Here's a not completely accurate summary:
Line 52: Line 52:
  
 
But, free firmware cannot protect your privacy if you open Facebook and upload your name, location, contacts, and activities.
 
But, free firmware cannot protect your privacy if you open Facebook and upload your name, location, contacts, and activities.
 +
 +
==Argument for free firmware==
 +
 +
If you got given a piece of proprietary software on a read-only CD, you would still miss the source code, because you could not study, distribute it, create copies, or modify it.
 +
 +
Similarly with a read-only piece of firmware, you may not be able to study it, nor can you redistribute copies, nor can you create copies, nor can you modify it.
 +
 +
So whilst having a non-adjustable piece of proprietary firmware may be better in security terms than having an adjustable piece of proprietary firmware, it is still, in my opinion, always better to have these essential freedoms in place in the form of free firmwares. [[User:J05HYYY|J05HYYY]] ([[User talk:J05HYYY|talk]]) 19:33, 21 October 2015 (EDT)
  
 
==Articles and statements by ''or about'' FSF==
 
==Articles and statements by ''or about'' FSF==

Latest revision as of 18:33, 21 October 2015

This page not by FSF
Like most pages on LibrePlanet, this page is not written by FSF. This page carries an explicit notice because the topic sometimes attracts media attention and people unfamiliar with LibrePlanet might arrive at this page without knowing the (non-)relation to FSF.

Goals of this page

  • Analyse the problem
  • Discuss possible policies
  • Establish FSF's current policy
  • Make suggestions, if necessary, for how FSF's policy could be improved, clarified, or better explained

RMS on Android

From: http://www.gnu.org/philosophy/android-and-users-freedom.html

The phone network firmware comes preinstalled. If all it did was sit there and run, we could regard it as equivalent to a circuit. When we insist that the software in a computing device must be free, we can overlook preinstalled firmware that will never be upgraded, because it makes no difference to the user that it's a program rather than a circuit.

Unfortunately, in this case it would be a malicious circuit. Malicious features are unacceptable no matter how they are implemented.

On most Android phones, this firmware has so much control that it could turn the product into a listening device. On some, it controls the microphone. On some, it can take full control of the main computer, through shared memory, and can thus override or replace whatever free software you have installed. With some models it is possible to exercise remote control of this firmware, and thus of the phone's computer, through the phone radio network. The point of free software is that we have control of our computing, and this doesn't qualify. While any computing system might HAVE bugs, these devices might BE bugs. (Craig Murray, in Murder in Samarkand, relates his involvement in an intelligence operation that remotely converted an unsuspecting target's non-Android portable phone into a listening device.)

In any case, the phone network firmware in an Android device is not equivalent to a circuit, because the hardware allows installation of new versions and this is actually done. Since it is proprietary firmware, in practice only the manufacturer can make new versions—users can't.

Putting these points together, we can tolerate nonfree phone network firmware provided new versions of it won't be loaded, it can't take control of the main computer, and it can only communicate when and as the free operating system chooses to let it communicate. In other words, it has to be equivalent to circuitry, and that circuitry must not be malicious. There is no obstacle to building an Android phone which has these characteristics, but we don't know of any.

Hard drive controllers

Some hard drives have upgradeable firmware. Some (currently) rare ones can even run a Linux kernel:

What's the general status of hard drive firmware in terms of upgradeability and problems caused?

Same firmware on EEPROM or burned in

Here's more info about this situation: [1] (which follows from a previous comment)

Here's a not completely accurate summary:

In certain situations, there are similar hardware components, some of which have a certain firmware on an programmable ROM, and other versions of that components have the exact same firmware but in a non-programmable ROM.

But the current distinction, the former is non-free and the latter is fine even though they're both running the same non-free firmware.

Should the distinction be fine-tuned to address this situation?

How important is free firmware?

It depends. For some goals, free firmware isn't enough, and for others it's not necessary.

A free network driver (wifi or other) is necessary for privacy because it could log what servers you connected to and when.

Free CPU firmware is good, but reliable encryption is still possible on a non-free CPU, even if you assume it is back-doored.

But, free firmware cannot protect your privacy if you open Facebook and upload your name, location, contacts, and activities.

Argument for free firmware

If you got given a piece of proprietary software on a read-only CD, you would still miss the source code, because you could not study, distribute it, create copies, or modify it.

Similarly with a read-only piece of firmware, you may not be able to study it, nor can you redistribute copies, nor can you create copies, nor can you modify it.

So whilst having a non-adjustable piece of proprietary firmware may be better in security terms than having an adjustable piece of proprietary firmware, it is still, in my opinion, always better to have these essential freedoms in place in the form of free firmwares. J05HYYY (talk) 19:33, 21 October 2015 (EDT)

Articles and statements by or about FSF