Posted
by
timothy
on Sunday April 12, 2009 @09:55PM
from the you-and-you-and-definitely-not-you dept.

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."

The WINE libraries are moving into their own right as a development platform, it would seem. Take, for instance, Picasa - it uses WINE as well.

I don't know much about the whole affair, but considering that some applications will run better under Linux + WINE than in Windows, and that this case is also likely true in Windows, it's hardly all that surprising. The code is likely better, and it's easier than (say) using Mono/.NET, and better than Java, for Windows/Linux development.

On what platforms can I use Spotify?
Mac OS X 10.4 or later and Windows XP or later. You can also run Spotify in Wine on Linux.

So it looks like you can already run it in windows on Wine. Seriously though, at least they seem to be catering to us 1%, more than what most do. We should be thanking them for this token effort, keep applying pressure to open it sure but at least they bothered to test on wine and make a blob.

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) Armoring2) Symbols3) 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.

they may use licensed code which they can't release. Or they may be using unlicensed code and don't want to be caught. Or the code quality may be shit. Or maybe it sends back interesting things. Yep, lots of reasons not to release the source code.

Yes, because often you can release code in binary form that you're not allowed to release in source form. That happens, umm, never.

Or they may be using unlicensed code and don't want to be caught.

Which is fail for the exact same reasons.

Or the code quality may be shit.

I almost guarantee it is.. but that will be evidenced by the binary also.

Or maybe it sends back interesting things.

That might be one of those secrets that I was alluding to, yes. It's pretty obvious that such a thing will be discovered in just as short an amount of time as it would in source code and be much more interesting due to the fact that they tried to hide it.

Yes, because often you can release code in binary form that you're not allowed to release in source form. That happens, umm, never.

err.. that can and does happen, depending on licensing agreements, you can buy licenses to use some libraries in your product X, but if you then released source to your product AND proprietary library so you could compile it, company you bought it off would rip you to shreds.

Prime example being punkbuster for q3, had to be removed for the source distribution because punkbuster library isn't owned by ID software but by some anti-cheating company

It doesn't matter what research I do. You made the statement and I ask what you have to back it up outside you saying so. If you have nothing then the answer isn't what you claim because you made the claim.

Anyways, what this means is that the possibility is still on the table. Despite you wanting to remove it. And it means that we aren't missing anything that you are privy to which caused you to make that statement.

As for me doing my own research, well, as you would know, research involves taking the claims

Spotify runs great and uses very little resources. I doubt there is much, if any, shit code in it.

They've made a program that run exceptionally well under Wine. The only problem I've found is the banner ads don't let you click through (no big loss there) to their web site. But I'm sure there are Linux people that want more than that and they're trying to give it. The fact that they are being relatively friendly towards Linux means there is probably a good reason they're releasing the binary only. For all

> Yes, because often you can release code in binary form that you're not> allowed to release in source form. That happens, umm, never.No, actually, in the proprietary world that does happen. When id released the Descent source code, it lacked sound support, because they didn't have source-release rights to a sound library they'd used. (The D1X folks then proceeded to get sound support working, of course. But it took a few months.) Very early versions of OpenOffice.org didn't have spellcheck, I thi

I don't see why there shouldn't be any buzz about a service that has been launched other places, but not in the US yet. You mean you american guys never hear about products before they're launched in the US ?

Head in the sand? Now you're just being stupid. I don't know why or how I would come across a site that I cannot even use unless I was searching it out with prior knowledge of its existance. It's not like it is some kind of earth shattering new technology. It sound very similar to Last.FM and Pandora.

Yup, I've never heard of Spotify and I can't imagine why I'd be interested in this.

I've completely changed to use spotify for my usual music listening. They have amazing library of music and it feels like you're listening normal mp3 files from your computer. Its also easy to share links between friends, like we do on irc and im's with my friends and on facebook with my gf.

Theres also both free ad supported version (that is usually one audio ad every 4-5 hours or so) and premium for 10e/month.

