"Binary firmware and your freedom" at DistroWatch
- Inicie sesión ou rexístrese para enviar comentarios
I just read this article:
http://distrowatch.com/weekly.php?issue=20100614#feature
and am scanning the comments, but I thought it worth starting a thread on it here. One of the early posters has encouraged DW to solicit comments from the FSF (which I would be interested in hearing myself), while others have criticized the author for including inflammatory language in what otherwise seems to be an informative technical article.
> http://distrowatch.com/weekly.php?issue=20100614#feature
>
> and am scanning the comments, but I thought it worth starting a
> thread on it here. One of the early posters has encouraged DW to
> solicit comments from the FSF (which I would be interested in hearing
> myself), while others have criticized the author for including
> inflammatory language in what otherwise seems to be an informative
> technical article.
I've just sent this comment:
You claim that firmware being non-free is not an issue since it is run
by the peripherals and not by the main processor. That argument fails
in two points: first, it is hard to say that computers have only one
processor nowadays, as the GPU can even be more powerful than the main
processor. Second, that main processor has a binary only non-free
firmware too. The common consumer processors this days are fed with a
blob during the BIOS stage.
So, the firmware is just another program designed to be run by a
processor, being it the CPU or any of the other processors in a
computer. And if you don't have the four freedoms over that software
you can't know what such software does, and you cannot modify it or
improve it. What happens to a perfectly fine peripheral which just got
its warranty expired and the vendor doesn't want to keep supporting it?
If you have the code you can keep using your hardware forever. Don't
forget that a printer with no modifiable drivers started all this free
software thing 30 years ago.
A practical example might be the firmware included in the ATI Radeon
driver -which is listed as free software almost anywhere-. It is run by
a command processor in the card -not by the actual GPU- and it is
required for 3D and 2D support... it also manages the DRM (Digital
Restrictions Management) of the card, from a deep level. It is designed
to take away your freedom, to limit what you can do with your card.
It is needless to say that ATI cards show no 3D support on fully free
operating systems like gNewSense or Trisquel.
The other main claim is that the difference between embedded firmware
and user-loadable firmware is unimportant. If it is the same binary
blob, why being unable to change it improves the user's freedom? If you
need to load a binary blob yourself, then you need to get a copy of it
first, so you need to get non-free software to make your hardware work.
It sounds pretty bad to me. The worst thing is that in the GNU/Linux
world a free software provider -your distro- will need to provide such
non-free program to you. And if they don't, people like you will
undermine both the user and the distributor effort towards freedom. By
the way, the current FSF policy states that the kernel should not load
those binaries anyway, so there is no need for the users to hunt.
Besides, I see nothing wrong in saying to the users: your hardware
vendor doesn't respect your freedom. Buy from one that does. Also, this
policies are showing those vendors that they are doing wrong. To lower
the prices they are embedding more and more software inside the
hardware, it is cheaper than actually wiring the thing the proper way.
Now it is the moment to say the vendors: if you want to do that, give
me the code or I'll buy from someone else.
I read through the article and comments also, and there are some interesting points from both sides. From my understanding the main question is what is the difference, from a freedom standpoint, if the code necessary to operate a peripheral is loaded by the OS or if that same code is embedded in the peripheral itself? I have thought about this with respect to the hardware my system uses. Although Trisquel does not load any blobs, what about embedded code in the Seagate drive, Sony DVD/RW, monitor or even the keyboard that's part of the system? I am sure flash drives also contain embedded code.
All electronic devices do is execute instructions (call it software, firmware, code, programming, etc) so where do we draw the line and say we still have a free system? As best I can tell the FSF focuses on computer related items, but as some comments pointed out, the line between traditional computers and other consumer electronics is getting blurred as they get more sophisticated.
Please don't think I'm saying we should accept the binary blobs as past of the OS. I'm just saying that when we talk about free software we might need a more in depth and wider perspective
than we might have had in the past when declaring a device as free or non-free, and in deciding what level of free versus non-free we will accept before we reject a device. For example, we may use a TV remote that is completely non-free (just an example) but will not use a computer with an OS containing non-free code.
> For example, we may use a TV
> remote that is completely non-free (just an example) but will not use
> a computer with an OS containing non-free code.
The drivers are an essential part of the OS, and packaging them in a
weird way doesn't make the problem disappear: the firmware is part of
the driver, and if you need to feed it to your computer to make the
hardware work, then it needs to be free software for us to ship it.
Perhaps the following illustration will explain better what I think the DW article is trying to say. Suppose we have two systems:
(A)
applications (free)
kernel (free)
drivers (free)
-------------------
firmware (non-free)
hardware devices
(B)
applications (free)
kernel (free)
drivers (free)
firmware (non-free)
-------------------
hardware devices
Everything above the line is part of the OS loaded at boot, everything below the line is embedded in the hardware. According to the article, system (A) is acceptable to the FSF because all parts of the shipped OS are free, but system (B) is not because the shipped OS contains non-free code. I think the point he is trying to make is that the freedom provided by both systems is the same, with the only difference between the two being where the non-free firmware code is obtained. I don't think he is saying the FSF should endorse having non-free code in the OS (system B), but is asking why they don't object to having non-free code embedded in the hardware devices. If someone else interprets his remarks differently please let me know. Now from what I understand Richard Stallman's laptop uses free code down to the BIOS so he is holding to a consistent standard.
The bigger issue I was trying to bring up is that as hardware devices become more sophisticated, how far do we need to look into the workings of the devices when deciding what is truly free? For example, can I install Trisquel, which contains 100% free software, onto a computer system that has a non-free BIOS and non-free firmware embedded into the hard drive and optical drive and who knows what else, and claim I have a free system? Is it possible to truly have a 100% free device? What if we look at software use beyond the traditional computer? Cars use software that controls how they work and can't be modified, but we use them all the time. Even the TV remote, which was just an example, uses software. What if I want to reprogram the buttons so that volume is on the left and channels are on the right. I can't do that, but yet I use the device. Why do we object to non-free software on our computers, but accept it on other devices? I do believe they asked Richard Stallman about this once, with respect to using an ATM machine, and he said that although the ATM uses proprietary software, he has no control over it and so does not object to using the ATM.
Closing thoughts... while we work towards the goal of having 100% free software & firmware, we need to make sure we using a consistent standard, which was the main point of the article.
> (B)
> applications (free)
> kernel (free)
> drivers (free)
> firmware (non-free)
> -------------------
> hardware devices
Why do you split the firmware from the drivers?
> Everything above the line is part of the OS loaded at boot,
> everything below the line is embedded in the hardware. According to
> the article, system (A) is acceptable to the FSF because all parts of
> the shipped OS are free, but system (B) is not because the shipped OS
> contains non-free code. I think the point he is trying to make is
> that the freedom provided by both systems is the same
It is not. The firmware is a required part of the driver, regardless of
the technical details. And since it is in fact software -changing its
name doesn't make it disappear- it needs to be free.
> non-free code in the OS (system B), but is asking why they don't
> object to having non-free code embedded in the hardware devices.
Because embedded code is indistinguishable from wired hardware.
> The bigger issue I was trying to bring up is that as hardware devices
> become more sophisticated, how far do we need to look into the
> workings of the devices when deciding what is truly free? For
> example, can I install Trisquel, which contains 100% free software,
> onto a computer system that has a non-free BIOS and non-free firmware
> embedded into the hard drive and optical drive and who knows what
> else, and claim I have a free system?
If you are evaluating the problem that way, then you need to split the
firmware in three categories: Embedded and inaccessible -like the one
inside the Intel video cards-, embedded and accessible -like the bios-,
and not embedded.
The first is not a problem, since it is invisible -you might not even
know it is there-, the second one is an issue since it is serviceable
software you might need/want to modify. The third one requires you to
get a copy and feed it to your hardware to make it work.
Only the first one is completely ethical, but at least with the second
one you can buy the pieces -toss any software cd which may come with
them-, get a fully free distro and you are set to go. In most cases
you will never need to update the firmware anyway, so you can think of
it as embedded. It is not completely true -and that's why projects like
coreboot are required- but it is certainly a difference.
[...]
> Closing thoughts... while we work towards the goal of having 100%
> free software & firmware, we need to make sure we using a consistent
> standard, which was the main point of the article.
I'm not sure of what is the main point of the article -other than call
us naive-, but its main flaw is to make people think that firmware is a
thing other than software, and it seems to be working. ;)
> Why do you split the firmware from the drivers?
Here I was refering to the binary blobs which are non-free. Yes the firmware is part of the driver, but for example look at the nouveau driver. As I understand it, the driver is free, but for 3D capability it needs the non-free binary blobs. Since there are two parts required that is why I split it.
> If you are evaluating the problem that way, then you need to split the
> firmware in three categories: Embedded and inaccessible -like the one
> inside the Intel video cards-, embedded and accessible -like the bios-,
> and not embedded.
>
> The first is not a problem, since it is invisible -you might not even
> know it is there-, the second one is an issue since it is serviceable
> software you might need/want to modify. The third one requires you to
> get a copy and feed it to your hardware to make it work.
>
> Only the first one is completely ethical,...
To be ethical, would it depend on what the embedded and inaccessible code is designed to do? If we're looking from the stand point of freedom, what if the embedded code is for DRM? Isn't that one of the campaigns the FSF is working on to prevent requirements that manufacturers embed DRM carpabilities into their hardware? I could be wrong so please help me out.
Please understand that I am not advocating easing restrictions on non-free software; I am asking if maybe we need to look deeper into the "invisible" things which might affect freedom as much as the seen things.
Every device will become more complex in the next future. For example next TV generation will be more like computer than simple devices that can receive a signal, and it will be our concern to choose a model that embed a free operating system. The same for the Cars. What about today's mobile phones? They are computers and need an operating system.
> What if we look at software use beyond the traditional computer? Cars
> use software that controls how they work and can't be modified, but we
> use them all the time. Even the TV remote, which was just an example,
> uses software. What if I want to reprogram the buttons so that volume
> is on the left and channels are on the right. I can't do that, but yet
> I use the device. Why do we object to non-free software on our
> computers, but accept it on other devices?
Yes, we should fight in order to obtain that every computer-device such as next TV generation, mobile phones and even cars has a fully free operating system.
> To be ethical, would it depend on what the embedded and inaccessible
> code is designed to do? If we're looking from the stand point of
> freedom, what if the embedded code is for DRM? Isn't that one of the
> campaigns the FSF is working on to prevent requirements that
> manufacturers embed DRM carpabilities into their hardware? I could be
> wrong so please help me out.
I agree with Rubén Rodríguez about the firmware categories: embedded and inaccessible, embedded and accessible, and not embedded.
If the firmware is embedded and inaccessible, than the DRM concern doesn't make sense. It's not a problem since the firmware can't neither be changed nor updated. I agree: this case is completely acceptable.
Anyway, the DRM problem can exist even if the firmware is embedded, accessible and free. In this case the operating system could be considered absolutely free but with a DRM problem, since the firmware is a nominally free software that can't be changed. If the firmware is embedded and accessible we could have a totally free operating system with or without DRM problems, but this does not depend on the software. No software, in this case, could solve the DRM problem, either free or non-free. It is a hardware problem and it should be our concern to chose a device that doesn't implement the DRM.
--- Ven 18/6/10, name at domain <name at domain> ha scritto:
> Da: name at domain <name at domain>
> Oggetto: Re: [Trisquel-users] "Binary firmware and your freedom" at DistroWatch
> A: name at domain
> Data: Venerdì 18 giugno 2010, 02:21
> > Why do you split the firmware
> from the drivers?
>
> Here I was refering to the binary blobs which are
> non-free. Yes the firmware is part of the driver, but
> for example look at the nouveau driver. As I
> understand it, the driver is free, but for 3D capability it
> needs the non-free binary blobs. Since there are two
> parts required that is why I split it.
>
> > If you are evaluating the problem that way, then you
> need to split the
> > firmware in three categories: Embedded and
> inaccessible -like the one
> > inside the Intel video cards-, embedded and accessible
> -like the bios-,
> > and not embedded.
> >
> > The first is not a problem, since it is invisible -you
> might not even
> > know it is there-, the second one is an issue since it
> is serviceable
> > software you might need/want to modify. The third one
> requires you to
> > get a copy and feed it to your hardware to make it
> work.
> >
> > Only the first one is completely ethical,...
>
> To be ethical, would it depend on what the embedded and
> inaccessible code is designed to do? If we're looking
> from the stand point of freedom, what if the embedded code
> is for DRM? Isn't that one of the campaigns the FSF is
> working on to prevent requirements that manufacturers embed
> DRM carpabilities into their hardware? I could be
> wrong so please help me out.
>
> Please understand that I am not advocating easing
> restrictions on non-free software; I am asking if maybe we
> need to look deeper into the "invisible" things which might
> affect freedom as much as the seen things.
>
> I agree with Rubén Rodríguez about the firmware categories: embedded
> and inaccessible, embedded and accessible, and not embedded.
>
> If the firmware is embedded and inaccessible, than the DRM concern
> doesn't make sense. It's not a problem since the firmware can't
> neither be changed nor updated. I agree: this case is completely
> acceptable.
In rethinking this I agree. The four freedoms of the FSF relate to the software, not the response of the device. If a fully free OS tells the device "do this" and the device says "no" due to embedded code, the OS has not violated the four freedoms. Perhaps, as Lembas states in this thread, it's time for a Free Hardware Foundation. As the hardware gets more sophisticated, I can see the potential for very restricted devices which, although they might have fully free software, have lots of embedded firmware to limit them.
Side note - has anyone noticed the screenshot on gnu.org is of Trisquel?
Thanks for posting this thread. Those are interesting questions. Well worth the read besides the strange attitude.
(And then there's tivoization, you may get the source but only the original binary will run on the hardware.)
I guess the post correctly identifies the solution, to develop actually open hardware. Perhaps it is time to start the Free Hardware Foundation.
I am a translator!
From lembas
Perhaps it is time to start the Free Hardware Foundation.
I do completely agree, that would clearly help.
from usnica
Cars use software that controls how they work and can't be modified, but we use them all the time. Even the TV remote, which was just an example, uses software. What if I want to reprogram the buttons so that volume is on the left and channels are on the right. I can't do that, but yet I use the device. Why do we object to non-free software on our computers, but accept it on other devices?
Perhaps one important point is security and privacy. Our computers are usually connected to the net all the time and that makes them different from a TV set, which could work better or worse but does not actually pose any risk about your data. I do not like the idea of having installed in my computer a piece of software which no one knows what it is doing.
I agree with your point on security and privacy, especially with the computer. That is the main reason I was drawn to free software. I don't like the idea of the machine running code that cannot be openly reviewed. Recently there was a story here in the United States about two apps for Windows based phones that were found to have viruses placed in them intentionally by the programmers (I am including the link in case anyone thinks I'm making this up (http://today.msnbc.msn.com/id/37515778/)
As for the TV set, and even the car, there are now TV sets that connect directly to the internet, and although there may not be any data exposed, who's to say the software running in the set doesn't monitor, track or restrict the content? As for the car, the computer system is designed to control functioning of the vehicle's systems but can easily be used to monitor driving habits or vehicle location.
The whole software in my car thing scares the living daylights out of me. Free or proprietary. The idea that there are no mechanical connections and that if you turn the steering wheel it's software that controls how the wheels turn. I don't know about you but I have bugs in my software. I don't like the idea of how many free software programmers we would have to lose in fiery car experiments due to bugs before we get it right. I can see it now, widows posting on trac the results of the bugs encountered. Also this is going to be a major challenge. Cars change so fast. Even if we were to get a fully free OS for any car it would probably be obsolete by the time it got developed.I think I'll just stick to riding my bike now. No computer there.
- Inicie sesión ou rexístrese para enviar comentarios