Blockchains in the Music Industry

Blockchains in the Music Industry

These were not pure blockchains after all. They were conventional databases, overlaid with blockchain attributes.

February 5, 2024

June 2017.

Blockchains are a new, exciting, mysterious, transformational technology surrounded by a lot of hype. Being a lawyer, I viewed this as a challenge. I wanted to investigate. I wanted to cut through the hype and at the same time contribute thought leadership to my area of practice. The result is my paper for the International Association of Entertainment Lawyers’ 2017 book, Tech: Disruption and Evolution in the Entertainment Industries. It was presented at MIDEM in Cannes, France, where I appeared on a panel with Cecile Rap Veber, Director of Licensing and International at SACEM, the Society of Authors, Composers and Publishers of Music in France; Virginie Berger, CEO of Armonia, the European-based licensing hub for digital platforms; and Alex Loscos, CEO of BMAT, a music monitoring technology company based in Barcelona, Spain – moderated by Maxime Gazeau from Turquoise Law in Brussels, Belgium. The following is a condensed version of my presentation.

Why is blockchain a big idea? Because potentially it addresses a lot of important problems currently facing the music industry such as data overload due to streaming; inefficiency of making micropayments; data in silos; delay in payment; delay in licensing permission; failure to track monetization; inefficiency of granting micro-licenses; need to move away from advertising-based revenue models for digital; black boxes for payment. In short, money and data problems. Lots of them.

Some innovators have imagined solving these money and data problems using cryptocurrencies, and smart contract platforms like Ethereum to enable more efficient, standardized and transparent payments, but these technologies, themselves, do not address the data problem of “who to pay.” If we want to enable, somehow, the maximization of value flow and creation, we’ve got to solve the data problem first with respect to correctly identifying works of copyright. Given that context, blockchain solutions can be seen as a metaphor for shared, networked, media metadata. This is where the music industry is largely at, right now: cleaning-up data and becoming used to the idea of sharing data.

But then, what about the flow of the data; a shared metadata network, or networks – what does this look like? This is where the hype begins, about blockchains, in terms of what blockchains can do, will be able to do, and how blockchains can disrupt.

Blockchains in their pure form cut out the middleman in a transaction. If we read through Don Tapscott’s 2016 book, Blockchain Revolution: How the Technology Behind Bitcoin is Changing Money, Business, and the World, we can see there’s plenty of potential. For example, blockchains don’t need a bank to settle a payment transaction, so if a ride sharing app like Uber or Lyft were to become blockchain-enabled, then potentially the payment I made from my blockchain wallet at the end of the ride would go directly into the blockchain wallet of the driver – with no banks in the middle. Of course, this would be disruptive for credit card companies and banks – middlemen – who would not longer get a processing fee. For music it can be the same. A consumer could listen to a music stream and the artist/ writer could get paid directly. Potentially, this could exclude entities like record labels, music publishers and performing rights organizations – more disruption. Given enough time, would they all become extinct? No, in my view that’s not going to happen for a bunch of reasons that come down to the added value that those parties bring. But, the ideas behind blockchains are disruptive – especially to the so-called “value gap” (i.e. the disparity between the value of music and what’s currently paid for it).

These ideas boil down to: (i) de-centralized, shared control of data globally; (ii) an immutable ledger and/or audit trail of occurrences; and (iii) automatic transactions either tied-back to fiat currencies, or settled using assets that are native to the blockchain (e.g. Bitcoin, Ether).

How about the truth? Thinking about blockchains is confusing. How can there be so many blockchain-fueled companies springing-up so fast? For example, IBM has a new blockchain platform touted by IBM to be the first commercial deployment of Hyperledger Fabric v. 1.0, enabling users to build a blockchain network in hours instead of weeks; to run highly secure blockchain networks for regulated industries; and to easily manage decentralized networks across members. It’s said by IBM to be the world’s most secure blockchain service.

