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 😉