On Tue, Oct 28, 2008 at 06:01:45PM +0100, David Weinehall wrote: [...] > some cases, the binary blobs *is* the source code; I've spent more than > enough time programming 8-bit directly from a machine-code monitor). And many people write non-modular programs; use non-usual constructs; do not comment their code; include pre-calculated constants. Is Debian going to remove a table of primes that were calculated and then stamped on code in an array, because the source code for the prime number generator was not made available? I'd rather have said source code if it, in fact, existed at all. People may have written a one-liner in some high-level code or did it by their hands or used some other tool already distributed by Debian. I guess it is just not feasible to verify all that. > As a bonus, an increasing amount of firmware these days is > cryptographically signed (cpu microcode, for instance), which means that > even if you had the source of the firmware, and the development kit, you > would still not be able to load the firmware onto your device. Which the GPLv3 tries to solve, stating that if the vendor can do it (the software distributed by the vendor in this case being under the GPLv3 license, of course), the user must be able to do it also. Even if that means providing the private key. > Now, I always prefer to buy hardware I can get the drivers for, > so both my laptops and my server uses Intel chipsets to and through. > The only things I don't have the sources for are: > > The CPU microcode > The iwl3945 firmware > > I'm 100% certain I wouldn't have any use for the CPU microcode sources, > I know this because the microcode is cryptographically signed, and thus > any modified version I could possibly produce won't be able to load on > the CPU anyway (and apart from that, I seriously doubt that there is any > means of editing it in a sane way available in Debian anyway) Again, this is not about what your computer use, but about what Debian distributes in its main section. > As for the iwl3945 firmware, I do not know for sure whether it's written > in C, assembler, or whatever else (I'm fairly certain it's NOT in some > obscure 8-bit CPU or similar). Personally I wouldn't mind having > the source code, but I do know, that if the choice is between either > having the firmware in EEPROM or having it as a binary blob, I'd take > the binary blob anytime. Some people have claimed this does not concern Debian, but I am for the Free Software Foundation fights, and fighting for free/libre "firmware" and hardware is worth, in my opinion. Anyway, Debian is about a free/libre universal operating system, and distributing non-free/libre pieces of "firmware" Debian knows there is unavailable better forms of modification would not be the perfect way of doing that. > I see firmware sources as a nice bonus in cases where it's written in > a language that we can actually modify and build using Debian tools. > I don't see it as a necessity. Throwing out the firmware doesn't help > our users, it makes things worse for our users. And our users are our > number one priority. Is it not providing them the best free/libre operating system? > The same could of course be argued for non-free software as well, but > the difference is that we can write replacements for the non-free > software. We don't have the option of replacing our users hardware. And why can't we write replacements for non-free/libre "firmware"? Is it because you don't consider reverse-engineering network protocols and file formats as hard as reverse-engineering hardware? And as someone else has compared hardware to network services, Debian does provide software that communicate with those just as Debian provides drivers that communicate with the hardware. But if Debian cannot provide a service software, does that mean Debian should exclude the access software? That would be an argument for the maintenance of the drivers, which I am for. But would Debian be required to distribute the service software? Debian does not provide the service software that will run in another machine, but if it did, it would comply with the DFSG to be in main. The same should be required from "firmwares". Debian does not distribute hardware to run "firmware", neither it does distribute the hardware to run "service software". > The closest we can get is to petition the hardware manufacturers for > specs or source code to the firmware, but if they don't answer, or if > they say no, we have to face he fact: our users are better off with > binary only firmware in Debian. Not in non-free. They are better off with free/libre firmware written by people who care about them. If it requires reverse-engineering, so be it. > For laptops running Intel chipsets, the most common wireless chipsets are > iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary > only firmware. With Intel's recent track record of releasing > sources, it's reasonable to assume that they would have released the > sources if they saw it as possible, so hoping for a source release seems > fairly futile. Write a replacement! Go for other hardware! Copy the firmware yourself if you have the author permission! But do not distribute non-free/libre software in Debian main! > Now, imagine Debian having this hypothetical yearly conference, called, > oh, let's say DebConf. During that conference we organise a special day > for our users, let's call it Debian Day. Lots of potential new Debian > users show up with their laptops and wants to install Debian. As the > kind souls we are, we hand out credit-card CD's with netinst images that > they can use with the WiFi available at the conference. > > Oh, but wait. They cannot access the WiFi, because their wireless cards > are not supported. Or rather, the drivers are available, but they all > report the same error message "Firmware not found". Happy, happy, joy, > joy. I'm sure those potential Debian users will feel really happy about > Debian's consistent policy that dictates that software running on > non-cpu == software running on cpu. They might not feel equally please The hardware manufacturer is at fault! Not Debian! > with the fact that Debian isn't consistent in its dedication to > prioritising the users though... I will try to be short in telling something about the history of education in my place. The government passed some resolution that students must be approved always. Well, some teachers interpreted that as that they should just give some grade to the student so they could "achieve" that. What they should have done was everything so the student would learn and not be able to fail. If Debian interprets that its prioritising of users' software and "firmware" availability is in favor of their freedom, why don't forget the DFSG and include whichever distributable work in main? Debian could tell them about the known issues with known hardware as well as tell them about known issues with known network services and ask them for help. > [snip] > > > Regards: David > -- > /) David Weinehall <tao@debian.org> /) Rime on my window (\ > // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire // > \) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/ > Regards, Cascardo.
Attachment:
signature.asc
Description: Digital signature