But wait, blockchains for “regulated industries”? No offence is intended toward IBM here, or SACEM, PRS for Music and ASCAP – who have recently announced a long-term joint venture to build a prototype for a new shared system of managing music copyright information using blockchain technology. They are working together to model a new system for managing the links between music recordings (i.e. International Standard Recording Codes – ISRCs) and music works/ compositions (i.e. International Standard Work Codes – ISWCs). Their goal is to prototype how the music industry could create and adopt a shared, decentralized database of musical work metadata with real-time updating and tracking capabilities. This is a good idea!

Yet, Bitcoin – which only was invented in 2008 – i.e. the original, classic blockchain – is notoriouslyunregulated; blockchains like Bitcoin or Ethereum are entirely self-guaranteed. They’re said to be “DAOs” (decentralized autonomous organizations) – they don’t need to have a seal of approval or a performance guarantee from anyone and they certainly don’t have any database administrators. They can be “forked” – amended – going forward, but that’s about it in terms of averting potential disaster.

As I read further into the blockchain topic for the IAEL paper – to unpack the hype – I read that some blockchains do not need “miners” (who verify the blocks, in exchange for a payment from the blockchain’s cryptocurrency). I read that some new blockchains have “Oracles” – whatever the f@$k that means. I found that searching for the truth about blockchains is like trying to pull out a coin that had slipped between the cushions of a big chair. The more I pried apart the cushions, the deeper the coin dropped. Then the coin fell out the bottom of the chair onto the floor. The Oracles were third party services that were not part of the blockchain consensus mechanism – i.e. they were external, trusted sources of information. From my point of view, as a lawyer, they were people or things with the keys to the back door of the enterprise, not much dissimilar to network administrators.

The takeaway: these were not pure blockchains after all. They were conventional databases, overlaid with blockchain attributes.

If we go back to Satoshi Nakamoto’s original 2008 white paper for Bitcoin (n.b. it was likely developed by a group of people, not just one person), it talks about a purely peer-to-peer version of electronic cash, that would allow online payments to be sent directly from one party to another. The validity of the previous transactions, in a blockchain, is verified by miners who get paid in Bitcoin for their trouble. Hence, a supply of digital currency is needed, created and presto! – a money supply. Yet, in the short period of time since 2008, in the music industry at least, we seem to have veered-off in another direction. Where does that leave us? Where are we headed? Well, a pure blockchain like Bitcoin is terrible as a processing platform. It has a low throughput, low capacity, high latency, and poor query support. In short, it’s no good for massive amounts of micro-transactions occurring simultaneously across the world. Think about how many credit card and debit transactions are occurring simultaneously right now, across the world! How could a classic blockchain with mined blocks handle all that? In short, it could not. In order to get the necessary computing horsepower, we need to fall back to large, permissioned databases.

Where blockchains in the music industry are headed, is to take the compelling aspects of pure blockchains, which again are, decentralization and shared control, immutability and audit trails, and the ability to authorize the exchange of assets, and to overlay that onto a database.

Therefore in conclusion, the truth about blockchains in the music industry, currently at least, in my opinion, is that there are two kinds of blockchains: (i) permissioned blockchains, which potentially could run extremely fast on conventional databases; and (ii) pure blockchains, which are pure peer-to-peer networks where anyone can join and where validation is achieved through mining. The latter will continue to be developed and used by the outliers. They will continue to evolve in interesting new directions that seek to make a direct artist-to-fan connection, while the former will be the core for the music industry’s back-end payment systems.

One of the most interesting issues to me in all of this, and that has not yet been addressed squarely by the industry, is “who will have access?” Contemporary music tracks have numerous co-writers, and many re-mixes. Opening up a blockchain platform for example, to music producer studios or artists, despite the best of intentions, could result in an influx of bad data, and bad data is the curse of any computer system because, aside from AI and machine learning, machines can’t cope with ambiguity. It’s inevitable that the more access given to the blockchain platform, the more likely that bad data will occur. We’re not talking about a simple failure to use accepting protocols for identifying sound recordings or compositions. Here we’re talking about over-claiming on splits, expired rights, etc. Yet, blockchains are all about sharing and openness.

Perhaps the ultimate truth about blockchains in the music industry is that there’s always going to be a tension between classic blockchain ideals of openness and inclusion, and the music industry’s need for data certainty.