licenses, daap and md5
Another day, another python-daap release. Version 0.6 allows you to connect to shares requiring a password, and fixes some problems with the source tarball. However, there are still outstanding licensing issues that may entail an annoying change to the library in the future.
First a brief bit of history. Since version 4.2 iTunes has required incoming DAAP client requests to be signed with a hash of their parameters. In iTunes 4.2, this was signed using md5. In iTunes 4.5, this was changed to a slightly modified version of md5 with some internal numbers jiggered, presumably just to annoy me. In iTunes 7, the hash was changed again, and no-one has since reverse-engineered the new system, so no open-source DAAP clients can currently talk to the most recent version of iTunes. This is clearly the intent of the hash - it serves no other useful purpose, it exists only to prevent clients other than iTunes talking to music shares, presumably to enforce the restrictions on shared music.
PythonDaap can talk to all versions of iTunes <7, because I include in the source a modified version of the md5 digest algorithm that was reverse-engineered by David Hammerton. For the most recent version of iTunes, however, you're just out of luck. There are various people working on reverse-engineering this one but it's clearly a hopeless battle (it's far easier for Apple to come up with another hash than it is for anyone else to reverse-engineer it), and not one I have any interest in being involved with.
To complicate this more, the MD5 implementation I based my version on is the 'RSA Data Security, Inc. MD5 Message-Digest Algorithm', which is licensed under an annoyingly non-LGPL-compatible license (I'm required to refer to it as the 'RSA Data Security, Inc. MD5 Message-Digest Algorithm', for instance). Thus my ability to legally distribute the source of PythonDaap is in question. I see only 2 reasonable ways out for me:
-
I could port the code to use a library with a more friendly license - OpenSSL for instance. But that's a bunch of work (I didn't even do most of the work for the current hasher - I just ported the changes mode in Digest::MD5::M4p) and doesn't help the iTunes 7 problem.
-
I could just rip out the code completely, and only support iTunes servers before version 4 (and open source servers). This approach appeals to me more - I assume that most people are using recent versions of iTunes, so all the users of PythonDaap must be using open source servers. Many of these are far better servers than iTunes itself - they allow any number of connections, for instance, unlike iTunes and its ridiculous restrictions.
I consider it a real shame that the open source community has embraced a protocol that neither works with the most recent version of the software that it was reverse engineered from, nor is actually particularly well-designed or easy to use. There are plenty of open source server implementations of DAAP, and iTunes can talk to all of them just fine, but no open source clients can talk to iTunes. That developers are essentially supporting Apple in this by producing servers for a protocol that they're not able to write clients for is annoying.
More annoying is that, at the same time as being restricted by the closed protocol, I'm having to deal with problems caused by the fact that not all of my code is open enough. Yay.