Killing proprietary drivers for all Operating Systems

Be sure to read my legal disclaimer. Great. Now, if you've been hacking on the Linux kernel, FreeBSD, NetBSD, OpenBSD or any other open public Operating System kernel project you may at times have reached a point where you have had to deal with code written by a random silicon company. You'd have had to either review it, rewrite it, or massage it to conform to your groups' views of good code, a non trivial daunting task. Now, good code can be subjective but I argue that's a bullshit lame claim and one can mathematically prove what shit code is. Showing what bad code is through mathematics can be used to help alleviate yourself from the politics that you likely will be pegged for calling out bullshit nasty piece of shit code. When working with a large community you get used to people lashing out on your code, you need to grow a thick skin and grow comfortable with accepting public criticism to your work. Some companies have required code review policies but I don't think that these efforts will ever compete with the level of public scrutiny a good engaged community can provide. There is simply not enough resources, passion, and drive from corporate code review to compete, not matter what any PHB may say. Getting a community engaged is difficult however and the claim that all open code is good is simply false. What helps make a community engaged is difficult to iron out but its easy to spot. This post is not about what makes these communities well engaged or measuring them but simply to make the case that when you do have a good engaged community you will not be able to compete with the level of scrutiny of that community at your company.

I've dealt with reviewing / massaging company code a lot, not only for 802.11 but for video and random hardware concoctions. Given that I am part of a public community I can also engage with developers from other subsystems and also other public Operating Systems and from what I have talked about with every single developer its all the same: they agree, most company corporate code tends to suck. Guess who has to deal with fixing all that crap? Us. Its all shit and I'm tired of it and I want to put an end to this mess. On December 9, 2011 I declared war against proprietary drivers. Such a claim is easy to make but its really hard to fix this issue. There are a slew of politics in the middle, a bunch of historical baggage, and a huge set of legal misconceptions, and lets not forget community tensions around the idea of 'free software' and stupid claims of what operating system is better. Making the assumption that you will have the solution yourself to a complex problem requires serious delusions of grandeur and politicians keep failing at this same mistake and its why so many political promises end up not being met. This problem is best illustrated by Tim Hardford on his Ted Talk 'Trial error and the God complex'. My strategy then is to accept I cannot come up with the solution to the problem myself but instead start by reviewing the issue at hand with different parties both in the community leaders and anyone at companies who would lend me an ear to discuss and try to take a very different strategy, by first reviewing carefully existing failed strategies. Getting people to accept existing strategies as failed is difficult due to a huge slew of politics and frankly a line of PHBs in the way but also a plague of archaic cultural practices instilled in the industry in ways to support hardware and tensions around public community projects and legal FUD.

To even begin to try to address these issues would require engaging with folks that likely disagree with me philosophically and who would never be afraid to make claims that disagree with your own points of view. I joined forces with Adrian Chadd, a FreeBSD developer, and we started trying to look at this problem from all angles possible from both the Linux, FreeBSD and corporate world. We made our first public outcry of the problem at the 2012 Linux Collaboration summit and explained the general issues in the current assembly line of hardware and software production. Our hope was mostly to educate the public development community and corporations about general issues in the existing assembly line of hardware and software production and to get feedback on our initial proposed strategy. You can see the slides here, and video here.

This post is a follow up to that talk, tell you where we're at, provide references to the legal foundations of our efforts and to bring together interested parties to start participating by keeping in mind we are open to change our strategies and all this is up to public scrutiny and review. First we'll give the idea of 'driver unification' one last shot, mostly because some people keep dreaming this might be possible and we figured we'd look into this from a community perspective. Some large companies have already given up on the idea of driver unification but that also has some interesting side consequences. We figured if there can exist any such unification strategy it should be defined by the community, not corporations. The technical strategy for our work is work is to start out with something as simple as possible and to try to support just two Operating Systems: FreeBSD and Linux but to never make any compromises to our community development tenets on quality / style. If unification is not possible at least we'd end up trying to create a base repository for development that is public for community developers to pick up and integrate into their OS. That is, we'd end up killing proprietary drivers anyway and make public development the only way to do driver development. Our legal foundation was to follow the path set out by SFLC for doing collaboration between Linux and the BSD family learned through the ath5k wars: we'd use the ISC license to share between BSD and Linux and we'd stick to the strengths of the Developer Certificate of Origin to help ensure changes are intended to be kept under that license. This is implies a call to use a permissive license for Linux device drivers to help with sharing with the BSD community, I formalized this on my localizing the GPL post. I'll note that there are some interpretations on intent on the sharing code between BSD/ Linux, for example the intent behind some Linux developers is that although we allow for sharing we do not intend to enable extracting permissive licensed components from Linux, GPL larger project, and for you to go and make non-GPL compatible modifications of that extracted content to the same Linux GPL project given that the license at run time of the individual components are all GPL; in short you should not extract BSD licensed code from the Linux kernel and make proprietary Linux kernel code.To be clear I am not calling out for the end of copyleft, quite the contrary, I acknowledge the importance of the GPL, but I'm calling it useless if we are to kill the larger plague of proprietary driver development in the industry given that we have no alternative as it stands and that archaic legal strategies should be reconsidered to help us find the areas where copyleft can best be used. If we want to share code simply use a permissive license for those components. We then needed to pick a pet project, something simple, the simpler the better. With agreement to participate in this effort we joined forces with the alx Ethernet driver and we set out to address FreeBSD and Linux support.

As it stands the alx Ethernet driver is being developed in a standalone tree maintained by Adrian. We currently have addressed only Linux support. You can either clone the git tree or use compat-drivers "-u" releases to get this driver for Linux. Admittedly there is a cost here: the driver is not yet upstream. It doesn't matter, the quality of the driver is not yet ready anyway, the team tried to get it upstream about 4 times now.  We also didn't go through staging given that we wanted to have the flexibility to make huge changes without the cumbersome requirements for the Linux kernel but the same time rope in the teams to get used to the same quality / bar. The next phase of development is to address FreeBSD support without making compromises to style / quality for both OSes while the other teams keep on working on fixing bugs and addressing general style requirements on our way to get the driver ready for a new submission upstream into the Linux kernel and FreeBSD project. We have a mailing list for unified-drivers where we request all patch submitters and interested parties to subscribe to help review strategies and patches. If you're interested in helping us review these strategies please join the mailing list and effort. The more critical review we get the better, specially if you disagree with us. If you're skeptical please consider the fact that I received similar skepticism over the ability to automatically backport the Linux kernel. As it stands compat-drivers, the project to automatically backport the Linux kernel, now backports four subsystems across 26 kernel revisions. For that project we've looked at ways to even further optimize backporting collateral evolutions and tools such as Coccinelle SmPL are being seriously considered, and guess what? Its usage may likely also be easily applicable here to help with porting code from one OS to another, its no different than porting driver code from one OS to another, and we have never made a single compromise to style / quality upstream. As Adrian notes though -- please be aware that Coccinelle SmPL should not be considered the "silver bullet" here to the problem, its just one of the tools we are evaluating.