Slashdot Mirror


Theo de Raadt On Firmware Activism

An anonymous reader writes "KernelTrap has an insightful interview with OpenBSD creator Theo de Raadt, discussing their recent activism to try and open up wireless chipsets. In the interview, Theo discusses what has been accomplished so far, the difficulties involved, and why such efforts are important to all free and open source operating systems."

11 of 121 comments (clear)

  1. Re:100% Free? by RAMMS+EIN · · Score: 4, Informative

    The legal status of the official ISOs and artwork do not change the fact that the OS itself is 100% free.

    You can make your own ISOs and distribute them, do a network install (which, last time I did it, required just one floppy image and was very easy).

    It's all similar to Red Hat not allowing you to call copies of the official CD Red Hat, or vendors not releasing the latest version of their software under a free license. It doesn't make other distributions of the same software non-free.

    --
    Please correct me if I got my facts wrong.
  2. To keep average Slashdot reader on track... by codguy · · Score: 5, Insightful


    Since most Slashdot readers will not RTFA before commenting, let me clearly point out that this is *not* about wanting the companies involved to open up their source code for use by OSS. It is simply requesting that the existing firmware be freely distributable by OSS without onerous conditions.

    For A.D.D. and no-RTFA Slashdot readers/commenters, let me repeat that this is simply about being able to freely distribute an already compiled (e.g. binary) version of the firmware. OpenBSD is *not* asking for the source code.

    Loosely speaking, the firmware in question is already freely available--you just go to the website and download it. But that doesn't help when you are loading a distro. If you *only* have a wireless connection, this is a chicken-or-the-egg problem. You can't go to the website to download the firmware because your wireless NIC won't work without the firmware. Yeah, there are many possible workarounds, but by simply allowing the firmware to be freely distributable without onerous licensing terms, the wireless NIC can work right off the bat.

    Unless your foresight is amazingly shallow, or simply a Theo-hater, note that this will benefit *all* OSS, and not just OpenBSD.

    --codguy

  3. I hope that Linux&FreeBSD users will join by renoX · · Score: 4, Interesting

    Whatever one may think on Theo, I think that he is right here: firmware which cannot be redistributed by distribution are a *pain* for the users.

    I hope that Linux&FreeBSD users will join this movement because the more users requests hardware-makers to allow redistribution of firmware, the better!

    Also, I think that this movement should not be restricted to wireless HW, I have a speedtouch ADSL modem where there is a similar situation: firmware may not be redistributed.

    This is very annoying when you want to install a distribution.. I think that Mandrake managed to get the rights to redistribute this firmware, but they shouldn't be the only one to have this right..

  4. Re:Why not? by nbert · · Score: 4, Interesting

    IIRC it's not up to them, because some FCC rules prevent completely OS firmware drivers.
    The FCC is basically afraid that someone could modify the code in a way which would lead to a wlan device operating out of spec.
    But that's just what I read some time ago...

  5. Re:100% Free? by raddan · · Score: 5, Insightful
    Gimme a break. You can download the entire OS via FTP and make your own ISO. Even the OpenBSD installer doesn't care about the files, so you're not dependent on the 'official' ISO at all.

    The people who buy OpenBSD CDs don't do it because they're locked in or forced to in any way. We do it because we want to support a high-quality operating system. Considering that OpenBSD has replaced several costly Windows boxes where I work, the $40 for a CD is inconsequential.

    And, lest you forget, OpenBSD has a free-er license than Linux (don't get me wrong, I love and use Linux every day). OpenBSD's goal is getting high-quality software out there, not to free the world. You seem to be forgetting Theo's interview on Slashdot:

    The licence on our code is pretty clear. We want vendors to use our code. We want commercial operating systems to ship with OpenSSH. Not shipping with an SSH varient causes great grief, and it is time that ends.

    Same goes for OpenBSD. We would prefer if companies building commercial network appliances used OpenBSD, rather than writing their own operating systems. Typically, these companies are very comfortable with solving the problems within their application space. Yet, there is a history of these companies writing their own cruddy operating systems, and at the same time writing worse applications.

    It would be better if routers, firewalls, telephone switches, fileservers, and whatever else used reliable components, designed by people who care.

    So go ahead, use any parts of OpenBSD as parts of commercial systems.

  6. Re:Why not? by Simon+Lyngshede · · Score: 4, Informative

    Would you please stop this. They are not trying to get the companies to open source their firmware, they can't. The firmware determines the frequency of the wireless chipset, open sourcing it means you can change the frequency, which is illegal in most parts of the world. The OpenBSD developers know this and is therefor NOT trying to get the source code for the firmware, Im sure they wouldn't mind having it, but they know that it is impossible.

    What they are trying to do is to have the firmware release under a license, which will enable them to distribute it along with the operating system. They're aren't asking for anything but permission to ship the binary firmware. I am amazed by the number of people not getting this.

  7. Re:Why not? by Technician · · Score: 4, Interesting

    and they are approved by the FCC to operate on specific frequencies with specific power levels.

    It's like the days of CB radio. Early PLL sets had an easy to access PLL divide by N counter. Feeding it vales other than what the dial provided permitted illegal operation. Later to prevent lawsuits, the divide by N counter had a pre-programmed interface front end. The channel number was input and the divide by N was done internally. It made for more complex chips, but made out of band operation much easier.

    Some WiFi chip manufactures may have the same choices. The user interface software may take the chosen channel selection and set the chip PLL to the correct divide by N ratio. The advantage is if later the FCC opens more frequencies, a simple driver update will put the chip on the new frequencies. With OSS, renagades may ditch the FCC permitted channels and find a "channel" without neithborhood interferance and not seen by the wardrivers for additional security. The chip manufacture could be held liable for enabling the out of band operation. The chip manufacture could do like the CB radio chip manufactures later did and do the divide by N table in the chip instead of in the driver software.. Now you have a chip that can become instantly obsolete if/when the FCC opens more bandwidth. The chip costs more to manufacture to boot. In a comptetive market this is a bad thing.

    --
    The truth shall set you free!
  8. Open Cores? by cpghost · · Score: 4, Insightful

    [All chipsets] should be open. Really, it's very narrow-minded of the chipset manufacturers to not consider the possibility of people using F/OSS operating systems instead of propietary.

    All chipsets should be open. Really, it's very narrow-minded of the chipset manufacturers to not consider the possibility of dust or humidity settling or condensing on the open raw chip. Plastic cases are there for some reason, ya know?

    Now Open Cores would be great! But as long as we don't have a home chip manufacturing unit (say, like a printer or so), we won't be able to use the source code anyway (though some of us could find out about hidden functionality etc...).

    What we do need now are open specifications, both electrical and functional: What do you need to write to Pins 3-29 and what does the result on Pins 30-35 mean? This kind of stuff ought to be open!

    --
    cpghost at Cordula's Web.
  9. Re:Why not? by DoctorPepper · · Score: 4, Interesting

    I see your point, and you're half-right. The equipment is type-accepted to operate at a certain power level on a certain frequency, but there is nothing in the FCC regs stating that the firmware has to be closed source. After all, there is really nothing (except the fear of a hefty fine and/or jail time) preventing a person from buying a type-accepted radio at Wal-Mart and modifying it to put out more power, or to transmit on a different frequency band. These radios are not "black boxes", so neither should be the firmware.

    My own thoughts on as to why they are closed source leans more towards trade secrets.

    --

    No matter where you go... there you are.
  10. Re:Theo de Raadt at its best? by agent+dero · · Score: 4, Insightful

    "He created the currently most distributed free operating system, did he?"

    No, he created a kernel, he created a GPL licensed, monolithic and modular kernel.
    Linux is _just_ a kernel

    I'll have to stick by Theo on this one, there is a lot of whining about Nvidia binary drivers for their video cards, but that seems to be all it is, whining.

    Theo is doing something about it, whether or not you agree with his cause, he is _doing_ something at least.

    --
    Error 407 - No creative sig found
  11. Re:Let's push freedom aside for convenience. by ComputerSlicer23 · · Score: 4, Insightful
    When such firmware is built into the Linux kernel, that variant of the kernel becomes non-redistributable because one can't meet the terms of the GNU GPL
    Here you claimed to understand that this wasn't a matter of being a part of the driver.

    You are being silly. Go read up on the definition of "derived work" and "linking". Then read the GPL very closely. You'll notice that the firmware of a PCI card doesn't even execute on the same CPU architecture, let alone in the same address space (the rule of thumb amout if you are "linking" or not). When you get done figuring that out, realize that because the firmware was independently developed outside of the Linux kernel, and it works completely independently of the Linux kernel, it's not a derived work. Thus it's pretty much in the free and clear of all GPL issues. The actual binary bits in the kernel you are free to change to your hearts content with full GPL rights.

    That's why firmware can be inside of the Linux kernel now. Some people want to move it outside of the Linux kernel (for both technical and political reasons). The technical being, that you can upgrade the firmware without re-compiling your kernel, and it shrinks the size of the kernel to not have it statically compiled in. The political is that so dolts like you don't say "That's a GPL violation". It isn't. The firmware isn't a derived work, and it isn't a linking to a GPL'ed piece of code. It's just data as far as the kernel is concerned. Just like the C code that passes thru a GCC is just data. Yes technically speaking it is source code, but it's just data. It's just like saying, well in order to initialize this card, you have to write a "0x80" to this port to get it configured correctly. In this case, instead of a single byte, it could be a 10-64k chunk of bytes. It's the same thing. They are going to make it blazingly obvious by moving it outside of the source tree so it acts just like the GCC code does in every single way. Then we can finally be finished with this argument. That's why the 2.6 kernel is building all of the infrastructure so that firmware can be loaded from user space. Then as long as the vendors say the firmware can be distributed for free, it's all good (which is what Theo is attempting to make happen).

    Even if the OpenBSD and Linux people got the source to the firmware GPL'ed, there's no way in hell they'd ship source you had to compile. You'd still get a binary distributed to you. That would require you to have a development tool chain for whatever language (compiler for the language, assembler for the target architecture, and possibly a linker for the object format). Some or all of which literally might not exist outside of the company. It's not like Adaptec is using an x86 OBJ from C source for writting it's firmware. They might, but I wouldn't be shocked to find out they use a PIC with a propriatry C compiler from an embedded vendor. That would be a dependency the Linux kernel folks wouldn't allow for building a kernel.

    Kirby