Hi, Christopher Howard writes: > Hi David, I don't agree that just being given a redistributable blob is > any wonderful thing. What you end up with down the road (and this is > where we are now) is systems that need several (or many) blobs that only > the providing company understands and controls. Usually these blobs are > in control of critical or highly desirable functionality. You don't know > for sure what the blobs do or whether or not they have security > vulnerabilities. And sometimes the blobs come with restrict licensing > allowing distribution but not allowing you to reverse engineer. > +1. I don't see how having blobs helps security at all. David, you mentioned that having blobs could help manufacturers fix security issues (human errors) in their products; while true, this is a double-edged sword; it could also be used to insert spyware or whatnot, and very easily (simply release a new version of the blob for distribution, advertising it as bringing "fixes"). I think the FSF's position, as expressed in their "Respects Your Freedom" certification guidelines [0], is reasonable given the current state of things. Basically it says that "All the product software must be free software.", but grants some exceptions for software equivalent to hardware (e.g., fixed in ROM and non-upgradable) [1] and which runs on "secondary embedded processors" (which can include firmware built into I/O devices). For the time being, the hardware we use is closed. Just as we reluctantly accept to use non-free hardware for the time being, we can reluctantly accept to use non-free software which is equivalent to hardware. Whether the non-free firmware is stored as a loadable blob or in the ROM of a device doesn't change the fact that it's non-free. The subtlety is whether this firmware is used as hardware (upgradable) or software (easily replaced or extended). The later puts more control in the hands of the manufacturer, which is why the former is preferred. The RYF criteria page also states that they "want users to be able to upgrade and control the software on as many levels as possible.". In other words, a device with completely free firmware is more valued than a device with a closed firmware used as hardware, as it should be. Finally, preferring built-in, closed firmware to loadable blobs (closed firmware) could be seen as an incentive for manufacturers to release their firmware as free software (user-upgradable): releasing it as free software enables them to fix things (in a transparent manner) after the product is launched, which reduces risk (if the firmware is non-upgradable, the product could have to be recalled in case a serious problem is later found with it). > For firmware development to be practical, you want more than > documentation. You want source code. Also (for embedded development) you > want a tool chain. You might have the source code but find it near > impossible to build because you don't have a good tool chain. > The RYF criteria includes a "Compilation" (all the software must be buildable using free tools) and "Documentation", so this is at least summarily covered. > Yeah, with documentation, you might be able to engineer the source code > and tool chain... but it might take you 3+ years, and then only if > enough people are interested. And by that time no one will want the > hardware anymore. This isn't a moderately annoying problem for x86, but > it is a major problem for tablets, cell phones, and other embedded > development. > > The companies that should be the rewarded are the ones that release > firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100. > Indeed, we ought to put our money where our mouth is, i.e. back the companies which are helping the cause of free software/hardware. My two cents, Maxim [0] http://www.fsf.org/resources/hw/endorsement/criteria [1] The "fixed" part is not worded directly in the RYF criteria, but from the anti-tivoization clause found in the GPLv3, I would expect that this is how they would consider the matter.