Apple Smacks Down iCommune
flipsidejones writes "Looks like Apple has killed iCommune. iCommune, as mentioned previously, allows users to share music libraries across a network from within iTunes. It seems the license for the iTunes plugin API does not allow for software-based plugins (only hardware: MP3 players, etc). Apple issued a 'Notice of Breach and Termination of License' to iCommune, who have since pulled the download. Something tells me that they won't be putting it back up anytime soon. Every time I forget about Mac OS X being proprietary, Apple does something to remind me." Well, in fairness, this could happen even if Mac OS X itself weren't proprietary, as iTunes still could be. For that matter, iCommune still is, too. Hm, none of that makes me feel any better ...
I may be missing the point, but what is it about iCommune that was so different from sharing the files over a network via network protocols, anyway?
Since iTunes is a proprietary work, I'm not too upset by this - luckily, all iCommune needs to do to counter this is to produce an MP3 player better than iTunes, open source it, and they can very well do what they please. Just because iTunes is a proprietary MP3 player doesn't mean that it's the only possible one that'll work on the MacOSX platform.
This is more molehill than mountain.
Considering that according to last July's MWNY keynote, the next version of iTunes will be coming soon with this exact same feature, I'm surprised Apple didn't just wait until they ship iTunes 4 or whatever and just kill off iCommune the same way they killed WindowShade (incorporated into System 7), Watson (incorporated into OS X 10.2), etc.
Unless there's some reason they think we would prefer iCommune to their Rendezvous iTunes...?
Seems to me that the RIAA is starting to sue the hell out of anyone doing anything special with music or media in general.
It's good business sense for Apple to cover their asses by squashing something they fear might get the RIAA crawling up their innards.
And with earnings in the red, Apple is sure to be sensitive to the desires of shareholders, who might not be savvy enough to understand that a 3rd party tool should really not be of Apple's concern.
So, Apple decided not to take on the considerable risk of being seen to sponsor music piracy.
Sounds reasonable.
Now, this is a more interesting question: why do some people believe that Apple had a responsibility to risk it's neck so you can download tunez more easily? Why do some people believe that just because Apple sold a certain product, they must have a responsibility to provide other things, such as use of their software for music distribution, too?
I'm not sure about the answer... I expect it's something depressing.
Whence? Hence. Whither? Thither.
Only public SDK is the visual-plugin. The device plug SDK is by request. So only those who have it can answer that question.
The solution of course is to rewrite it using visual API and leaching the audio. As the Visual SDK has no restrictions mentioned about hardware.
The problem isn't the APSL, it's the iTunes SDK license that developers have to agree to. That license keeps developers from making software plug-ins (except for visualizers).
In cases like this, just don't agree to the API license. There are tools for digging into Cocoa apps and figuring out the class interfaces. I've already dug into iCal and iChat -- they don't have APIs, but there is some interesting stuff in there. (If I'd been looking, I might have seen some of the unnanouced iLife hooks talked about at Macworld!)
That said, I don't think iTunes is Cocoa. It used to be Soundjam, right? So it's probably Carbon and the obj-c digging tools won't help much. Not sure the best way to figure out Carbon APIs. In the old days, we'd use MacNosy to "decompile" the code. Not sure what the Carbon equivalent would be.
I am kind of disappointed that Apple is bullying developers who promote their hardware and software for free. But I am not sure why you need plugin SDK for this project. iTunes writes its libraries and playlists as XML files. I wrote a tiny shell script to copy files in the playlist to my MP3 player, which acts as a USB hard drive. Why not just write a small web server that reads those XML files and lets others browse the files and listen to your playlists as streams?
Also, MacOSX has Samba and NFS in addition to Apple's own file sharing. On a local network, everyone can just export their MP3 collections and then just point MP3 players to the parent directory under which other collections are mounted. Should be even more transparent than the plugin.