Spotify: So, we can release the source, right?Music Industry: Nope. That would reveal our ROT13 DRM.Spotify: But they'll figure that out eventually, why can't we j...Music Industry: Do you want to license our music or not?

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.)

It's a common settlement offer (play nice from now on and we'll forget the past) but never a requirement - if any GPL violator don't want to release the source, even caught redhanded they can simply stop distributing and pay damages after copyright law. Stop making that silly argument, it's a piece of FUD thrown around by anti-OSS people like that if Microsoft got 200 lines of GPL code in Windows 7 they'd have to GPL the whole shebang. If that really was true the GPL would be viral in a dangerous sense, but

But it is a requirement to stop violating the GPL. I was rather hoping they'd turn out to be in serious violation, just to serve them right for this "we'll let you do the open work, and benefit from it, but keep our guts closed". NVidia does this with OpenGL in their drivers, and it really bothers me. And Spotify could conceivably be using their own code from scratch, or more likely be working from a BSD licensed original code base: I'm not saying they need be in violation of anything. It would simply be fu

I'm SO excited! A binary-only blob is much better than nothing! It's like getting herpes instead of having no diseases anyway. Sure we'd rather have a-cure-for-herpes but hey, getting a quarter of that is better than nothing!

What is spotify anyway? Anyone ever heard of it? Other than the illiterate OP did anyone care? Slow day in slashdot editor land?

I'd guess that a significant part of people in western Europe have heard about it, at least it seems to be sufficiently mainstream to get mentioned every now and then in (non-IT) newspapers. Elsewhere the answer is probably "not many", due to the geographical restrictions the service current has.

Personally, I think it's a quite nice music streaming service with a rather impressive set of available albums, even though running the client under Wine seems to occasionally crash my window manager (while it does

I would be willing to bet that, if you discount servers (i.e. machines where this is not of interest) there are more Linux/ARM machines out there than Linux/x86 machines. Apparently Spotify is some kind of music streaming thing, and a large number of the kind of device that might want to use this have ARM chips. You can probably run the x86 binary in QEMU's single-process mode, but a lot of ARM devices won't have enough RAM to do this.

Perhaps they want a working solution to at least use the service to avoid the entire "it doesn't work on X so we made it work" as a defense/reason for other programs that defeat protections they thought was necessary.

IF I offer access on linux, then open source programs that defeat my copy protection or whatever pretty much can legally be viewed as just that in their intent. It gives them a legal foot to kick around should it be necessary in their minds.

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.

Porting software between 32 and 64 bit architectures is not just recompiling: there are error conditions. Depending on whether the source is C or Java, elementary components (like 'long long' in C) may have rather different behavior and require cautious code review. And most 32-bit compiled software, even with shared libraries, can run on 64-bit operating systems: the reverse is certainly not true. So if you can only publish one set of libraries, it's safer for now to make it i386 compati

Looked at their terms and conditions a while ago when it came up on a newsgroup I'm no longer subscribed to. Firstly, you become part of a P2P advertising network. Then they can change their T & Cs by altering their website and your continued use of their product means you've accepted their new terms. No, thankyou.

When I mentioned this on the newsgroup their answer was "But it's free". Hence why I'm no longer subscribed.

I really don't mind the binary-only release of the API. Even though i believe that open-source is the best way to do software, i realize that Spotify is in a very sensitive position right now, and i'd rather hope for them to release the source at a later date. They are open-source advocates, and as long as they continue down that path, i'm willing to turn a blind eye.

The real issue here is the platform-restriction. I don't know if the spotify-team or the music industry is to blame for this, but the explicit

1. Consumer Level closed source products have never really sold well for Linux. Business/Enterprise level software is a different story.

2. Close Source Libraries cut the development of GNU software. Linux Development has a much higher level of GNU only developers. Finding good close source developers to make a client for you for Linux is a bit more difficult, especially for free.

3. Close Source Developers would probably be concerned about legal recourse if their app