| |||||||||||||
|
| |||||||||||||
FSF offers "GNU Bucks" for finding nonfree works in free distributionsFSF offers "GNU Bucks" for finding nonfree works in free distributionsPosted Oct 2, 2009 11:45 UTC (Fri) by Zack (guest, #37335)In reply to: FSF offers "GNU Bucks" for finding nonfree works in free distributions by ikm Parent article: FSF offers "GNU Bucks" for finding nonfree works in free distributions
>Basically the FSF says that you should better pay extra for an onboard EEPROM than to use cheaper hardware along with some external blobs which you'd have on that EEPROM anyway.
No, "basically" the FSF says what they've always said; that it's preferable to have software that can't be modified by anyone over software that can only be modified by certain parties thereby creating a relationship of artificial inequality.
>Well, whatever, Richard. I'm happy it's Linus who runs the kernel.
It seems GPL2-only is quickly becoming the new BSD.
(Log in to post comments)
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 15:38 UTC (Fri) by foom (subscriber, #14868) [Link]
> No, "basically" the FSF says what they've always said; that it's preferable to have software
> that can't be modified by anyone over software that can only be modified by certain > parties thereby creating a relationship of artificial inequality.
Except that's quite simply *not* the tradeoff in this case.
Which would you rather have:
2) firmware in RAM that you need to upload each time and thus need to store on your hard
With the second, at least there's a hope of being able to hack it. Yet that's the one the FSF
Gotta hate those blobs Posted Oct 2, 2009 16:11 UTC (Fri) by man_ls (subscriber, #15091) [Link] I think it makes a lot of sense. Fighting for manufacturers to make devices updateable from Linux is a battle certainly worth fighting. But there are some very unpleasant scenarios which stem from your second option, like the manufacturer prohibiting distribution of firmware blobs for old devices once they want to decommission your perfectly good hardware -- you could still choose to copy the blob to the hardware illegally or fight in court. Linux distributors cannot choose, they would have to comply. The distributor can also (out of sheer cluelessness) prohibit redistribution of binary blobs, complicating the whole installation process unnecessarily: how do you download and install a firmware blob for a modem if you don't have internet access?Remember, the reasons for the four freedoms granted by the GPL are practical. The freedom to modify the code and redistribute your modifications might not apply here, but the first two (run software and distribute it as is) are still very important.
That's totally different kettle of fish Posted Oct 2, 2009 16:31 UTC (Fri) by khim (guest, #9252) [Link] But there are some very unpleasant scenarios which stem from your second option, like the manufacturer prohibiting distribution of firmware blobs for old devices once they want to decommission your perfectly good hardware -- you could still choose to copy the blob to the hardware illegally or fight in court. That's why Linux requires perpetual license to firmware blobs. Blobs which can not be redistributed forever are just not included in Linux. I think that both Linus's position and RMS's positions are valiable: Linus's are practical (we'll accept what we can and reject what we can't) while RMS's is more forward-looking. I support and applaud RMS - even if I don't plan to use such free distribution I feel it's really important to at least know problem areas. If they can be resolved or not is different question, but we should at least know when/if we depend on non- free software.
That's totally different kettle of fish Posted Oct 2, 2009 18:31 UTC (Fri) by foom (subscriber, #14868) [Link]
But the Free distribution *doesn't* tell you about the problem areas. The problems are in
every single device in your system -- your CPU, network card, hard drive, keyboard, mouse, video card, and monitor are all are filled with non-free software.
And many of those are updatable by the manufacturer.
RMS's position just pushes users to demand that manufacturers hide the software in the
Hit'n run Posted Oct 2, 2009 20:01 UTC (Fri) by man_ls (subscriber, #15091) [Link] It doesn't follow; it's like saying that current traffic laws encourage drivers to hit'n run, since if they stop after an accident they can be fined and/or imprisoned.No, the FSF asks manufacturers to do the right thing; and if they can't do the right thing, not to ask people to do their dirty job for them just to save a couple of dollars. If manufacturers choose the way of hiding code in the device instead of opening it, then you have the option not to buy it and prefer something more hackable. But at least we are not carrying their binary blobs around which do mysterious things. I don't see what is wrong with that.
Hit'n run Posted Oct 2, 2009 20:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
the problem that many of us have with the FSF position (including as it was artculated earlier in this thread) is that it says that firmware blobs loaded into the device by the OS every boot are Evil, but if they are in flash or rom it's not an issue
the option isn't between things that have firmware blobs and ones that don't, it's between
firmware blobs loaded by the OS
all of these can be with and without source available
smart peripherals are going to include firmware. as noted elsewhere just about every x86 CPU includes firmware (usually called microcode) that runs on the CPU.
if the position was that any of these without source was Evil it would at lease be consistant (even if not realistic), but as it is this position is only hitting the vendors that are the most open, saying that they are bad, but vendors that are less open are considered good.
More open? Posted Oct 2, 2009 21:37 UTC (Fri) by man_ls (subscriber, #15091) [Link] The wrong notion here is that vendors that give you the binary blob to load at runtime are more open than those which have it on flash or ROM. They are exactly as closed, only they give you their opaque bunch of bytes to carry around. But this is precisely the situation where source code would be more useful; right next to it is firmware blobs in flash.Source code that cannot be modified is completely useless. Asking for the sources used to generate a ROM image would not just be unrealistic, it would be idiotic. At least you could have made the argument that uploading random code to a device can be harmful to the device and the owner, so blobs must be somehow signed.
More open? Posted Oct 2, 2009 22:38 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
in our eyes, the wrong notion is that a freely distributable blob that can be installed via a documented interface (i.e. the requirements for the firmware to be able to be distributed and installed by the kernel) is somehow _less_ free than a firmware blob that cannot be redistributed and must be installed via a windows GUI tool
to me it seems obvious that the first situation is better than the second, but the FSF position seems to be that the second is better.
Free vs convenient Posted Oct 3, 2009 9:23 UTC (Sat) by man_ls (subscriber, #15091) [Link] You express the dichotomy perfectly, but fail to draw the missing link. It is more convenient to have an opaque blob that is loaded using a documented interface, but it is just as "unfree" as having firmware updateable only from Windows or having it on ROM. Users would actually have an extra degree of freedom in the first two situations, but the binary blob unbalances the freedoms for the vendor: the vendor can modify the firmware and you can't. With the ROM we have a level playing field (nobody can modify the firmware), and thus should be better in the long run.This unintuitive result comes from trying to look into the consequences of your acts a little further. If we just obtusely center on the current situation we will never improve things. It is a bit surprising that Linux users might not understand the dichotomy, since we have seen it before in many forms: the GPL gives you less freedom than a BSD license, but is better in the long run. But let's not be naïve: at a certain point most people are happy with the status quo and say "Yes, the freedoms we have are nice and all, but now is the time for convenience". We have seen it with GPL vs BSD, we have seen it for kernel devs and the GPLv3, we are seeing it now with firmware blobs. The FSF is like the guy who is never happy with the situation and always tries to push the envelope.
Free vs convenient Posted Oct 3, 2009 10:08 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
if the only options were downloadable blob vs ROM (and especially if the vendor had some way to force the update of the doanloadable blob) I would probably agree with you.
but there are a couple of issues here.
1. yes, only the vendor can (easily) create the blob to download, but the user/OS can choose which blob to use. they don't force you to change what blob you send to the card.
2. the real alternative to the downloadable blob doesn't seem to be ROM that nobody can modify, it seems to be flash/eeprom that can only be modified through an undocumented windows-only program
so rather than having an interface that would allow me to run an otherwise completely free OS, this opposition to the firmware blob ends up with me needing to boot/install windows to run a black-box firmware update tool for those (relatively rare) occasions when I really do need to update the firmware.
why is it that having a windows only program to update the firmware is considered _better_ than having the driver feed the card a firmware blob at boot time?
Free vs convenient Posted Oct 3, 2009 21:21 UTC (Sat) by man_ls (subscriber, #15091) [Link] I am sure if you ask Stallman he will say that proprietary interfaces to update opaque firmware should also be avoided. As a matter of practical fact, I am sure that people updating the firmware in their devices (not devices updating themselves) are comparatively rare, and most people prefer to just buy a new thing. (Note that I said comparatively; 1% of 3com routers can still be millions of people.)The point is that whoever can destroy the spice, controls the spice -- ehm, sorry, that whoever can modify the software, controls the software. It is easier to locate blobs that have to be uploaded every time than blobs that are updated seldom if ever, and thus it is easier to fight them. But what we should really require is to have no blobs on our desks -- in RAM, ROM or EEPROM. This is just a temporary phase to raise awareness, and the only step that can be done from the FSF that may have any impact. It is not the moment to ask for open ROMs, given the very limited uses they would have.
Free vs convenient Posted Oct 3, 2009 23:13 UTC (Sat) by nix (subscriber, #2304) [Link]
I suspect that people updating the firmware in their devices is
*vanishingly* rare, especially if those updates are persistent.
I never ever do it unless I encounter a bug that a new revision fixes,
Some BIOS vendors have fixed this by having a 'backup BIOS' in actual ROM
This has happened to me more than once, as a result of which I am now
Blobs that have to be uploaded every time have *none* of these problems.
Free vs convenient Posted Oct 4, 2009 13:32 UTC (Sun) by man_ls (subscriber, #15091) [Link] From my very limited experience with these things, I think that vendors have improved a lot. I bricked my first ADSL router uploading the wrong file (which it did not check at all -- it was a .txt for goodness' sake!). The next one was cleverer. The current model has a recovery mode where pushing certain buttons upon startup it will load the provided file as a firmware image; that part (the "bootloader") cannot be overwritten so it is always available. IIRC the NSLU2 has that capability too, and I believe the iPhone has a similar panic mode.Modern network-connected devices know how to upgrade themselves, generally require signed images, and the panic mode is there just in case something really bad happens. This auto-upgrading somehow negates dlang's argument about him deciding when to upgrade his firmware, and again tips the scales towards the vendor.
Free vs convenient Posted Oct 4, 2009 20:37 UTC (Sun) by nix (subscriber, #2304) [Link]
Network-connected devices, sure. What about your hard drive firmware? Your
BIOS? Your disk controller? All of those have upgradable flashable firmware in my latest machine, and only one (the BIOS) provides any sort of recovery if things go wrong --- and *that* requires me to dismantle the computer, turn it on with the case off, and flip a jumper. Hardly convenient.
Hardly convenient Posted Oct 4, 2009 21:08 UTC (Sun) by man_ls (subscriber, #15091) [Link] Scary, I didn't even know drives or controllers had updateable firmware. For these low-level components I am fairly sure it's as you say, a vanishingly small percentage of people ever reflash them. (And there isn't even the option to upload a binary blob from the OS to use them, since either the firmware is used before the OS or it would be needed to fetch the blob.)
Hardly convenient Posted Oct 4, 2009 22:46 UTC (Sun) by nix (subscriber, #2304) [Link]
Both have updateable firmware. My Seagate drives require (ick) a Windows
program to update the firmware: my Areca RAID controllers can be updated via their relatively icky (Linux statically linked closed-source 32-bit x86 binary) web proxy, or I think via their BIOS-accessible interface (higher-end controllers also have an Ethernet port but I bloody hope you can't reflash the firmware over that). If the update goes awry you could potentially reflash back to the earlier version --- *if* you have it somewhere accessible with your disks behind a dead controller, and *if* the updater still works in that situation, and *if* the firmware lets you downgrade like that. (All these facts are, of course, undocumented.)
As you suggest, uploaded blobs are a lost cause in both cases, but
Free vs convenient Posted Oct 5, 2009 15:35 UTC (Mon) by paulj (subscriber, #341) [Link]
I had a Yamaha SCSI 4416 CD-RW which I discovered had an emergency
firmware, after I made a mistake in my port of a firmware-writing utility. The emergency firmware could only speak SCSI and upgrade the firmware, it couldn't run the actual CDRW drive..
Free vs convenient Posted Oct 6, 2009 0:29 UTC (Tue) by nix (subscriber, #2304) [Link]
Oh good, some vendors have thought of this then (though it sounds like
they still haven't thought of documenting it).
Free vs convenient Posted Oct 6, 2009 1:28 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the FSF position is that it's better to have a proprietary firmware blob in flash than to have it downloaded by the driver.
it's not that they say they approve of the proprietary firmware blob in flash explicitly, but they do so implicitly by attacking the vendors that download the blob from the driver and recommending that people use the devices that have the firmware blob in flash with the closed source update tool.
Free vs convenient Posted Oct 6, 2009 1:49 UTC (Tue) by paulj (subscriber, #341) [Link]
There have been several comments now putting forth that the FSF prefer
ROMs to uploaded firmware. I'd really love to see a cite for this.
My own understanding is that the FSF would have users given the same rights
It seems like you (and possibly others) are taking that the FSF does not per se
Where does the FSF say they prefer ROM to uploaded firmware? I think a clear
Free vs convenient Posted Oct 6, 2009 2:11 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
The FSF doesn't say that it's preferable to have the firmware blob in flash/rom instead of ram, but it has been stated many times (including in this discussion) that it's _acceptable_ to have the firmware blob in rom or flash, but not acceptable to have it in ram. This has been done both implicitly (by only attacking vendors that have the frimware blobs in ram) and explicitly when challenged on this behavior. To me if one is acceptable and the other isn't, then the one that's acceptable must be preferred.
as for the claim 'users given the same rights as the manufacturers/developers', that's a nice sound bite, but I would argue that firmware blobs in ram already give the user more rights than the manufacturers as the user can decide at boot time which firmware to use. I don't see any way that the manufacturer can dictate that the user must update to a newer firmware blob. I have seen devices where one firmware has a feature that is removed in later firmware updates and users choose to use the older firmware to maintain them.
the OS developer may require it by requiring features/APIs that are implemented in the new firmware that weren't in the old one, but in my opinion that is not a problem as long as the features/APIs are documented any more than it would be to require firmware version >X for a device that has the firmware in flash/rom.
Free vs convenient Posted Oct 6, 2009 8:27 UTC (Tue) by paulj (subscriber, #341) [Link] but it has been stated many times (including in this discussion) that it's _acceptable_ to have the firmware blob in rom or flash, but not acceptable to have it in ram. So how is that a *preference* for ROM? As for this discussion, it's not quite clear to me who is speaking for the FSF and who is putting words in their mouth. (NB: I've nothing to do with the FSF, though I might have given them money in the past). as for the claim 'users given the same rights as the manufacturers/developers', that's a nice sound bite, but I would argue that firmware blobs in ram already give the user more rights than the manufacturers as the user can decide at boot time which firmware to use. I don't see any way that the manufacturer can dictate that the user must update to a newer firmware blob. I have seen devices where one firmware has a feature that is removed in later firmware updates and users choose to use the older firmware to maintain them. Well, there tend to be major differences in development attitude towards and the spread of its cost over the lifetime of a device, between devices whose working is hard to field-modify and those which are easy to modify. A hard-to-change device (ROM/most flash) will, on average, have had more effort put into development and QA prior to shipping. With an easy-to-change device (RAM/low-risk-upgrade flash), the vendor can afford to ship earlier obviously, and it will have more bugs initially. Basically the 2 cases are, given the economics, not quite as equal as you claim. The 2 cases may be poles of a spectrum, and there may not be a sharp dividing line between them, but clearly at one end the user is getting a reasonably unprogrammable "device" and at the other they're getting a programmable device whose development cycles the market is expected to experience, just like any other software. Why should firmware in the latter class be different from any other software, which the FSF would say end-users should receive source for? Now, I know, at present, it's not completely pragmatic to eschew soft- uploaded firmware, and I fully agree soft-uploaded for local-devices is much better. However, it would be nice to get a world where we all get the source to such firmware, surely? We can't all walk their path, but the FSFs' idealism surely helps achieve it? Pragmatically, the FSF do not object to *end-users* using closed, easy-uploaded firmware, rather they encourage users to *avoid* such hardware.
Free vs convenient Posted Oct 6, 2009 9:39 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
when someone lists a bunch of products and labels the ones with ram firmware blobs unacceptable and says to buy the ones with the firmware blobs in flash (usually with windows-only update tools) or rom instead that is clearly preferring the ones with the firmware blobs in flash/rom.
I would love it for vendors to make the source of the firmware available.
you claim that the FSF position will drive vendors to open the source for their firmware, however by telling people to buy the products with the firmware locked down to flash/rom instead of the ones with it in ram, I see the push moving vendors the wrong way. it's a lot cheaper and easier to justify shutting up the FSF by adding flash (possibly by selecting a different cpu that includes flash on the chip for the next revision) than it is to go through all the business/legal hassle of releasing the source (and for companies that have never done this before, it is a hard thing to do)
asking for the source of the firmware would be good, but the reality is that much of what is in the firmware of devices is third-party libraries that the companies do not have the rights to release.
we still haven't managed to convince the industry that the firmware blobs should be able to be distributed with the OS instead of having to be extracted from the windows drivers, getting that message through would be a lot easier than convincing the companies that they not only need to release control over the binary blobs, but also the source for them as well.
Free vs convenient Posted Oct 6, 2009 10:33 UTC (Tue) by paulj (subscriber, #341) [Link] when someone lists a bunch of products and labels the ones with ram firmware blobs unacceptable and says to buy the ones with the firmware blobs in flash (usually with windows-only update tools) or rom instead that is clearly preferring the ones with the firmware blobs in flash/rom. So you're taking practical advice, based on the current condition of shifting markets, and then extrapolating the FSFs general principled position from it. I'm not sure that's useful. E.g. at present there's a dearth of hardware with open firmware (though, some wifi is getting there with reverse-engineered firmware). If there were such hardware, it's more than reasonable to think the FSF would recommend it - therefore your "FSF recommends ROM over flash" extrapolation is clearly insufficient. it's a lot cheaper and easier to justify shutting up the FSF by adding flash (possibly by selecting a different cpu that includes flash on the chip for the next revision) than it is to go through all the business/legal hassle of releasing the source (and for companies that have never done this before, it is a hard thing to do) So we're all agreed on the principle that open firmware would be best, but you disagree with the FSF on how to advance toward that, right? The practicalities seems like something reasonable people could have lots of different opinions on. That said, I disagree somewhat with your premise that adding flash is cheaper than opening the firmware. I don't think that follows at all. If you believe that free software adds economic value over the long-term for both the users and the vendors (if you don't believe that it ultimately adds value to the vendors as well, then you believe free software is not sustainable), then clearly opening the firmware would be cheaper than adding to the cost of your device's BoM. This is ignoring the matter of just how much clout the free-software/free-firmware crowd have. we still haven't managed to convince the industry that the firmware blobs should be able to be distributed with the OS instead of having to be extracted from the windows drivers, getting that message through would be a lot easier than convincing the companies that they not only need to release control over the binary blobs, but also the source for them as well. You may have a point here about the practicalities of advancing this agenda. I don't think though that it helps to try read the tea-leaves of the FSFs binary- blob-avoid hardware lists so as to, almost certainly (IMO), mischaracterise their position. That seems divisive and counter-productive to a longer-term goal that, very likely, nearly everyone here shares.
Free vs convenient Posted Oct 6, 2009 17:54 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
in the long run I believe that open firmware would be best, but you do have to take into account industry norms.
right now the industry is just shifting from the firmware in flash/rom to the firmware in ram. the easiest political response to being attacked for firmware in ram is to move back to having the firmware in flash, not to have to convince lawyers and upper management to release the source.
I hope that this will eventually change, but right now it is still very hard to get the industry to release the source for things that they are clearly legally required to release. once complying with the GPL for derivative works and embedded code becomes normal the industry will start to loose it's fear and see some of the benefits. right now they are on the wrong side of things and so pushing them now moves them the wrong way
Free vs convenient Posted Oct 6, 2009 2:32 UTC (Tue) by foom (subscriber, #14868) [Link] > Where does the FSF say they prefer ROM to uploaded firmware? I think a clear> citation is important here.
http://www.fsf.org/resources
/hw/net/wireless/cards.html They list both cards that have built-in flash/eeprom/rom non-firmware and those for which free firmware has been developed, in the same list, without distinction. They tell you to avoid using the ones that require uploading non-free firmware, but don't mind listing a bunch that have non-free firmware hidden within the device. Since wireless cards are one of the only kind of devices available for which you even have the OPTION of using Really Truly Free firmware (which is because these devices having uploadable firmware and are thus easily and safely hackable!), I would at least expect a recommendation to only use those. But no. Non-free firmware that you don't see is apparently just fine.
Free vs convenient Posted Oct 6, 2009 2:38 UTC (Tue) by foom (subscriber, #14868) [Link]
> built-in flash/eeprom/rom non-firmware
I meant to say:
Free vs convenient Posted Oct 6, 2009 7:54 UTC (Tue) by paulj (subscriber, #341) [Link]
That doesn't say the FSF prefers ROM to uploaded firmware, afaict. Lets have
the rest of the discussion under dlang's reply to me.
Free vs convenient Posted Oct 9, 2009 14:10 UTC (Fri) by epa (subscriber, #39769) [Link]
I remember RMS saying he wasn't too concerned about the software running his microwave oven. OTOH, if microwaves came with a binary blob on a USB key that had to be loaded, we can be pretty sure RMS would refuse to use them ;-p.
Free vs convenient Posted Oct 4, 2009 2:26 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Except that's not the choice either. See the reverse-engineered open firmware for b43, for instance. The vendor's choice to provide runtime loadable firmware resulted in the development of a platform that allows people to perform research on 802.11 with a much lower investment than previously. While it would obviously be better if the vendor had provided open firmware in the first place, I'm pretty sure that this is preferable to people having to flash the firmware under Windows and risk bricking the card in the process.
Reloadable without penalty vs. great big buggy hurdle Posted Oct 6, 2009 1:03 UTC (Tue) by xoddam (subscriber, #2322) [Link]
+1 for sanity, and +2 for a real-world example.
When 'firmware' is obviously (from its implementation) loadable, replaceable software, and the procedure for loading it is well-specified and well-tested, that non-free firmware becomes a clear candidate for replacement by free firmware in the same way as compilers, editors and OS kernels were clear candidates for replacement by free software in the earliest days of the GNU project.
Ripping out the blobs is one way of pointing up the issue, but it isn't a solution to anything unless it is accompanied by efforts to obtain genuinely free firmware: by asking the people who already produce the firmware, or by encouraging development of free replacements.
If it's in flash or ROM, it won't occur even to most fairly brave hackers that it's a reasonable idea to tweak the blob, reverse-engineer it or rewrite it. Nor will it occur to anyone to ask for the source. But if it's in the Linux kernel as pages of hex constants, it's glaringly obvious that the source code is missing. The solution is to encourage reverse engineering and concurrently to ask nicely (and insistently, for years, with solid reasoning) for the complete corresponding source code. Surely?
It is to my mind far preferable in terms of end-user freedom to use RAM for firmware than any kind of ROM or rarely-exercised reflashing interface that risks bricking your hardware.
Blobs Posted Oct 3, 2009 8:12 UTC (Sat) by job (subscriber, #670) [Link]
As you point out, the issue is not just blob vs. eeprom, other aspects are more interesting: Is the blob freely redistributable or just by "Linux"? Is the blob non-mutable by some draconian US law? What about patents, do the blob carry an implicit license for them?
Even the question of eeprom has shades of gray to it. The device in itself is a black box and its inner workings unknown so non-free code inside it makes little practical difference for the programmer. But if you're supposed to send undocumented binary data as part of the API you blur it and makes programming unnecessary hard. It can be much worse than duming a blob as part of initialization.
I have respect for OpenBSD and the FSF for taking a simple stance on this issue. Not all blobs are equally bad but when you have an operating system with hundreds of drivers their rule of thumb probably helps.
Hit'n run Posted Oct 2, 2009 20:59 UTC (Fri) by foom (subscriber, #14868) [Link]
> it's like saying that current traffic laws encourage drivers to hit'n run, if they stop
> after an accident they can be fined and/or imprisoned
But Hit-N-Run is illegal, and has bigger penalties than hitting someone and not running.
On the other hand, as far as I can tell, the no-nonfree-firmware group of people don't care
These people consider the moving of the non-free software into an EEPROM as a
This is nonsensical. You are not removing the non-free software, but simply hiding it.
And at least if I'm carrying the mysterious blob, I've gone the first baby step towards
Hit'n run Posted Oct 2, 2009 21:20 UTC (Fri) by man_ls (subscriber, #15091) [Link] Of course, my bad-car-analogy was just an example of non-sequitur.FSF people don't care that devices have hidden code because it cannot be changed. But these people prefer the software to be modifiable by the owner. Just as in the non-sequitur example, the ultimate goal is not to stop at some intermediate level (distributing opaque blobs) but to get full source code so the software can be modified. Making the choice of free/non-free easier, or sweetening the non-free deal, does not put us any nearer that goal. In practice, having the distributed blob to study is no different than downloading an updated blob from a website. Sometimes compromises must be reached, but at other times refusing any such compromise is the way forward. Since here the FSF is not gambling anything, but just trying to encourage hardware companies to open up their code, compromises would be a bad choice: it would be unwise to recommend that they lift the kimono a little bit and let us peek, knowing that it is an utterly useless step.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 16:24 UTC (Fri) by paulj (subscriber, #341) [Link]
Read the comment you're quoting again, carefully. Where exactly does it say the
FSF argue for the 2nd? -> It doesn't.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 16:34 UTC (Fri) by paulj (subscriber, #341) [Link]
Oops, and by extension: Where do the FSF argue for what you say they do? (The
grandparent's summary seems closer to my vague understanding of the FSF's position than your summary).
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 9, 2009 14:05 UTC (Fri) by epa (subscriber, #39769) [Link] 1) EEPROM on the device that you can only write to from windows with a special firmware upload tool, and which only accepts signed-by-the-manufacturer-blobs.But that's not considered free-as-in-GNU either. AFAIK, RMS and his pals would like either (a) firmware with source code, where the owner of the device can install his changed versions; or (b) firmware in ROM, not changeable by anybody. If this sounds bloody-minded, it's just the same principle as copyleft has been intended to create all along, that of freedom-or-nothing; for example, RMS would rather emacs not be distributed at all rather than be distributed without giving the user freedom to change it, share it, and run the changed copy.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 9, 2009 14:12 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
In that case, why do the firmware-free distributions support hardware that has eeprom-based firmware? Shouldn't they only support hardware that has it in ROM?
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 9, 2009 22:41 UTC (Fri) by nix (subscriber, #2304) [Link]
I suspect a tiny bit of practicality enters here. How much hardware uses
actual ROM these days? Does any?
(For that matter, how much uses EPROM? I haven't even seen the acronym for
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 9, 2009 22:50 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Yeah, I tend to agree, which is why I don't buy this "Loadable firmware is worse" argument - there's a power imbalance between the vendor and you with almost all hardware you can buy these days, so if that's the motivation then drawing the line at loadable firmware seems like it's doing it wrong.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 10, 2009 6:26 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
lots of chips are available with ROM nowdays.
EPROMs are just about gone (the packaging costs for them make it such that flash is a batter deal)
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 9, 2009 23:20 UTC (Fri) by epa (subscriber, #39769) [Link]
I think it's not the job of the distributions to decide not to support certain hardware. Rather, they just don't want to include non-free software on the distribution CD. Whether to purchase such hardware is up to you.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 10, 2009 14:59 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Not only do they not include the non-free software, they also make it impossible to use the non-free software. However, they're entirely happy to let you use non-free software out of the box, as long as it's in an eeprom instead. They're even running non-free software by default in the kernel when they execute ACPI methods. I honestly just don't understand how these distributions do anything other than encourage vendors to move their non-free software to somewhere where it's more difficult for us to replace it.
|
|
||||||||||||