Copyright Royalty Board Boosts Songwriters’ Streaming Pay Nearly 50%
variety.com
variety.com
However, music is different than video. With music, Spotify needs a full catalog for a great streaming service. With video, Netflix just needs sufficient compelling content to keep the subscriber from churning.
Not only have they been creating more and more original audio content, but they're about to try video content again (their first effort failed) as well. In their mind, music was just their beachhead offering.
http://variety.com/2017/digital/news/spotify-lures-courtney-...
In those two scenarios, how much does the band/performer get?
I think that's an opinion that only looks fair to the labels. The labels also do things to suppress competition, and their very opaque contracts only benefit themselves. Clearly the millions of streams should result in more money than less than $300 for 38 million streams? And I'm not an artist, just another programmer. :-)
I.e. whose pocket will this actually come out of in the long run.
Rather than all-you-can-stream, charge a low rate per song play to users. Assume that existing services charges $15/mo, and heavy users might play 16 hours a day, and act song length is 3 minutes, that comes out to about $0.0015 per play to be the same value proposition. But guessing average is much lower so we could up the rate 2x or 4x and customers come out the same. Everyone gets the same cut of revenue per song play, so popular artists get the same cut of streams as indie artists.
Am I missing something?
It might make some sense to charge for the number of different songs played each month, though this would tend to encourage channels that repeat songs more often (to save money), and perhaps for artists to record more variations on basically the same song.
Incentives are tricky. When making rules like this, you have to think about how it might be gamed.
It is what keeps streaming stations from having to have lawyers negotiate hundreds of deals for the content they play and then still get sued when they screw up and play an unlicensed song.
Back in the day, IBM trialled it with some version of their mainframe and a particular database program, or tried to.
From what I recall, IBM said it would save us in the long run, and claimed they were able to because we hadn't bought the mainframes, they were under a contract. It didn't fly. (Business hint - don't try and fudge numbers when dealing with an insurance company.)
Today? AWS Lambda, and other "function" cloud services, charging for execution time, which isn't quite the same, but I have to feel we aren't far away from someone building their product around Lambda... And then directly passing costs to customers with the same pricing model.
For sales, royalties make sense for songs if we believe that more valuable songs (as measured by how the public values them) should earn their creators more than less valuable songs earn their creators. That's because it is almost impossible to tell ahead of time which songs are more valuable and which are less valuable. You can only tell that based on what songs the public actually buys. Furthermore, this changes over time...a song can start off not valuable, and then years or even decades later become very popular.
What you really want for setting a fair price to the creator is the integral of value to the public over the copyright lifetime of the song. Royalties are a way to approximate that integral.
How about streaming? Similar argument to that for sales, just using play rate to approximate current value to the public instead of sales. This is arguably a better approximation.
For programmers, most of us get paid a decent wage up front to write programs as employees. The employer has estimated how valuable having the programs are to them, and made an offer based on that, and we accepted. We don't ask for a royalty instead, because we would rather have a big check upfront instead of tiny checks dribbling in over the life of the program (which would not be the long copyright life, but rather how long the employer uses it).
For programmers who are selling their programs to the public instead of writing them as employees for a specific employer, their cut of the sale is effectively a royalty.
Finally, what about per-execution royalties for programmers? There are a few differences between programs and songs that make it generally less sensible.
First, number of executions is not as good an approximation to value as it is with songs. That's because programs are utilitarian, whereas songs are art. We run programs to accomplish tasks, and the value of the program to us depends greatly on the value of the particular task we are accomplishing with that run.
Second, most programs aren't streamed for each execution. You can't get execution information back to the programmer unless such tracking is specifically built in. It's very hard to do that in a way that is not visible, and potentially disruptive and intrusive, to the user. If you are in a competitive market, that can put you at a disadvantage compared to competing programmers who are not doing per-execution tracking.
Third, program value is not as uncertain as song value. Programs are tools, obtained to accomplish specific tasks. Users often have a good idea of how valuable accomplishing those tasks are, and how much the program will aid that, so can often can figure out up front what the lifetime value of the program is to them. Programmers who know their market can also figure out the value to their customers of the program. Unlike with songs, this means that we can set a fair to both parties up front fixed price for a program. We don't have to resort to a drawn out approximation like they have to do with songs.