Software freedom and cognitive dissonance.

Andreas Jaeger on Novell’s GNU/Linux distribution discusses Novell’s decision to stop distributing proprietary kernel modules but speaks favorably of distributing proprietary software as a “user’s choice”. The difference between kernel modules and “userland” programs is easily lost when viewed in terms of a user’s software freedom.

Jaeger says that he agrees with Groklaw’s Pamela Jones who says that if we “pollute free-licensed open source software with secretive code, which we must with binary drivers, we lose what make GNU/Linux special – its openness and our freedom to control what happens on our computers”. But then Jaeger defends using proprietary programs because for him (and apparently for Novell) choice is paramount.

For another perspective which argues that this is unsurprising cognitive dissonance, read Why “Free Software” is better than “Open Source”.

Jaeger’s argument about debugging is a red herring. Proprietary kernel software can adversely affect your system, but if you spend a considerable amount of your time dealing with a proprietary program running atop a free kernel then you see that proprietary software is hard to debug no matter where it is; the part of the system you care about is still hard to work with because you’re dealing with a black box.

The real issue concerns one’s goals and whether one views software use as a social activity where increased freedom for users matters, or a technical convenience where proprietors deserve at least as much say in one’s system as users do.

Jaeger knows that, thanks to all of the work put into the Linux kernel, he can do whatever he needs to do on a strictly free kernel. This wasn’t always the case; there was a time when the Linux kernel was simply not suitable for everyday use by most computer users. So one wonders how did the Linux kernel get to be so useful? Well, we know that the Linux kernel didn’t get to be so useful by people being satisfied running proprietary alternatives. Whether working for freedom or not, kernel hackers spent their time improving the Linux kernel. Perhaps there is a lesson there for “userland” software too—if we grow comfortable running proprietary applications (like Adobe Acrobat) instead of using free programs (including kPDF, Evince, and XPDF) we’ll have no reason to help improve the free programs (in the form of coding, submitting bug reports, providing suggestions and ideas, and lobbying government representatives for better laws) and make them suitable for more jobs.

So we come to a conflict of goals, as the aforementioned FSF essay says; if the goal is increasing user’s freedom, free software matters primarily for the freedom it brings. This doesn’t mean software should be technically inferior, it means that freedom must be retained in the pursuit of improving programs to meet technical needs. If the goal is running technically better software, there’s no problem with picking whatever program does a particular job better at the moment, switching between free and non-free any time one program gains an advantage over another.

Hence, there are real problems for our community if we forget how proprietary software treats users and pretend that proprietary software is the equal of free software. Add DRM into this mix, and users will certainly lose to the well-funded and politically aware pressures of proprietors. The Free Software movement has shown by example that we can all contribute according to our strengths and build a viable free system. Let’s not forget the value of freedom for its own sake.