We see six possible approaches to dealing with proprietary codecs. In this section, we'll discuss the pros and cons of each and attempt to map a path to victory.

What Are The Alternatives?

Do without. Unload the problem on individual users. Reverse-engineer all codecs for which deployment is legally possible (e.g. not blocked by patents or the DMCA). Press for delivery in open formats. Get closed source binaries that are "free as in beer". Pay to license codecs, per-copy.

Do without. We can choose to fail. If we don't support the media formats that contain the content users want to see, we lose the 64-bit desktop. It's that simple. Doing nothing guarantees that we lose, probably to MacOS X. Every type of content that is unavailable on Linux hands another content-based killer app to a proprietary platform that does support it. Just as we needed a binary-only Netscape in 1998, we're going to have to stomach some binary-only crap for now if we hope to be ready in time. If we ignore this issue, the dominant 64-bit platform will be owned by our enemies.

Unload the problem on individual users. Another way of ignoring the problem is to distribute unlicensed copies of Windows codecs[35] for use with wrappers like Mplayer's. There are sites outside U.S. jurisdiction that carry packages designed to snap-fit into major Linux distributions and support formats from MP3 to Quicktime. Several multimedia projects (xine, mplayer, and xmms) are designed to accept separately-developed codec plugins, several of the most popular of which are of at best questionable legality in U.S. and many European jurisdictions. The fundamental problem is that vendors shipping preinstalled Linux won't touch this stuff, for obvious reasons. Even distribution-makers won't carry these files, or even publicly link to them for fear of contributory infringement lawsuits. Offering them as an aftermarket upgrade is a mitigation strategy at best, and not a good one. The installation procedures for these kind of codecs aren't even well-documented, let alone simple enough for nontechnical end-users, and technical support for them is nonexistent. The gauntlet you have to run to get codec support in this way is so daunting that even the authors of this paper, both among the hardest core of Linux experts, have never been able to keep basic functionality like playing DVDs stable across normal system upgrades. On top of that, after spending several years carefully distinguishing open-source software from pirated software (despite Microsoft's best efforts to conflate the two), depending on end users to laboriously upgrade their machines to receive basic multimedia functionality in a way that leaves them open to potential legal liability is not an appealing strategy. Some people in our community maintain that this behavior is ethical and the laws against it unjust. We're not going to argue for or against that position here; we'll just point out that it's not a practical solution within our deadline. Instead, it's simply a refusal to address the real problem of getting a preinstalled Linux that can handle these formats (without manual upgrades or legal liability) in time to matter. Nontechnical end-users are not willing to jump through arcane technical hoops. More than that: they expect (and have every right to expect) that a modern operating system will come pre-installed on their hardware and ready to use. Anything that can't provide that is just an elaborate way of choosing defeat.

Reverse-engineer codecs We're good at reverse-engineering. Once Windows versions of a given codec run under Wine, working out what it's doing becomes fairly easy. The problem is that we've already done this for every codec of interest that isn't blocked by patents or the DMCA, and even some that are. There is very little ground left to be gained here; the unsupported formats that remain are gated not by technical issues but by patents, by the DMCA's anti-circumvention provisions, or other lawsuits. And iTunes is a paradigm example; we actually have reverse-engineered open-source support for it, but we can't ship it without falling afoul of Apple's legal department. A few years ago Linux distributions widely shipped MP3 playback and encoding support, but legal threats have almost eliminated this capability from modern distributions. Reverse engineered codecs that we can't ship without risk of lawsuit are no different than binary-only codecs harvested from Windows that we can't ship without lawsuit either. If it doesn't give system vendors something they can preinstall, it's just not good enough to matter.

Press for delivery in open formats. We've been doing this, and we need to keep doing it. But we can't let it become an excuse for ignoring the mountains of content in formats we don't support. The problem with pressing content providers to package in open formats is that we're too small a demographic right now. Providing technology isn't the problem: Ogg Vorbis and Ogg Theora are wonderful geek projects that have little or no traction in the real world, and Schrodinger is an initiative by one content provider that currently only applies to their own content. Most content providers have no incentive to offer their content in Linux-friendly formats while we remain a tiny minority of desktop users. We're statistical noise. Increasing the amount of content in open formats won't eliminate the existence of content in closed formats while we remain a minority platform. At best it will be years before open formats host even a simple majority of available content, let alone everything anyone wants to see. We can't expect major change until providers have reason to fear losing market share unless they ship in open formats. And that won't happen without tens of millions of end-users demanding it. Which takes us back to the original problem.

Interlude: On Coping With Reality. The first four methods of dealing with the proprietary codec issue have two things in common. We're already doing them, and they haven't solved the problem. It's not that they don't work, but that we haven't got enough time. We need something to ship now, because after 2008 the opportunity to capture the desktop during the 64-bit transition will have gone by, and a new incumbent will be in place. There are a number of format support plugins that we technically have, in open source, but can't ship without fear of lawsuit. Examples include DeCSS, reverse engineered iTunes support, MP3 encoding and playback, and FFmpeg. Support for these is not a technical problem, therefore technical solutions do not address the real issues. If hardware vendors preinstall Linux distributions with support for this stuff, selling hardware for-profit, they can expect to get sued. The current legal environment makes these lawsuits inevitable, and we can't change the law while remaining a tiny minority. The largest area suffering from this problem is video codec support. The patented Sorensen codec in QuickTime is one problem, the patent pool around Windows Media Video is another. So far we have exactly one solution that works today to provide support for video content in proprietary formats: space-shifting binary-only Windows codecs. The Ubuntu Restricted Formats Page is as close to nontechnical end user support as this approach can come: find a community-supported wiki page by word of mouth, read a legal disclaimer, enable an overseas repository, and install some packages from it at your own risk. Unfortunately, this does nothing to help hardware vendors seeking to preinstall Linux. Hardware vendors can't afford to give away their hardware, and when money changes hands lawsuits have something to go after. Hardware vendors need clear legal title to both the hardware and the software they're selling. The really tough question is: how do we get hardare vendors something they can ship, right now, without having to wait for new legal precedents or changes in the law?

Secure rights to "free as in beer" codecs, possibly with a one-time payment. Some of the codecs we need today are not available under an open source license. We cannot open up these formats (or wean users off of them) without first capturing the user base. This is a classic chicken-and-egg problem. The problem with space-shifting binary-only Windows codecs isn't that it doesn't work, it's that it's not clearly legal. If the community had the legal right to redistribute these codecs (or equivalents), we would have something system vendors could preinstall, long enough to get us over the hump in 2008. (This solution is unpleasant, but no worse than binary-only firmware to support 802.11g wireless cards. And after 2008 we can come up with something better.) In the best-case scenario, some organization with billions of dollars and community ties could arrange for a CD full of "free-as-in-beer" binaries of every codec we need, which could be freely redistributed. Perhaps this would involve a one-time payment for royalties, certification, the development cost of porting an existing binary to Linux, or perhaps just the lawyer time to negotiate and sign cease-fire agreements with the entities who object to DeCSS or MP3 playback, or even licenses to redistribute the existing Windows versions of video codecs for use on Linux via Wine or a wrapper. This approach might work for codecs which are currently downloadable but not actually a part of Windows. Examples of past success in this area are the Linux ports of the RealAudio and Flash plugins. Again, the important part is a solution that allows Linux system vendors to preinstall support for these formats. An agreement which allows a codec to be downloaded from a specific website, but which does not allow redistribution of that binary, may not be sufficient to allow system vendors to ship the codec preinstalled on their systems. As unpleasant as this alternative is, it's much more appealing than the final alternative we reluctantly come to.