Just noticed this edit https://musicbrainz.org/edit/69395686
I would argue that “can be streamed for free” is incorrect. I followed the link and tried to listen to the track. It wasn’t possible, instead I was asked to sign up or log in.
AFAIK, Spotify at basic level is ad supported. “For free” may not always mean “free of charge” but for me implies “if no consideration is requested” (i.e. no synallagma = no EXCHANGE of services). However, Spotify wants personal data in exchange and targets the listener with (customized?) ads. I think a more finegrained explanation should be used.
I guess @jesus2099 is using the Spotify app on his smartphone which is indeed very limited – while the website (on my desktop PC) and the app for (Android) tablets allow you to listen to whatever you want with a free account
I’ve taken issue with even having such a relationship at all. Most commercial streaming services, even if they advertise themselves as free, are not totally free. More and more of them are moving to a paid-subscription-only model, in large part thanks to protests from artists like Taylor Swift.
Before I made https://tickets.metabrainz.org/browse/STYLE-1287, I debated whether to add a separate relationship or rename the existing one. It seemed at the time like adding a separate relationship was the way to go (path of least resistance), but I question that decision every day. My worst fear is that artists will point to the existence of the “stream for free” relationship on MB as evidence that we don’t care that they get paid, and retaliate accordingly.
I don’t think this scenario is far-fetched. With Corona it is unlikely that concerts will happen anytime soon. Especially bigger artists will want to tighten their control over revenue as a result.
I would suggest to change “can be streamed for free” into “can be streamed legally” - as those two are not necessarily the same.
The intent is to let people know that you can follow the link and listen to the song without handing over money, and I’m sure that’s how people understand it. They know what site they’re being sent to via the link and can make their own assessment. ‘Can be streamed legally’ might be more technically correct but I don’t see the benefit in a practical sense, and maybe a bit more confusing (do we guarantee that our links are legal uploads, and a paid stream, eg a iTunes purchase, also falls under the definition of ‘legal stream’).
Disclaimer: I also strongly believe Spotify is satan manifested on earth as a music “service”
At least the semantics are right for Bandcamp!
This is also a grey area IMO: The importer scripts and general consensus seem to be to apply the “stream for free” relationship to Bandcamp releases where all tracks are publicly available, but unless it’s an entirely free release (i.e. pay-what-you-want with no minimum), you will be asked to purchase it after streaming it a few times.
There are few things for fee on the Internet, especially/also at Google/YouTube.
If you watch a video on YT it is not for free. Maybe you pay for the Premium account. Or you have to take ads (and so another one pays for you). Or Google will track you and it will be monetized at the end.
Maybe you don’t have to pay money directly but often you pay with your data – and so it is not for free.
I’m against using “for free” for paying with data.
I think the links are useful: no more than we catalog barcodes, or ASINs, Spotify IDs are a useful identifier worth cataloging.
But the editioralising of “Can be streamed for free” is problematic for several reasons. Although
I don’t agree with the complaint of “is Spotify really free” specifically, because then the word free wouldn’t exist – everything has a cost to someone.
However:
Although I’ve yet to ever see it, UMG’s deal with Spotify allows them to withold releases from free tier for a few weeks (“free” is then untrue by any definition)
Spotify releases can become unavailable. For instance one version of Waste Management by t.A.T.u.. They remain in the Spotify catalogue, and direct lookups by the ID will return the metadata – both through the client and through the API, but they cannot be found by search on either. Keeping the Spotify ID for these releases is something I believe MB should do, but it is not true that the link takes you somewhere you can stream it (free or not).
The wording is not consistent with other IDs we catalogue: ASINs are just marked as identifiers, not “Can be purchased on Amazon”
This doesn’t address the use case where a given version is no longer available anywhere on Spotify (etc.)
The only thing that links guarantee is “this is the identifier XYZ service uses for this release”. There’s no guarantee it can be streamed at all even ignoring payment restrictions.
Cataloguing them as a specific relationship is what makes most sense to me — like publishing society IDs for works.
So why is Amazon special? You can “stream for free” from Amazon if you pay them for Prime. I can’t “Stream for Free” from any of Spotify, Deezer or Tidal as I don’t have an account.
Surely these shops should all be treated equally. They are a club you join to access the music. Joining the club either means paying a fee or listening to adverts. It is still a club and not really “free” music.
As @tatsumo points out - these clubs have music come and go from their collection depending on who is paying fees and which music they are currently selling.
Currently YouTube is genuine free access to all without a sign-up. And there are many other links I see appear added to releases that are truly free access without an account. Click and you play in the browser, no app required. (Trying not to get distracted\OT with the “YouTube has adverts” comments as they are easily blocked. Even with adverts the music is still easily accessed without an account)
True That’s the situation where I’d expect we could set the relationship to “ended” (so that we still store the ID but don’t claim it can be streamed anymore).
They just got grandfathered in, really (we originally had Amazon separately because we used their cover art, way before they had streaming). Eventually we might want to have separate relationships for each one of them, but only if we make it so they don’t get in the way when you want to select a relationship type by hand (the list is super long as it is).
Keeping track with an “ended” state feels like overkill.
Sometimes releases literally come and go. Or rather, come and go and come. For instance this other version of Waste Management by t.A.T.u. replaced the completely unavailable one above. However, there was a period for about a month (or more), where this also ceased to be available (I’m not sure when it became available again). It has since become available again, under the same ID.
Everything but the ID itself, could be derived programatically: either MB could integrate with the APIs (unlikely) or more likely, a 3rd party client of MB which is interested in the external services, would lookup what it needs from Spotify or Deezer based on the ID Spotify or Deezer provides.
Whether or not it’s still streamable is something I’d consider internal to Deezer/Spotify/etc. and especially since they have public APIs (again, not necessarily for MB to use, but other clients could use if they need it), I don’t really see the value in cataloguing “Unavailable” states in MB just like we don’t catalogue when a CD ceases to be pressed (it may be pressed again, under the same catalogue number and barcode, just like the Spotify release I mentioned here was revived). It will constantly be severely out-of-date. Unless someone writes a bot to periodically update it – but then what’s the value versus retrieving it live from the API?
For this reason I also don’t see the value in listing 200 release countries for digital releases, since really it’s where it’s licenced at present, which can change – what’s the release date when a country is added? What about when one is removed? (Both of these scenarios happen frequently)
That’s the situation where I’d expect we could set the relationship to “ended” (so that we still store the ID but don’t claim it can be streamed anymore).