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."
I don't understand what companies have to lose by open-sourcing firmware or software that goes with hardware.
... right?
They make money on the hardware, not the software
...if only to see a pic of the guy who causes such a ruckus.
Otherwise, the interview is extremely tame. He alludes to the "corporate ways of Linux vendors", but doesn't give vent to any interesting rants.
De Raadt raises one interesting question, though, when he says, "in other cases we have had to resort to activism. An example of this was Qlogic...for a few years we did ship this code without being aware of the issue. But after a few mails to Art at Qlogic, and a threat to remove their code from our upcoming release, they decided to let us include the firmware in our operating systems."
The question is: how is this "activism"? He states that they used Qlogic SCSI firmware inadvertantly, and when asked to stop, threatened to comply with the request. That's "activism"?
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.
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
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..
Nothing stops you from downloading the source, building it on your own, stamping the binaries on CDROM and selling it.
Give them a break, a lot of OBSD fans buy the CD set just to show some support. And remember, at least as far as commercial use is concerned, it *is* free-er than GNU/Linux (not getting into whether that's desirable or not).
Go somewhere random
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.
Firmware is NOT linked with the linux kernel, so the GPL "mere aggregation" clause applies. Obviously, this is MHO, and this has already generated a LOT of debian-legal discussion.
:-)
YMMV HTH
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
[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.
"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
This comment is 100% stupid.
Creating an ISO image from an OpenBSD FTP download is pretty simple. With one simple FTP session and a subsequent mkisofs command you have a bootable ISO image with a full operating system that installs in minutes.
I have even written a small python script that will download a package and all of its dependencies so you can include it in your ISO image for easy access. Pretty simple to do if you know how the packages are laid out internally.
Sure, there is no full ISO to download, but all the pieces are there. Nobody forces you to buy anything. Feel free to create an ISO image and share it yourself on a private mirror or bittorrent. I'm sure those of us who want OpenBSD on a CD will either buy the official set to support the project or create their own.
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