Bit confused on one point -- so SoundCloud revised their ToS to deny downloads, but they kept the download URL in the API response? Amazing that after two different illegal take-downs it just kept getting back on top of the listings.
Random Android question: When the app was taken down, I guess you lose app storing listing and IAP. But existing users would still be able to run it, and the developer would still get ad impressions and ad revenue?
I don't quite understand SoundCloud's rationale... Why is it OK for me to do an HTTP GET from one user agent but not another? How is that something they have legal standing to dictate?
Hartig seems perfectly happy to let his obviously well liked software be stomped into oblivion? SoundCloud could perfectly well provide the equivalent functionality, but instead they snuff out an honest developer?
It's not even like he was deep-linking the content (oh no, don't actually use hypertext markup how it designed to be used, shiver), this was just an added intent in the existing 'Share' dialog.
So serious question: 3rd party apps insert themselves into the Share dialog. It's purposefully designed that way. In that dialog, the user gets to choose how to handle the data being shared. Basically, it's in a clipboard and the user is choosing where to paste it. How does SoundCloud get Google to nuke an app for properly using this interface?
(Sorry, that's like a dozen different questions that this post has raised in my mind)
> Bit confused on one point -- so SoundCloud revised their ToS to deny downloads, but they kept the download URL in the API response? Amazing that after two different illegal take-downs it just kept getting back on top of the listings.
I think they eat their own dogfood here. As far as I can tell, they have no special privileges for their owned and operated clients. If you for example look into the network panel when using the web client, you'll see that they directly access `api.soundcloud.com`.
> Random Android question: When the app was taken down, I guess you lose app storing listing and IAP. But existing users would still be able to run it, and the developer would still get ad impressions and ad revenue?
Yes indeed. I'm surprised how much of a long tail the app has. Even though it's now been almost two months since I've taken down the app and SoundCloud has also revoked the API key, I'm still getting a sizeable amount of ad impressions in a completely dysfunctional app. :/
> I don't quite understand SoundCloud's rationale... Why is it OK for me to do an HTTP GET from one user agent but not another? How is that something they have legal standing to dictate?
It's their platform, they can do whatever they want. As operator of a platform like this, it's natural wanting to control the experience. I think it's remarkable how open SoundCloud remained over the years whereby most other platforms leverage their APIs as a way to find initial adoption and then quickly close them down as soon as they reached a certain point.
> Hartig seems perfectly happy to let his obviously well liked software be stomped into oblivion? SoundCloud could perfectly well provide the equivalent functionality, but instead they snuff out an honest developer?
I'm certainly not happy about this, quite the contrary. But I see and understand their rationale, learned a lot along the way and SoundCloud has always treated me fair.
> How does SoundCloud get Google to nuke an app for properly using this interface?
I'm quite interested in the exact process myself. I presume that this all works under the ominous "copyright" umbrella.
>It's their platform, they can do whatever they want.
Surely that's proper legal standing, next to the user can cram it, arguably. There are basic rights and to forbid the use of any can't be broken by contract. IMHO access to arbitrary data on the net should be included, because otherwise it's restricting the market, obviously to artificially drive up the prices. That's against the free market principle, but maybe it's necassary to get the userbase to generate revenue. Soundcloud is not profitable right now. I'd contest that it is necessary, though there is responsibility on the user not to abuse Soundcloud's offering. I'd argue that download rates would be enough to meassure popularity or for whatever they need the data, which is listening behaviour. I'm not sure the law intends to protect Big Data collection on privacy grounds, if data is cleaned up. used for all but what comes down to accounting.
I used soundcloud-dl.py in the past, because the page didnt work for me. Don't know if it still works. I found it very convenient since I'm not interested in the networking features either. I don't understand why people depublish pieces and very much like to keep them. Copyright-Law grands the right to rewoke copyright or perhaps doesn't grant it to the public in case of transmissions to begin with. I'd argue though that with the event of computers and the net, where you select the transmission yourself, the lines are blured. If program-code needs to be specifically excempt from the copyright, in order to legalize loading into RAM any data you bought, then receiving a transmission is a copy as well. I don't know if there are exceptions to the exception, or the transmissions - it's not a persistent copy. Still, you aquire it and the ability to record it is a functional requirement, it's not like a performance that could be given without recording it.
>> Bit confused on one point -- so SoundCloud revised their ToS to deny downloads, but they kept the download URL in the API response? Amazing that after two different illegal take-downs it just kept getting back on top of the listings.
> I think they eat their own dogfood here. As far as I can tell, they have no special privileges for their owned and operated clients. If you for example look into the network panel when using the web client, you'll see that they directly access `api.soundcloud.com`.
But it is strange that they in their TOS for the website state:
"You must not copy, rip or capture, or attempt to copy, rip or capture, any audio Content from the Platform or any part of the Platform, other than by means of download in circumstances where the relevant Uploader has elected to permit downloads of the relevant item of Content."
In other words, they seem to allow users to download content that is available for download. So if I write my own web browser, I'm free to download downloadable content -- but not if I write an app for Soundcloud...
Or perhaps, it's this clause:
"(x) You must not rent, sell or lease access to the Platform, or any Content on the Platform, although this shall not prevent you from including links from Your Content to any legitimate online download store from where any item of Your Content may be purchased."
It's unclear to me how Soundcloud cannot get Firefox for Android banned under this clause as well... (well that would be insane, but you can ask for the desktop version of the site, and download from there?).
Note that this is the user TOS[1], not the API TOS[2] -- but that line is a little more fuzzy than they would like it to be IMNHO.
[edit: entirely forgot to thank the author for being open about this, and publishing the app for everyone to access. On another note: did you already provide source to some of the users on request? Or did you just recently add cert pinning?]
It sounds like they are claiming their ToS can dictate how you can use the data they are putting in your computer's clipboard. They then used that claim to remove the equivalent of a 'wget' program from the app store.
I don't like what SoundCloud has done here. I'm pretty sure it was line noise for Google, but I don't like that they went along with it either.
Note these are published files that are generally available for download. The download is an HTTP GET on a public URL, which they publish freely and directly on their own site. It's in no way "ripping" the file from the site or defeating any DRM.
>It sounds like they are claiming their ToS can dictate how you can use the data they are putting in your computer's clipboard.
They key word here is "they". They "are putting" that data. If you put the data yourself, with your own API and your own service, you can do whatever you want.
Or they get it just fine, since top lawyers of the kind hired by SoundCloud are as smart or even smarter than most programmers, and some even have technical training, but they have their reasons.
Like, they know that the fact that you can "get around" something doesn't matter as much as there being a slight inconvenience.
If, for example, at some point the official SoundCloud app allows direct download, people will use that, and not the "get around" method -- whereas if they allowed third party clients to have that feature it wouldn't be so clear what the users would choose.
There are still plenty of SoundCloud downloaders, and as long as the data is transferred it can still be downloaded. In fact one of the first hits on Google for "SoundCloud downloader" is a website that claims to do just that (I didn't try it but I'd bet it's functional - likely on a mobile device too.)
Data storage and file management is difficult, especially within the UX constraints on mobile devices
This is a very common excuse ("security" is the other one) to justify the increasing constraints on what mobile devices can do - when I think it's really about control over the users. On my desktop, I can double-click files to open them in the app they're associated with, and double-click apps to open them too. I can save files anywhere, including the desktop, and they'll be as accessible as apps. I can use one app to interact with files I created with another one. I have an Android phone and despite it having more processing power and screen resolution than desktops a decade ago, it is nowhere near as flexible. Apps are mostly locked into accessing only the data they've created, with the exception of external storage (which is also starting to disappear). This app-centric model means that working with files/documents is difficult; I can't easily save a file into a folder and have it show up as an icon on the home screen. From what I've read, iOS and WP isn't so different in this respect.
In the context of something like SoundCloud, the motivation for this model and their removal request isn't so obscure: DRM. Google wants services like SoundCloud and other media providers to get the impression that they are on their side, so its decisions are aimed at restricting users' ability to share and remix content freely. Ideally to them, everything must be done via an app, which Google must approve, and which cannot do anything someone else disapproves of...
Thanks for opening the source; the Play Store is not the world and the app will live on outside of it, possibly with further improvements from others. There's a huge app modding community that doesn't even need source, but they'll be glad to have it.
> There are still plenty of SoundCloud downloaders, and as long as the data is transferred it can still be downloaded.
A while back I was fooling around with their API. The "stream" you get is just an mp3, so downloading any song is incredibly easy. It's a shitty thing to do though. The artist will only get a single play out of it... and maybe they were trying to sell you a download. You (not you in particular, anyone reading this) might not sympathize with SoundCloud, but please act in good faith toward its users. SC users are changing the music landscape.
Trivia: the stream mp3 isn't the same thing you get when you click the download link. SC streams are at a particular bitrate, but the proper downloads are of the original file which could be an aiff or higher bitrate mp3.
I never optimized for revenue. Given the high retention rate and overall user numbers I could have gotten way more out of it, but I was frankly not interested in it. I felt like I was making good enough money given the effort that I put into it. I used standard AdMob, without any mediation and replied with "No, thank you" at least twice per week to random people asking me to buy an ad slot in the app.
The numbers fluctuated quite a bit in the beginning but were relatively stable during the last couple of months. From AdMob I'd get between 25€ and 30€ per day and IAP made up for an additional 15€ to 20€ per day.
Obviously before taxes, but given that my running costs for the app were exactly 0 and I sometimes put equally many support hours into the app, I was more than happy with it.
EDIT: Just to clarify, those are pretty much peak numbers. I didn't add revenue stats to the article because I'd have to properly crunch the numbers them first. If you just multiply those by 365 you end up with way more than I generated over the entire 2 1/2 years.
same. very interesting article, and interesting to hear about the distribution between income from adds and people paying to remove adds. But I for one would be also interested to get a rough estimation of what finding a nice little niche space like this could bring you in terms of revenue
I find this extremely interesting, does anyone know or can estimate what percentage of Soundcloud usage happens on mobile compared to the web version which _does_ allow downloads?
Random Android question: When the app was taken down, I guess you lose app storing listing and IAP. But existing users would still be able to run it, and the developer would still get ad impressions and ad revenue?
I don't quite understand SoundCloud's rationale... Why is it OK for me to do an HTTP GET from one user agent but not another? How is that something they have legal standing to dictate?
Hartig seems perfectly happy to let his obviously well liked software be stomped into oblivion? SoundCloud could perfectly well provide the equivalent functionality, but instead they snuff out an honest developer?
It's not even like he was deep-linking the content (oh no, don't actually use hypertext markup how it designed to be used, shiver), this was just an added intent in the existing 'Share' dialog.
So serious question: 3rd party apps insert themselves into the Share dialog. It's purposefully designed that way. In that dialog, the user gets to choose how to handle the data being shared. Basically, it's in a clipboard and the user is choosing where to paste it. How does SoundCloud get Google to nuke an app for properly using this interface?
(Sorry, that's like a dozen different questions that this post has raised in my mind)