Weekly Edition
Return to the Announcements page
| |||||||||||||
The FSF's hardware endorsement program
The Free Software Foundation has announced an
initial set of
criteria under which it would endorse hardware as "respecting freedom."
"The FSF's criteria seek to cover all aspects of user interaction
with and control of a device: they say the hardware must run free software
on every layer that is user upgradeable, allow the user to modify that
software, support free data formats, be fully usable with free tools, and
more."
(Log in to post comments)
The FSF's hardware endorsement program Posted Oct 14, 2010 15:01 UTC (Thu) by davide.del.vento (guest, #59196) [Link]
This sounds great!
The FSF's hardware endorsement program Posted Oct 21, 2010 10:13 UTC (Thu) by dion (subscriber, #2764) [Link]
How? How, exactly does this sound great?
It's one thing to disallow "Works with Linux", it's quite another level of to crazy to disallow "works with windows" and "works with mac" badges as well.
A hardware vendor is primarily interested in selling widgets, if slapping a "Works with Linux" badge on the box will help sell a few percent more widgets they will do it and the customers will be a little bit happier.
No hardware vendor is ever going to take off the windows and mac badges to appease FSF and get the coveted "FSF GNU WTF" badge that none of the customers know to look for.
The FSF's hardware endorsement program Posted Oct 14, 2010 15:39 UTC (Thu) by pabs (subscriber, #43278) [Link]
Very interesting to see how it compares with the most recent draft of the Open Source Hardware definition document:
http://freedomdefined.org/OSHW
Might be good to see these two groups connect to strengthen each of their definitions so that OSHW requirements also ensure compliance with the FSF hardware endorsement criteria and that the FSF criteria encourage endorsed hardware to be also in line with the OSHW definition.
Nitpicking Posted Oct 14, 2010 17:01 UTC (Thu) by bjartur (guest, #67801) [Link]
The FSF insists on censoring interviews about endorsed products, so people won't be mislead by references to "a system with the Linux kernel". --- Why isn't the @title attribute allowed on <q>? Marking up emphasis this way feels wrong.
Nitpicking Posted Oct 14, 2010 17:29 UTC (Thu) by endecotp (guest, #36428) [Link]
> the seller must talk about "free software" more prominently
> than "open source."
Yes, it seemed reasonably sane up to that point. I was thinking about the Ben NanoNote, for example. But frankly I wouldn't want to agree to something that restricted my freedom to say what I wanted in an interview. Ooops, I just said my NanoNote "Debian" instead of "Debian GNU/Linux", now I have to go and peel off all those "approved by FSF" stickers....
I was also a bit annoyed by the FPGA and microcontroller exclusion:
"The exception applies to auxiliary processors or low level processors, none of whose software is meant to be installed or changed by the user or by the seller. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or code compiled into an FPGA."
So is the FSF the "Free high-level software foundation" now? I'm thinking of one particular box that I have repurposed which has an ARM Linux SoC (oooops, sorry, an ARM BusyBox/Linux system), a PIC, and a Xilinx chip. I modified two out of three of them.
Nitpicking Posted Oct 14, 2010 17:34 UTC (Thu) by josh (subscriber, #17465) [Link]
I don't think they've excluded those things in general, just if no mechanism exists for the user to change them on a finished product. So, if you have the ability to upload firmware to the device at all, then Free firmware must exist, but if the device has firmware burned into it at the factory that the user can't upgrade, then I think the FSF thinks of that more like a part of the hardware, where they would like freedom but don't consider it reasonable to demand it yet.
Nitpicking Posted Oct 14, 2010 18:30 UTC (Thu) by endecotp (guest, #36428) [Link]
Say I have designed a system that's running Linux on a main processor and some assembler that I've written on a microcontroller, and I keep the source to the microcontroller's code secret. I believe that I could get FSF approval for that, as long as I designate the microcontroller as "not meant to be changed by the user"; it would then not count as "product software" as they define it. Whether or not a method for replacing that code exists isn't mentioned as a factor in their rules. What they do say is that if free software for the microcontroller "becomes available" (presumably from a 3rd party, who has reverse-engineered my code), then I have to "adopt" it in the next version of the product. (I think "adopt" means "use", but I'm not sure.)
It definitely looks to me as if they're applying different standards to different kinds of software, without good reason.
Nitpicking Posted Oct 14, 2010 22:27 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
So a tivo that required you to send it in to the factory to change the linux install on it would not require you to provide the linux source code?
Nitpicking Posted Oct 15, 2010 7:46 UTC (Fri) by anselm (subscriber, #2796) [Link] I was under the impression that, according to the FSF, »non-upgradeable« meant »non-upgradeable for the manufacturer as well as the user«. If you need to send the Tivo to the factory just so the manufacturer can use their own special secret utility to upload a new Linux version, I don't think that is what the FSF has in mind. On the other hand, if upgrading the software involves unsoldering and replacing read-only firmware chips, or swapping the complete motherboard of the device for a newer version, that might be something else again.
Nitpicking Posted Oct 15, 2010 9:47 UTC (Fri) by endecotp (guest, #36428) [Link]
> if upgrading the software involves unsoldering and replacing
> read-only firmware chips
Well that's a great example of the double-standards. I have a soldering iron and a computer on my desk; if I have to spend an hour using the computer to change the code that is OK, but if I have to spend ten minutes using the soldering iron to achieve the same goal, that's not OK.
Nitpicking Posted Oct 15, 2010 12:49 UTC (Fri) by pbonzini (subscriber, #60935) [Link]
That's because the FSF considers anything soldered as equivalent to hardware rather than software. It's definitely a double standard, but you can expect that given their name is Free _Software_ Foundation.
Nitpicking Posted Oct 15, 2010 18:24 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
I'm pretty sure that if someone were to load a full linux distro into ROM and put it on a system and then not provide source there would be many people up in arms about the violation.
but according to the FSF, if this is something that needs a soldering iron to change it's acceptable.
Nitpicking Posted Oct 15, 2010 19:10 UTC (Fri) by josh (subscriber, #17465) [Link]
The FSF's hardware endorsement criteria have nothing to do with whether you can violate the GPL on some piece of software just because you've burned that GPLed software into a ROM. The hardware endorsement criteria just have some rough, pragmatic statement of when the FSF considers some piece of software too much like hardware to demand source for it: namely, if nobody can change that software on a shipped product anyway. That doesn't mean they don't want that software, like all other software, to provide freedom to its users; it just means that they have a pragmatic understanding of what they can actually ask for. These endorsement criteria already require that a system have a Free Software BIOS, loadable firmware, and so on.
Nitpicking Posted Oct 15, 2010 21:12 UTC (Fri) by endecotp (guest, #36428) [Link]
> nobody can change that software
No, that's not what they say; the criteria is:
" ...except for certain microcode and firmware.
Not "nobody can change", but simply "not meant to be changed" (meant by whom?), and has to be a "low level processor".
(Note that the linked text is evolving...)
Nitpicking Posted Oct 15, 2010 21:23 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
you already note that "not meant to be changed" is very imprecise, but at the same time "auxiliary processors" is also very imprecise.
I could argue that on a smartphone, the cpu running linux is the "auxiliary processor" and that the main processor is the one running the radio (this would still be non-free, but would again make it so that the source for linux wouldn't be needed by this nebulous criteria)
they either need to say that they don't care about device firmware (and then define it suitable, for Tivo, linux is the device firmware), or they need to not make exceptions for firmware that may be harder to modify.
Nitpicking Posted Oct 20, 2010 2:09 UTC (Wed) by man_ls (subscriber, #15091) [Link] I think that both conditions are meant to apply: "The exception applies to auxiliary processors or low level processors, none of whose software is meant to be installed or changed by the user or by the seller." So it must be an auxiliary (or low level) processor, and also its software must be non-serviceable. Not a smartphone by any definition.
Nitpicking Posted Oct 15, 2010 9:01 UTC (Fri) by njwhite (subscriber, #51848) [Link]
I generally agree with the FSF on the importance of good terminology, but I think they need to be really careful not to overstep the mark here.
After all, the software associated with most hardware should just be drivers, which will be kernel-specific. So it's that a free kernel, Linux, supports it. Of course any userland built on that kernel will likely to support it to, be it busybox-based, gnu-based, or whatever. But just saying "This video card respects freedom: works out of the box on systems with Linux 2.6.30+" seems more appropriate than "This video card respects freedom: works out of the box on newish GNU/Linux systems."
Maybe there's a happy middle-ground somewhere that everyone will be happy with.
Nitpicking Posted Oct 19, 2010 0:39 UTC (Tue) by andfarm (subscriber, #61973) [Link]
Ooh, and you're not allowed to have a "Works on Windows" badge on your product materials either (presumably they're thinking of the WHQL logo). This pretty much guarantees that most peripheral hardware manufacturers will write the campaign off immediately, as lacking the Windows certification badge on packaging material will make a LOT of buyers assume the product doesn't work on Windows at all.
|
|||||||||||||