Free software still creating more pressure to release more free software

In or around October 26, 2011, Apple released source code to their software (called “ALAC”) for compressing and decompressing audio without any loss of audio quality. Apple chose the Apache License version 2.0 for this code which includes a patent license. This was a good thing to do because it helps users with ALAC files use free software to maintain those files. But FLOSS users already had this functionality because on March 5, 2005 David Hammerton published a simple decoder written in C under a very permissive FLOSS license based on the reverse engineering Hammerton and Cody Brocious had completed without any documentation of how the codec worked.

Hammerton and Brocious’ decoder has long been incorporated into a widely-used audio/video library (libavcodec). This code has also helped to make an Apple Lossless encoder to make Apple Lossless files. So for years popular audio/video programs based on libavcodec could handle Apple Lossless files; standalone hardware devices one could purchase at electronic shops (like Plex, XBMC, and Boxee) and popular software players like VideoLAN Client and MPlayer all take advantage of libavcodec.

The FLOSS community had achieved a high degree of interoperability without sacrificing software freedom, and done so on its own terms years before Apple contributed anything. I don’t know why Apple chose to release its code as FLOSS but I believe this is another instance where free software created pressure to release proprietary software as free software.

So what is the value of Apple’s code contribution? Perhaps there are only two points where Apple’s code could be of some value:

  1. Apple’s patent license—as a result of Apple choosing the Apache License version 2.0, Apple has granted permission to use the ideas covered by Apple’s patents in this program and its derivatives licensed under the same license. But this poses a problem because it’s not absolutely clear which patents Apple refers to in their source code comments; looking this up and reading those patents then implementing something on your own could set you up for triple damages. Software patents need to end but for now this threat should only last until these patents expire: 20 more years at the most. If you don’t live in a region that honors software patents (good for you!) this is a non-issue.
  2. Example code of 3-8 channel encoding/decoding—if you need to encode or decode more than 2 channels, Hammerton and Brocious’ code won’t help you right away as it can only handle up to 2 channel files. But on their webpage they note that supporting up to ALAC’s 8 channel maximum “should be trivial to finish […] once I find files that I can test it with.”. If the extant FLOSS code already handles enough channels for you, this too is a non-issue.

But by now FLAC (Free Lossless Audio Codec) has a strong foothold on the uses ALAC serves. FLAC is freely distributed without known patented algorithms, FLAC is widely used, FLAC supports 1-8 channels, FLAC has no support for DRM, FLAC has years of use prior to ALAC, FLAC has several independent implementations, and FLAC is widely supported in hardware and software. Even Apple’s restrictive playback equipment can be used to support more formats (including FLAC) by installing Rockbox software instead of using Apple’s proprietary and limited software. So in a purely technical sense, FLOSS beat the proprietary approach.