Strife and success in the land of open source
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.
License audit
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.