Please do not shoot: ASF read support
wheeler at kde.org
Fri Jan 5 20:27:40 CET 2007
Xavier Duret wrote:
> As far as I can see, there can be 5 arguments against the inclusion of ASF-WMA support in taglib:
> 1 - The maintainer does not want to have to maintain such an ugly format.
> 2 - The maintainer has some ethical or political problems with Microsoft.
> 3 - The origin of the code itself is doubtful.
> 4 - The code itself is not up to the standards of the project.
> 5 - The functionality involved is patented.
> I would like to answer those points one by one. The first four are the easiest to solve.
> 1 - Given that this project is open source, it should be easy to make it clear who is responsible for maintaining the ASF-WMA functionality and avoid bugging the main maintainer about it.
Except that never happens. ;-)
> 2 - I am just going to hope this is not the case.
I'm not exactly a fan, but no, that's not the thing keeping support out.
> 3 - I have read there "http://mail.kde.org/pipermail/taglib-devel/2005-March/000096.html" that Scott wants to avoid having anything to do with code from mplayer. Fair enough. If the functionality came from another source, would it be okay then?
It needs to be clear that it's from an LGPL'ed project or less
restrictive and that it draws from proper reverse engineering, not the
official spec. I mentioned MPlayer specifically because they've got a
reputation for mostly disregarding such things. (I have no problems
with the project, but in that regard I don't want to incorporate their
> 4 - This should be easy to fix.
It's not up to the standards and would essentially need a complete
rewrite. (This isn't Umesh's fault; he just took the code from a C
project.) It also doesn't support saving, which is essential for inclusion.
> 5 - This is where it pays to start being specific. I have seen a lot of statement from people about the fact that the format is patented. It seams that the "P" word is being used to close all discussion. The fact is that patents can be worked around. I am going to make a list of precise statements, let's see if some actual evidence of the contrary can be found:
Others have brought up the patent; I haven't. While that's something of
a concern, the more notable thing is that the specification has clauses
which ban OSS implementations. That makes the spec unusable. The
patent claims I haven't seriously looked into just because there are
presently so many other barriers that they're just a drop in the bucket.
One notable thing is that as of 1.4 (or was it 1.3?) it's possible to
add support for additional formats without modifying TagLib itself.
Amarok does so for several formats.
More information about the taglib-devel