COMMENTARY--For something that so many people claim to have an understanding of, open source sure appears to be misunderstood a lot lately. Not only do we have Microsoft's efforts to divide and conquer from the outside, but there's even sedition from within, with mud-slinging and accusation where neither is in any way necessary.
But even as various storm clouds formed, thundered, emitted rain, and then blew away, a much quieter success became apparent for the open source community, one which recalcitrant hardware vendors would do well to learn from.
The ipf tiff
As best I can tell, the whole disagreement around ipf and its license started when Darren Reed, the author of ipf, made a seemingly innocuous change to the license that ipf is release under. The act of changing the license drew attention and further scrutiny to it, and OpenBSD's Theo De Raadt concluded that the new license was not, in fact, an open source license, thus putting it in direct opposition to OpenBSD's licensing requirements.
After clarification from Reed, it seems that the license never was open source, and that ipf's inclusion into OpenBSD and the other *BSDs was probably ill-advised in the first place.
Unfortunately, this is the point when acrimony started. The gist of Reed's position is that it's his code and he can do with it what he pleases. Fair enough. However, Reed became clearly perturbed when De Raadt make the licensing problem public and subsequently removed ipf from the OpenBSD source tree.
The OpenBSD project has a history of making hard decisions like this and then delivering real alternatives. Investigation is already underway to determine as suitable ipf replacement for OpenBSD, though no plans have yet been set in stone. That said, code talks, and OpenBSD has spoken quite eloquently in the past.
Reed says he is in discussions with both the NetBSD and FreeBSD core developers with the intent of figuring out a way for those projects to continue using ipf if they want to. However, since Reed has stated his unwillingness to change ipf's license -- which is entirely his prerogative -- it's far from clear to me how NetBSD and FreeBSD can in good conscience use ipf given that the constraints of its current license are known.
De Raadt is now going through OpenBSD's source code and performing a license audit in order to guarantee there aren't any further inappropriate licenses lurking within. (This is particularly apt since OpenBSD regularly performs code audits looking for problems that can cause security vulnerabilities.) At De Raadt's prompting, Wietse Venema, author of Postfix and tcp_wrappers, has already changed tcp_wrappers's license to explicitly permit modification.
A quiet success
Fortunately, the land of open source software is not exclusively occupied with dissent these days. The release of OpenBSD 2.9, for example, brought with it an unheralded open source success story, one which will hopefully have ramifications for other open source OSes in the future.
Network interface cards are not inherently exciting bits of equipment. In fact, they border on the banal. Last December, I wrote about why OpenBSD meets my needs, and asked both Intel and 3Com why they weren't providing OpenBSD support for their crypto-hardware-accelerated Ethernet cards. OpenBSD and its security focus seemed a rather obvious symbiosis with this kind of card. At the time, both companies promised they would look into the matter.
It's now six months later, some things have changed, others have not. Intel PR did not respond to repeated requests for an update, and according to De Raadt, Intel never got in touch with them to start the ball rolling.
In contrast, while it took 3Com several months to get enough momentum going, it was able to provide the OpenBSD project with both documentation as well as the necessary firmware image to make the card work. As a result, OpenBSD 2.9 ships with support for 3Com's 3c990 card, albeit only in Ethernet-card mode, ie without crypto support. Yet.
Ethernet now, crypto soon
Work on crypto-support is well underway, and the results of these efforts will allow OpenBSD to use the hardware on the card to accelerate IPsec connections, though it unfortunately won't permit using the card as a system-wise crypto-accelerator.
The lesson (hopefully) learnt here is that if a hardware manufacturer is clueful enough to provide unencumbered documentation and any necessary tools and firmware to allow projects such as OpenBSD to do the actual software development, everyone wins, especially since -- thanks to the BSD license -- the hardware vendor can do what it wants with the resulting driver.
ZDNet columnist Stephan Somogyi pre-ordered his OpenBSD 2.9 CDs back in April and is eagerly awaiting its arrival.