Weekly Edition
Return to the Announcements page
| |||||||||||||||||||
|
| |||||||||||||||||||
FSF offers "GNU Bucks" for finding nonfree works in free distributions
## Free Software Foundation announces new bounty program, offering "GNU Bucks" for finding nonfree works in free distributions BOSTON, Massachusetts, USA -- Thursday, October 1, 2009 -- The Free Software Foundation (FSF) today announced that it will begin rewarding those who find and report any nonfree components in free software operating system distributions with public recognition and "GNU Bucks." The FSF maintains a list of guidelines covering what it means to be a free distribution, and endorses distributions that commit to meeting those guidelines. "By spurring users to find and report problems, this new awards program will help make sure that the FSF-endorsed free distributions of GNU/Linux stay really and truly free," said FSF executive director Peter Brown. "Ever since we published the guidelines for what it takes to be a free system distribution, we have been looking for practical ways to deal with the issue of nonfree software that is accidentally included in these distributions -- steps that are within our means and the means of distribution maintainers. This new program does a good job of striking that balance," said FSF licensing compliance engineer Brett Smith. Those qualifying for the award will receive a "GNU Buck" bank note, in the amount of pi and signed by Free Software Foundation president and "Chief GNUisance" Richard Stallman. In order to qualify for the GNU Buck award, someone first submits a detailed, actionable report about nonfree materials in a free distribution to both the FSF and the maintainers of the distribution. If the the report is confirmed, the person will receive an award and the option of public recognition. The FSF will also notify other free distributions to make sure they can address the issue as well. The awards follow in the tradition of the checks written by legendary computer scientist Donald Knuth to anyone who found errors in his seminal textbook "The Art of Computer Programming." To receive a check was such an honor that they were more often displayed on office walls than cashed. (Knuth stopped writing actual checks in 2008 due to check fraud.) A full explanation of the program is at <http://www.gnu.org/help/gnu-bucks.html>. For more information on the FSF's criteria for classifying a distribution as free, see <http://www.gnu.org/distros/free-system-distribution-guide...>. The full list of distributions meeting these criteria is published at <http://www.gnu.org/distros/free-distros.html>. ### About the Free Software Foundation The Free Software Foundation, founded in 1985, is dedicated to promoting computer users' right to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free (as in freedom) software -- particularly the GNU operating system and its GNU/Linux variants -- and free documentation for free software. The FSF also helps to spread awareness of the ethical and political issues of freedom in the use of software, and its Web sites, located at fsf.org and gnu.org, are an important source of information about GNU/Linux. Donations to support the FSF's work can be made at <http://donate.fsf.org>. Its headquarters are in Boston, MA, USA. ### About Free Software and Open Source The free software movement's goal is freedom for computer users. Some, especially corporations, advocate a different viewpoint, known as "open source," which cites only practical goals such as making software powerful and reliable, focuses on development models, and avoids discussion of ethics and freedom. These two viewpoints are different at the deepest level. For more explanation, see <http://www.gnu.org/philosophy/open-source-misses-the-poin...>. ### About the GNU Operating System and Linux Richard Stallman announced in September 1983 the plan to develop a free software Unix-like operating system called GNU. GNU is the only operating system developed specifically for the sake of users' freedom. See <http://www.gnu.org/gnu/the-gnu-project.html>. In 1992, the essential components of GNU were complete, except for one, the kernel. When in 1992 the kernel Linux was re-released under the GNU GPL, making it free software, the combination of GNU and Linux formed a complete free operating system, which made it possible for the first time to run a PC without non-free software. This combination is the GNU/Linux system. For more explanation, see <http://www.gnu.org/gnu/gnu-linux-faq.html>. ### Media Contacts Brett Smith Licensing Compliance Engineer Free Software Foundation +1 (617) 542 5942 <licensing@fsf.org> John Sullivan Operations Manager Free Software Foundation +1 (617) 542 5942 <campaigns@fsf.org> ### _______________________________________________ FSF And GNU Press mailing list <info-press@gnu.org> http://lists.gnu.org/mailman/listinfo/info-press (Log in to post comments)
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 0:17 UTC (Fri) by qg6te2 (guest, #52587) [Link] The FSF can offer all it wants, but how practical is it not to have firmware blobs ? As much as I support open source, my system would be useless without the blobs. And even if we had the source for the firmware, what exactly would we do with it, given that probably a bazillion hardware specific compilers would be required? PS. has Debian had their usual pre-release "debate" about firmware yet ?
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 0:50 UTC (Fri) by ewan (subscriber, #5533) [Link]
We've been here before. First it was "What's the point of a Free compiler when you need a proprietary OS to run it on?" then "What's the point of a Free OS if you need a proprietary browser to run on it?" and now it's "What's the point of a Free OS if you need proprietary firmware?"
Progress has been made, and progress is still being made - we're not all the way there, but it doesn't hurt to keep score in the meantime.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 3:32 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] The difficulty is that most of the devices that do not need non-free firmware blobs still have non-free firmware. It just comes pre-loaded.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 4:36 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Well, yes, but then it's effectively part of the device.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 7:22 UTC (Fri) by coriordan (guest, #7544) [Link] And we shouldn't let ourselves get stuck in a "can't be perfect so won't try" mentality.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 8:33 UTC (Fri) by epa (subscriber, #39769) [Link]
I believe the FSFite point of view is that if the firmware is on the device in ROM, then nobody can change it, so at least the owner and manufacturer of the device are equal. If it's a binary blob uploaded from software, then the manufacturer can make new releases but the user cannot, which makes it non-free.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 10:38 UTC (Fri) by ikm (subscriber, #493) [Link]
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. Well, whatever, Richard. I'm happy it's Linus who runs the kernel.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 11:45 UTC (Fri) by Zack (guest, #37335) [Link]
>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.
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 (subscriber, #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.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 0:52 UTC (Fri) by timschmidt (guest, #38269) [Link]
Similar things have been said throughout the development of Free Software. Firmware is just another layer of the stack beside applications and OSs. There are already numerous FOSS bootloaders (Qi, uboot, etc.), and several device firmwares (ath5k/madwifi fullmac comes to mind).
The push for completely-free distributions is not happening in a vacuum. There is a growing open hardware development community, and existing manufacturers are becoming more open daily.
Thanks to the efforts of these people, it will eventually be possible to use a reasonably modern machine in which all software and firmware are Free. And if we're lucky, and work diligently, the hardware on that same system might be documented down to each individual transistor.
Putting all possible information about a device in any interested person's hands will allow unprecedented levels scrutiny. Bugs will have nowhere to hide. And we would all benefit.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 7:32 UTC (Fri) by renox (guest, #23785) [Link]
>>Thanks to the efforts of these people, it will eventually be possible to use a reasonably modern machine in which all software and firmware are Free.<<
Maybe but not on x86 CPUs, AFAIK they all contain microcode which isn't Free..
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 18:02 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
I would be extremely surprised to find anyone who called microcode "software".
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 22:40 UTC (Fri) by dwheeler (guest, #1216) [Link] Be surprised. Microcode is software. Yes, it runs on a lower-level infrastructure. Yes, an initial version is typically built onto the device. So what? It walks like a duck, quacks like a duck, etc.; let's just admit that it's a duck.
If we're informed, we can do something Posted Oct 2, 2009 7:25 UTC (Fri) by coriordan (guest, #7544) [Link] When there were no distros trying to be 100% free, it was very hard for me to make good hardware purchases. Now when I want to buy a computer, I first check if gNewSense runs on it.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 8:27 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
I quite agree that a fully free distribution is not practical. On the other hand, it is often the "extremists" in all fields who help to move the field along for the more average people. (E.g. RISC processors. Nowadays, people have largely given up on them, yet look how many of their ideas have ended up inside a modern x86 architecture processor. Without all the "pure RISC" people over the years, modern non-RISC processors would be a long way behind what they are.)
fully free is practical Posted Oct 2, 2009 11:18 UTC (Fri) by coriordan (guest, #7544) [Link]
I use 100% free software - no binary drivers, no proprietary software - and I find it very practical.
15 years ago, people thought that using GNU/Linux as your real operating system was fun but not practical. We've made massive progress since then and there're just a few tiny corners left to free.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 14:25 UTC (Fri) by dbruce (subscriber, #57948) [Link]
"Fully free" may not be practical if you are trying to get gnu/linux running on existing hardware.
It may be practical when deciding what hardware to purchase.
It is definitely practical as a benchmark to hold up to computer manufacturers to see if they are really serious about supporting Free Software.
But I agree that for many users and many current computers, "fully free" will not provide the experience that will persuade them to adopt Free Software over proprietary software.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 8:50 UTC (Fri) by nix (subscriber, #2304) [Link]
In any case, even if the blobs were gone, code flows in both directions these days. My CPU executes both ACPI firmware code and code from the ATI ATOMBIOS, and as far as I know both of those critically important pieces of code are closed-source.
I dislike it, but how to fix it? This bounty program surely won't: it's trying to fix the opposite problem.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 9:15 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
In theory, I think that the OS - since it is the the one that decides what to execute and what not - could execute free replacements for ACPI routines, and only fall back on the firmware bits when it has no free replacement available. System boot and initialisation are more tricky though, short of replacing the BIOS.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 9:21 UTC (Fri) by realnc (guest, #60393) [Link]
The majority of distributions I know of support "freeness." They're not enforcing it, but support it; meaning that you have a choice to not install non-free software. The reason why a distro that enforces freeness is needed escapes me.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 10:37 UTC (Fri) by farnz (guest, #17727) [Link] A distro that enforces freeness is useful for two purposes:
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 12:44 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
Right. I stick with the default settings of my distro and only use free software from the main archive. If I need some non-free packages (Linus's sparse - the kernel code checker, documentation for gcc and other GNU packages, most firmwares) I install them explicitly from non-free.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 14:01 UTC (Fri) by hppnq (subscriber, #14462) [Link] If I need some non-free packages (Linus's sparse - the kernel code checker, documentation for gcc and other GNU packages, most firmwares) I install them explicitly from non-free. The term "non-free" here corresponds to your distributions interpretation of freedom. The FSF lists the OSL, which is used for sparse, as well as of course the GFDL under its Free Software/Documentation licenses.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 3, 2009 7:01 UTC (Sat) by tzafrir (subscriber, #11501) [Link]
The problem with the license of Sparse is, IIRC, the choice of venue clause: Assume I'm a poor programmer from Australia. Now let's assume that Linus has sold all rights to Sparse to EvilCorp and EvilCorp tries to prevent me from further developing the (free software) Sparse. One thing they can easily do is sue me for copyright infringement. Now I have to go half way around the world to defend myself.
This does not really make the software non-free, but makes it possible for the oopyrights holder to block some competing forks, which is not a good feature.
As for the GFDL: "thou shalt not remove my sacred text from those technical documents". Whatever. When I need GNU docs I just use the FSF web site. That method of "distribution" method is mostly good enough for me for now.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 14:06 UTC (Fri) by hppnq (subscriber, #14462) [Link] The reason why a distro that enforces freeness is needed escapes me. Because then you can say "I think this is free" and "I think that is not free". Then we don't need to reinvent to concept of "freedom" as "freeness".
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 9:57 UTC (Fri) by josh (subscriber, #17465) [Link]
ACPI tells you things about the hardware that you could potentially already know, such as how to put the processor into sleep states or lower frequencies. And video BIOS code has become increasingly irrelevant with the modern trend towards native modesetting; certainly the Intel driver doesn't care about the video BIOS anymore, as far as I know.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 13:19 UTC (Fri) by nix (subscriber, #2304) [Link]
Video BIOS code has become *more* relevant with new ATI cards. ATI has always had a habit of tweaking cards in minor ways without changing the model number, and in the past (as tialaramex says) this has led to proliferating forests of conditionals in the ATI drivers.
The atombios promises to fix all that, as ATI provide instructions (in a special language interpreted by the driver) on the card specifying how to do things on *this actual hardware*, changing it in lockstep with the hardware. The only downside is that no source is available for any of those instructions. (Whether anyone cares is another matter, as the execution of these instructions *is* under our control, and if we don't do roughly what the atombios says the card won't work --- but why it's requesting that we do particular things may remain mysterious.)
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 16:38 UTC (Fri) by josh (subscriber, #17465) [Link]
Glad I use Intel graphics rather than ATI then.
The Intel driver has a huge pile of quirks for random hardware as well. Replacing the functionality of the firmware tends to require that, since you can't rely on the firmware to handle the quirks for you. Relying on the firmware does generally prove easier than implementing the functionality directly. It sounds like the ATI driver, despite doing modesetting itself, chose to rely on the firmware to solve part of the problem for it.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 3, 2009 20:55 UTC (Sat) by elanthis (subscriber, #6227) [Link]
The radeonhd driver went the route of manually coding all the modesetting information. They changed their mind. In the end, it is just an unmaintainable mess of crap that nobody can figure out and nobody can keep up to date with all the tons of hardware revisions out there.
Intel has a very small graphics card line up. Intel's GPUs are weak and under featured. Intel's GPUs don't have to deal with a ton of different bus types because they're all IGPs (you don't have AGP, PCI, PCI Express, PCI Express 2.0, and so on all supported by the same chip).
Practicality wins. Letting anything get in the way of practicality is foolhardy and only hurts the Free agenda -- you can't get users to switch to Free software if all the Free software is junk and doesn't work as well as the proprietary stuff.
Sometimes there are trade-offs between Free and practical. The FSF errs on the side of Free, but I believe that is a huge mistake. Err on the side of practical and work towards Free and you'll get to your target goal much faster. Companies, and most users, only care about practicality, so it's going to be easier to get them to switch to Free BIOS and microcode if you prove to them why its better than if you say "this tiny little majority of users that has next to no financial impact on your business refuses to buy your hardware unless you acquiesce our demands."
The FSF has always been pretty dumb about getting its word out, though. The entire "Free Software" nomenclature is all the proof you need that the FSF is horribly lacking in any kind of marketing common sense. The only way to educate users about Free Software is to include three paragraphs of explanation over and over and over in every possible place you mention Free Software, because if you don't, users' initial interpretation of the term is going to be "software that has no cost." Because that's what the term freaking means in plain English without the vernacular. If RMS had used a less ambiguous term (like Open Source before it got coined for a different purpose, or even Libre Software, or so on) the situation would be better. Users seeing the term "Open Source" are more likely to understand the concept right away, and those who don't understand it are far less likely to assume it means something different. It's a better term from a marketing standpoint, and hence is a far better term from an evangelical/user-education standpoint, and that in no small part is why the term Open Source is used far, far, far more often by most people than Free Software, even when those people actually are talking about Free Software and not the looser definition of Open Source. If you have to explain a term over and over and over to every single person you mention it to, it should click in your head that the term is stupid. RMS and the FSF are more interested in their words than they are in spreading their actual meaning, it seems.
The same goes for GNU/Linux. People aren't going to use that because the term is ugly. It's long. It's hard to pronounce. People don't go around saying "I run Microsoft Windows Vista." They say "I run Vista." Same for XP, or ME, or 98. We use the shortest term we can. And good marketing people pick terms that sound good. "GNU" is a bad choice because the entire name is based on a horrifically stupid joke that nobody outside of socially-inept 1980s computer nerds ever laughed at, the word practically has to be spit out of your throat, and it doesn't sound "cool" or even "pleasant" in any way. Linux isn't a perfect choice, but it's a far better name than GNU, because it rolls of the tongue and sounds kind of neat (I'm not sure why anything with the letter X is automatically hip... silly Americans). No true Free Software proponent in their right mind is going to advocate the use of the term GNU/Linux everywhere because the only thing that will accomplish is making the platform harder to market and hence harder to get new users on and hence fail to spread Freedom as far and fast as it could.
If RMS and the FSF really care about spreading Freedom, they have to realize that it's more than just screaming as loud as you can and badgering people into listening to you. You have to make people _want_ to listen to you. And that starts with making sure that what you're peddling looks and sounds attractive, so that people come looking for you to find out what you're all about instead of you having to go slam your fist down people's throats to get their attention.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 3, 2009 23:06 UTC (Sat) by nix (subscriber, #2304) [Link]
Sir, I object! I was a socially-inept 1980s computer nerd and I didn't
think the GNU recursive-acronym name was a terribly good one. (Mildly amusing, yes. Great? Hardly.)
Socially-inept *1970s* computer nerds, on the other hand...
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 6, 2009 14:04 UTC (Tue) by nye (guest, #51576) [Link]
Your post was fairly unfocussed, but there are two points I'd like to pick up on.
First, is that the FSF has always been thinking more long-term than most of its opponents. There are constantly complaints made that the FSF's methods and ideals are impractical, where the implicit meaning is 'impractical *in the short term*'. The FSF's positions are entirely practical over terms more like a decade or two - in fact, they're far *more* practical over that length of time than the 'pragmatic' positions of today. Sure it wouldn't be reasonable for *everybody* to follow the FSF position, but we need *somebody* to take that line, in order to progress. Too many people forget that it's worth sacrificing a pawn today if that means taking the opponent's queen in five moves' time.
The second point is about the naming. You say that nobody uses the term 'Microsoft Windows Vista', and in a sense that's true - most reasonably savvy people are likely to say they're running 'Vista'; the others might just say they're running 'Microsoft', if you're lucky. But take a look at anywhere it's written down by an organisation - you'll almost always see 'Microsoft(R) Windows(R) Vista'. The point is that it's an unfair comparison to compare a colloquial name with a 'full' name. Also, the 'GNU/Linux' business has become a lot more meaningful recently, since we now have non-GNU Linuxes (notably Android), which kind of ties in with the first point because the FSF preëmpted that issue by quite some time.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 6, 2009 15:45 UTC (Tue) by foom (subscriber, #14868) [Link]
> First, is that the FSF has always been thinking more long-term than most of its opponents.
For that to be true, in this case, I want to see them decrying the evils of non-free *embedded*
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 6, 2009 17:40 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
exactly, if they were decrying all non-free firmware I would agree with their goal (even if considering it a bit of tilting at windmills still), but with their emphasis being only to attack firmware in ram and directing people to buy devices with the firmware in flash/rom instead I see them as activly harmful to their stated goal
Newspeak Posted Oct 10, 2009 14:56 UTC (Sat) by anton (subscriber, #25547) [Link] Free Software, because if you don't, users' initial interpretation of the term is going to be "software that has no cost." Because that's what the term freaking means in plain English without the vernacular.Ah, Newspeak has taken over. From the appendix of 1984: To give a single example, the word free still existed in Newspeak, but could only be used in such statements as "The dog is free from lice" or "This field is free from weeds." It could not be used in its old sense of "politically free" or "intellectually free," since political and intellectual freedom no longer existed even as concepts, and were therefore of necessity nameless.The difference is that Newspeak is now called "plain English" and in our commercially dominated world "free" was redefined to mean "has no cost". Interesting that Orwell did not think of that.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 4, 2009 16:35 UTC (Sun) by alankila (subscriber, #47141) [Link]
To me, it seems like a nobrainer to just execute the atombios bytecode. Why are they fighting against it?
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 4, 2009 20:41 UTC (Sun) by nix (subscriber, #2304) [Link]
Who's fighting against it? Nobody that I can see. radeon and radeonhd both
use atombios stuff now. It's just somewhat disturbing 'cos we don't have the source to this stuff.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 4, 2009 22:31 UTC (Sun) by alankila (subscriber, #47141) [Link]
Right, they have come into their senses. Well, no argument from me then. Can't care about the missing source, all that matters is that it's a documented interface. Until you have a PC made out of open chip schematics there'll always be a layer of closedness behind you anyway.
It just struck me as odd that there's a company trying to engineer a generic solution for getting hardware and software to cooperate without pushing a lot of complexity into every driver, and people would object to that rather than understand that the hardware was just trying to be helpful.
I mean, open source is nice and all, but it's a bit strange to treat the hardware-supplied code in ATI cards implementing some sort of defined interface as suspicious when you know that you can't get it right yourself without executing that code and tracing what it does, anyway. Which takes time & iterations with people who have each kind of hardware.
I was just thinking that maybe the interface was somehow inconvenient to use. If the sole reason is that it's closed-source, then that's pretty insane. You're picking a "guaranteed to fail" approach over "might even work".
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 5, 2009 0:37 UTC (Mon) by josh (subscriber, #17465) [Link]
Yes, your reaction sounds perfectly sensible from the perspective of someone who only sees freedom as a means to an end for obtaining better quality software. I acknowledge that that viewpoint leads to different tradeoffs. Others, including myself, value the freedom itself for reasons beyond simply believing it will produce better code.
In any case, even from a purely practical perspective, firmware interfaces have proven notoriously buggy in the past, and I have no reason to believe that this interface will prove any different. Having the ability to fix the firmware would provide a practical benefit.
As for your comment about always having some layer of proprietary bits underneath everything: valuing Free Software as a principle does not preclude having enough practicality to value something more Free over something less Free, without requiring immediate perfection.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 5, 2009 22:55 UTC (Mon) by alankila (subscriber, #47141) [Link]
You are correct in observing that I'm not ideologically interested in free software.
Since the firmware code is interpreted by the CPU it is in practice fixable/workaroundable if there are problems. You just have to blacklist the pci-id, maybe checksum the methods, or whatever, to identify bad code and run something else instead (if you can discover what works). Something in this spirit is probably done with buggy ACPI code too.
Otherwise it's just an engineering tradeoff. Your goal is to make a stable hardware API that works the same regardless what GPU your board has, so that a new GPU can work with older version of drivers as well. The way ATI people went about to gain this goal was to have the GPU supply command stream for the CPU to interpret, rather than implement some region of memory that can be written to and is interpreted by the GPU to perform equivalent effect. To me, both solutions look pretty much identical. The AtomBIOS code should not be treated as non-free software, it's just instructions to drive the hardware supplied by the hardware to fill the contract of a stable hardware API.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 10:20 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
The CPU doesn't execute either of these, or no more than it executes SVG in a web page.
In both cases they let the manufacturer include instructions for a virtual machine that show how to operate the precise bit of hardware you own, and it's then up to you / the OS how and when to use these instructions. For one thing, this means that ATOM is portable (ACPI less so, but then it does fiddle with stuff at a pretty low level) and so we don't face the prospect of being told that we can only make "free" drivers for a single platform.
In the past there have been free drivers for hardware with ACPI or ATOM that ignored the provided instructions, and they were lousy in various ways. For example, attempts to do modesetting on newer ATI chips without ATOM meant that hundreds of individual users had to write in with the results of running some test code and they'd created this huge spaghetti of conditional code, the exact scenario ATOM was intended to prevent.
I think the "not free enough" stuff eventually comes up to a place where they're not just asking for the schematics, but to sit in on the design meetings, to follow the engineers into the breakroom, to sift through their emails and interview them. Why is this method named 'resetC5' ? Why is there a 10µF capacitor here on the board?
If you imagine only one ATI card existed, and someone wrote the ATOM firmware out as a series of dry engineering notes (to set mode A, do X, Y and Z with the parameters from table 116) would we really be demanding an explanation for how the figures in table 116 were derived? I don't think so. It's human nature to want to see behind the curtain, but beyond a certain point I think this curiosity isn't about "freedom" any more.
Now, if you want something insidious that really does run on your CPU, look at System Management Interrupts. SMIs are "transparent" to the OS in the sense that you usually can't or mustn't (warranty voided) switch them off but they eat cycles, which equates to time. The OS loses control, some arbitrary vendor defined stuff which might have bugs happens, and then you get control back. Did it tweak the fan speed, or write your password to a secret flash device? No way to know.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 13:15 UTC (Fri) by nix (subscriber, #2304) [Link]
All agreed: this isn't execution in the sense of "here's machine code, now run it"; it's execution in the sense of "here's uncommented virtual machine instructions, now execute them". This is plainly better than SMI because the kernel can stop the instructions doing stupid things and can keep track of what they're doing and decide to do something else... but still the VM instructions are uncommented and not in the form they were written and no source is available. i.e. they're closed source code run on your CPU.
(Even worse than eating time, SMIs can change the state of parts of the system other than the RTC and not tell the kernel about it. This is terribly dangerous and I'd not be surprised to find it implicated in intermittent kernel crashes.)
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 2, 2009 11:17 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] PS. has Debian had their usual pre-release "debate" about firmware yet ? No, I've been working to separate it out. This should be complete once we upload 2.6.31, certainly in time for the next release.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 10, 2009 15:11 UTC (Sat) by anton (subscriber, #25547) [Link] how practical is it not to have firmware blobs ?For some reason we recently built a 2.6.30 kernel from the Squeeze Debian source package and installed it on several Lenny systems. After some time I noticed the following in the dmesg output: [drm] Loading R500 Microcode platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin radeon_cp: Failed to load firmware "radeon/R520_cp.bin" [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!I had not noticed anything missing from any of the machines at the time. Later I noticed that I don't get 3D acceleration on that card, but I don't care. So it's obviously practical not to have some firmware blobs. According to another comment here the separation is not yet finished, so I cannot comment on not having any firmware blobs. Debian packages the firmware blobs in separate packages in the non-free section, so it's still there for the less virtuous among us.
FSF offers "GNU Bucks" for finding nonfree works in free distributions Posted Oct 10, 2009 21:41 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
it depends on the hardware.
sometimes (like your radeon video card) if you don't use the firmware blob you can use the hardware in a degraded mode.
however, most of the time if you don't use the firmware blob you just can't use that hardware at all.
A brave GNU world Posted Oct 2, 2009 12:46 UTC (Fri) by mheily (guest, #27123) [Link]
In our brave GNU world, an operating system is considered "free" only if it restricts the ability of it's users to install the software of their choice. The freedom not to install is more important than freedom of speech, so operating system distributors must be censored. You can't tell anyone that their 3D game will work better with the NVidia binary-only driver for Linux. In fact, even you can't even mention that the NVidia driver exists. Who knows what horrible things would happen if users were allowed to install Microsoft Visio under WINE, so you can't tell people how to do that.
Censorship is free speech. Restrictive licenses give us choice. Welcome to the brave GNU world!
A brave GNU world Posted Oct 2, 2009 13:20 UTC (Fri) by clugstj (subscriber, #4020) [Link]
If you are claiming that your distribution is "free" according to the FSF definition of free, why shouldn't the FSF be able to point out when you are not telling the truth? If you disagree with the FSF's philosophy, you are also free to ignore them.
Bait accepted Posted Oct 2, 2009 20:42 UTC (Fri) by man_ls (subscriber, #15091) [Link] If you do not use one of these distributions, and since nobody is forcing you to use them you have a choice of multiple other distributions, why does it bother you so much what other people choose to run on their systems?
A brave GNU world Posted Oct 3, 2009 18:19 UTC (Sat) by gmaxwell (subscriber, #30048) [Link] only if it restricts the ability of it's users to install the software of their choice Got a citation for that? There is a big difference between "restricts the ability" and "doesn't nag you to install" as well as a difference between that and "silently includes it by default". I'm sure the FSF wouldn't endorse anything that encouraged you to install proprietary software but I'd expect them to be equally opposed to restrictions which kept you from privately using your computer however you wanted even if the thing you wanted it something they think you ought to avoid.
A brave GNU world Posted Oct 8, 2009 14:05 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
The FSF's favoured distribution, gNewSense, not only removes sourceless firmware from the kernel (along with many initialisation tables that are arguably "preferred form for modification") but also prevents loading non-free firmware (see http://www.fsfla.org/svn/fsfla/software/linux-libre/scrip...).
A brave GNU world Posted Oct 9, 2009 11:10 UTC (Fri) by pboddie (guest, #50784) [Link] The freedom not to install is more important than freedom of speech, so operating system distributors must be censored. The FSF chooses to promote those distributions that best fits their ideology. Once again we see the perversion of basic terminology (something is apparently "censored" if another party is "unwilling to advocate" that thing) by people who think that ridiculing organisations like the FSF for expressing their views somehow furthers the agenda of their favourite flavour of Free Software licensing. Accusing the FSF of "coercion" (which upon further investigation actually refers to someone "voicing an opinion" to which one need not listen) is the only thing missing here - although it is implied - despite Microsoft having its products bundled on almost all systems available through mainstream retail channels. But then I suppose some people believe it still to be fashionable to frame the FSF as antidemocratic (using Newspeak-style rhetoric - how creative!) while ignoring the more blatant injustices.
|
|
||||||||||||||||||