If you have a dialog with them, why not just propose "Re-distributable, no changes permitted" which I guess might be a reasonable option given the circumstances. Note that I (and perhaps also you) need to repackage things, without changing any binary.
It's strange there's no answer to this. Trying to analyze the situation there are two questions: if the client is redistributable and if it can be repacked.
After a quick search I can't find any limitations on distribution for the linux nor the windows client. Also, windows clients are redistributed from other download servers than Spotify's. Together with the obvious "risk" of redistribution when creating a .deb package without such licensing restrictions it makes me feel that the package could be considered redistributable.
Also, I can't find any restrictions on repacking. The license conditions are designed to stop tinkering with the code, authentication etc. However, repacking is nothing of this.
Another aspect is that Spotify has an interest in distributing the client. If it hits major Linux repos, it will attract more Spotify users, both paying and free. So it shouldn't really be a problem.
Bottom line: without any other info from Spotify I'll assume the terms are "Re-distributable, no modifications permitted", with an exception that repacking the .deb archive is allowed.
For better or worse, RPM does not have this flexibility. My two options is either a spec like the one I have submitted, presuming the package is re-distributable. Or to create a package like download-build-spotify which downloads the binaries and builds the rpms on behalf o fthe user. However, this is not as nice from a user perspective.
So, I'll still presume that the package is re-distributable. Doing this openly here should avoid any conflicts, I'll just retire the package if/when Spotify clarifies that this is not the case.
If they are irritated anyway, I might talk to them gently in Swedish - that should solve any possible problem 😉
According to my colleagues in the legal team, until we have a more specific set of licensing terms for the desktop software, it's best to assume that the license is for personal use, non-modifiable and non-redistributable.
Sad, indeed. This means that this package can't go into rpmfusion (and probably no other Linux distro). I will withdraw my review request.
I note that there's no indication on that more elaborated license terms for the Linux client are under way. Together with the time required to get this simple message, I guess such terms are not here shortly.
Bottom line : a sad message: For Fedora users, for all other non-Ubuntu Linux users and for Spotify sales dept. And, not the least, for the excellent devs who have created this package.
Certainly not. However, I feel that the value of such an installer is limited. I will update the descriptions here in my post on how to roll your own RPM from the spec file. Besides that, I'll wait until the license becomes usable.
Thinking loud about the re-distribution issue: If re-distribution is a problem (although I don't really see why): couldn't Spotify create some simple infrastructure for community-driven packaging for different distros, keeping some control over what goes away? After all, most distros will not accept a prebuilt binary package in their repos anyway.
Normally liability could be a problem but it should be possible to handle with some proper disclaimers, I guess. After all, the complete Linux client is just a demo - Spotify as organization takes to responsibility for this "thing" which isn't a product, just a piece if fine work from some developers.
I have been watching this thread and decided to comment. I would like to create a repo for openSUSE and was wondering the excact same thing. There are wonderful people who have made a script to convert the official deb into a RPM without alterations and I would like to add this RPM and all requirements to a repo to be used for openSUSE.
Or Spotify could do the same as Skype and Google did and just make a RPM available and safe us all the bother!
We don't allow repackaging and hosting of the Linux application. Yet we understand that Linux enthusiasts would like to be granted permission to repackage the client for the purposes of the hobbyist. So I wanted to let you know that repackaging of the client without hosting it for others is ok. Under these conditions, Linux hobbyists won't be hunted down by a pack of Spotify wolves. However, we will be inclined to remove links to any repackaged apks on the Spotify Community. I hope this clears things up.
OK, about to make an installer which downloads and builds a rpm file locally which should be OK under these conditions. Normally, there would be a LICENSE file or so explaining the license conditions. SInce there isn't, I will use the following text:
The previous message was an implicit question. To be more explicit:
Basically I have understood that while hosting rpm packages for non-debian distributions is prohibited it's OK to build a rpm for personal use from the debian packages and/or the distribution tarballs..
I have now submitted a review request  for a Fedora package which does not contain anything from the spotify linux client. However, the package is capable of downloading and building a rpm package to be used on the local system. Basically, this means that Fedora would distribute an automated way to do the same thing as the manual procedure described in  and in existing archlinux and suse packages , .
As can be seen in the review request , I will not be able to do this without a clear statement from a Spotify representative that it's OK for Fedora to distribute such a recipe. Which boils down to a simple question: would it be OK for Fedora (and others) to distribute an automatic way to download and build a rpm for personal use using the debian packages and/or the generic tarball?