It's an interesting edge case when you have someone actually moving from one model to another. But I think even OpenBSD's famously strong policy on binary blobs would allow this one, at least as they've implemented the policy in the past. They require source for drivers, which means anything you need to load onto the chip or use to communicate with it, but not for every piece of ROM that's internal to a chip. For example, Intel and AMD both microcode some instructions in firmware on their chips, rather than implementing them in silicon, and OpenBSD is ok with that, treating the silicon and microcoded part as all part of the blackbox chip package, rather than as a "driver" that requires source.
Actually, the requirement for adding firmware (something that is loaded onto a chip) to OpenBSD is that it be modifiable. Source isn't required. (Speaking only about firmware that goes on the chip, not HAL layers that run on the CPU. Those are banned in binary form.)
I'd say the biggest difference here is that OpenBSD's goal is to make a free operating system, not a free phone.
To be fair, I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware. So even if we had full source code to the radio's firmware, it would be illegal to sell a device that could be user-programmed. Or something.
(I don't know how widely enforced this is, though. I've never had any trouble telling my wifi equipment I'm outside of the US to get access to extra channels. I guess this is a federal crime, but good luck enforcing it.)
Demonstrably untrue since you can download the Gnu-radio [1] kit which is supported by a module sold by Ettus [2] which basically allows you to create arbitrary software radios. If you ever wanted to build a hyper-encrypted-fast-flip-wideband-frequency-hopping super sekrit access point, these guys have what you need :-). Of course you would end up needing two of them at least.
This argument used to be used all the time by WiFi device manufacturers, and it turns out to be bullshit. The truth is that you, the operator of the device, assume all liability for your modifications, but there is no reason you can't flash/modify your firmware to, say, improve your power-saving abilities or improve your scanning times.
We have enough source code for Atheros devices to be able to reprogram them as we see fit, and the FCC doesn't really care.
> I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware.
If this were the case, you (the private individual) would not be allowed to have anything that would allow you to build a radio transmitter of any form.
I doubt it. RMS uses some laptop specifically because the processor is open source. From his wiki page: "Stallman's only computer is a Lemote Yeeloong netbook (using the same company's Loongson processor) which he chose because it can run with 100% free software even at the BIOS level, stating "freedom is my priority. I've campaigned for freedom since 1983, and I am not going to surrender that freedom for the sake of a more convenient computer."[57] Lemote is a joint venture of the Institute of Computing Technology of the Chinese Academy of Sciences, an institution of the State Council of China."
It'd be much more compelling if I knew how much RAM I could jam in the thing. Comes with 1GB, but if I could get 4 in there, it'd be a rocking little machine.
It's actually not. The US government doesn't have to worry about malicious hardware spying on them, because all the hardware is designed (and mostly manufactured) in the US. China, on the other hand, can't trust Microsoft or Intel, so they have to develop their own stuff. Since that's hard, they pawn it off on the Free Software community, who wants the same thing they do (but for different reasons). "The enemy of my enemy is my friend" and all that.
China? Could he not side with someone who dislikes USA more? Surely there's a North Korean laptop that fits his requirements. Not that anyone other than Stallman is right, it's just odd.
Your complaint seems just a little bit ridiculous considering that most Americans, yourself probably included, use computers made in China or made with parts made in China. In fact, it's probably easier to find and computer 100% free of proprietary software than a computer 100% free of Chinese components. Considering that, national security concerns aside, free trade between countries is usually mutually beneficial, I see no reason to fault Stallman for this.
I meant that he cares about total freedom and control of his hardware, and yet bought from a country that likes the opposite. Who knows if some part of it isn't actually open source, and if it isn't, China and NK are the least trustable countries (not companies per se) for it to be from.
At the risk of making meta-noise, why, oh why, have five different people replied to this thing in a single hour? Does anyone think that some kind of lovely discussion is going to bloom by "refuting" this comment? Half the page is now about whether Richard Stallman is anti-American and anti-freedom for buying a Chinese-manufactured laptop. Is this a good outcome?
Seriously, just downvote (or if it's bad enough, flag) and move on.
His concern in this case is to get something that runs with free software, rather than buy something from a particular country. I'm sure he'd agree that China does a lot of things he disagrees with at a political and philosophical level.
I disagree. I think people dislike the Chinese government, but not the Chinese people. I think there's a lot more racism against Americans in general in foreign countries than against the Chinese.
Probably yes. I can't find the source, but I think I remember him saying something along the lines of "if the firmware cannot be updated, it can be considered akin to hardware and doesn't need to be free".
Isn't all my other non-free software just blobs that are loaded by my free software? Why isn't it my right as a user to choose the closed software? If hiding the blob from the user makes it okay, why not apply that thinking to drivers wrapped by the NDISwrapper?
The problem is that binary-only drivers are in privileged locations and frequently cause OS kernel problems. As they're binary only, they've basically undebuggable, and frequently nonportable to other systems.
In short, if you want a system you can at least have a chance at fixing when it breaks, you need the source code to your drivers.
This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver, but can be a hassle if there are restrictions on distribution of the firmware.
> This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver
I'd argue that it's an entirely different kettle of fish. Once the firmware blob is loaded into the chip, the hardware widget works exactly like it would otherwise. If the firmware just lived on a ROM inside the widget, you'd never know it existed.
Protesting closed source drivers I'm all behind for the reasons you mention, but closed source firmware just simply can't aggravate me.
"This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver"
In most scenarios where I think a '3rd party chip with its own firmware' makes sense, that chip can generate interrupts and/or do DMA. Both cases will (typically) allow that firmware to crash the OS on the other CPU (or bring it to its knees by DDOS-ing it with interrupts)
Because of that, I do not see why a blob running on that 3rd party chip would be less of an issue than a blob running on the main CPU.
Good argument. I would say it is not less of an issue, but I also think it isn't less of an issue than having a blob running on the main CPU. IMO, such blobs only become problematic if they do not work properly or aren't flexible enough. Whether they are made in soft-, firm-, or hardware is immaterial for that.
In the end, for almost every case (yes, you probably _can_ build your own 1kW 6502-class CPU from sand, if you are good, start young and persevere for a couple of decennia) it boils down to the fact that you will have to trust some other people. After all, you cannot reasonably verify that say a x64 CPU really behaves as its documentation states it does.
One reason the blob on the CPU is so different is the way it interfaces with your code. In that regard, it is almost never flexible enough and the exposed interface surface is generally enormous. Your kernel version is supported only at the mercy of nvidia or whoever.
Firmware chunks have a very simple interface: load. Anybody with the firmware file and some basic documentation can make it happen.
Why isn't it my right as a user to choose the closed software?
It's your right as the user - there's nothing to stop you from doing that. They simply won't help you with it, and any distro that does is deemed non-really-free (like Debian).
Don't confuse "right to do" with "right to being easy to do".
I wonder how hard it is to swap peripheral chips in embedded solutions like this? And more importantly, are there any WLAN chips with good blobless drivers? Somehow it seems that they always have been a pita for Linux
Yes. And when a malicious packet is discovered that compromises the RTOS on the chip, and the vendor patches it, this cost raising ideological kludge will leave you devices vulnerable forever.
(I say this, knowing full well that I suffer from the closed nature of this device. The DreamPlug uses this, and the access point version of the firmware only supports 8 devices. That doesn't go very far with the usual complement of mobile devices people carry. I am powerless to patch it and will have to add a dedicated access point to work around it, but paying to freeze this particular deficient version of code is ridiculous.)
What if, instead of moving the software to a binary blob, they went a bit nuts and moved it to an ASIC that did the same job in random logic? That is, what if they re-implemented the software in pure hardware?
