Slashdot Mirror
Spotify Releases a Linux-Only Client Library
f0rk writes "Spotify, a popular music streaming service, has just recently released libspotify. An official, binary-only, only for subscribers, library to 'enable and inspire you to build some really cool stuff.' The first release only has support for x86-32 Linux, the only major platform Spotify does not run on. It looks like the Spotify team is trying to be nice to the Linux community and hope someone will use their restricted binary-only library to write a Linux client."
"Spotify, a popular music streaming service, has just recently released libspotify. An official, binary-only, only for subscribers, library to 'enable and inspire you to build some really cool stuff.' The first release only have support for x86-32 Linux, the only major platform Spotify do not run on. It looks like the Spotify team is trying to be nice to the Linux community and hope some one will use there restricted binary-only library to write a Linux client."
Wow, that are some insanely tight proofreading they're, editors.
So to run this in windows I'm gonna have to use Wine on windows? Thats just massed up
Yup, I've never heard of Spotify and I can't imagine why I'd be interested in this. But hey, I always love it with people release "binary only" libraries. They typically provide a nice big fat header file and a .so file. Sometimes they even strip the .so file, that's what I like to call "a challenge". Today I am not sufficiently bored to reverse engineer this crap, but I'm sure someone, who knows what Spotify is and actually gives a shit, will be. How hard something is to reverse engineer is determined by three things:
1) Armoring
2) Symbols
3) Relocation information
When it comes to Linux stuff, no-one ever does armoring, so we might as well not even think about that. All the interesting symbols for this library have come from the header file.. but ELF binaries leak lots of symbols, even when you strip them, so yeah, no problem there. Finally, relocation information, makes the so called "hard problem" of reverse engineering, separating code from data, pretty easy.. and .so files require you to provide them.
So I don't know why they bother. If there's secrets you're trying to hide from developers by not giving out source code, you're just failing.
How we know is more important than what we know.
In making the library binary, Spotify presumably desires to "protect" the music being streamed, some aspect of their service's technology, or both.
I find this curious. In terms of "protecting" the music, the cat is already out of the bag. Even if you can't crack the binary(and we know how long those usually last) pulling the music via virtual sound device or analog hole is trivial. Further, there are already (legal, accepted) music streaming services that don't do much at all in that direction. Pandora, for instance, dumps mp3s in a known temp directory. They don't have any ID3 tags; but that is their only defect. Given that, I'd be rather surprised if Spotify is legally against the wall here.
The protection of their methods/technologies/whatever argument seems equally odd. With most of these streaming services, the major value lies in a combination of having access to all the music and having(and doing useful things with) metadata concerning all the music. All that occurs on the server side of things. To the degree that anybody pays for expertise in compression and network transmission of music, they are paying for patent licences, not implementations(since there is at least one free implementation of any major codec in common use). Any UI expertise wouldn't be protected by closed sourcing the code, and wouldn't be relevant to a library like this in any case.
I can't think of any other good reasons. Access control for the service is, obviously, server-side, only an idiot would build a "trust the client" access control mechanism. The only thing I can think of is that they, like Adobe with Flash, want to make Spotify support free as in beer on the deskop; but make people pay for it on portables and such(hence the restriction to x86). Anybody have any ideas?
(Please note: I respect Spotify's right to release or not release whatever code of theirs they want, under whatever licence they want. That is their right. I find it odd, though, that they would go to the effort of supporting Linux; but do so in a way that precludes adding that support to any of the GPLed media player software, restricts support to a single platform, and generally complicates integration into distros and so forth.)
That would be amusing if it turned out to have significant GPL components and force them to release the source.
Why would anyone use their geo-restricted binaries when open-source Despotify is out there?
Res publica non dominetur
This is getting bloody ridiculous. Everyone releases a piece of binary crap for 32bit linux and that's - OK, are you saying your code is so crappy you can't recompile it at least for x86_64 (which is starting to get comparable in size to the ix86 crowd). Heck, our stuff (which is about 300MB of source) got recompiled for x86_64 in 6 hours (took two-three compilations and some tweaking, the diff was less than 30k).
So, please, people that release binary stuff for Linux, etc., take a bit of time, compile for something else, or you'll start looking really bad.
I didn't get the same impression from the comments at all, so decided to look closer:
"all"... I found no posts saying this. I did see two posts complaining about binary-only, but there are other possible reasons for that and.
Again, finding it hard to locate the posts this refers to.
Wow. where does this come from? I have no idea.
Zero, it seems. There was one guy who would find it funny if there was GPL code in there.
For all the groupthink accusations you spouted, the only evidence of groupthink that I see here is your moderation: +5 for whining based on nothing at all?