top of page
  • Writer's pictureV2POINT0

It’s the Copyrights, not the .exe files.

The first reactions I had to my early published articles were — “you can’t put content on block chain, the files are too large and the technology to slow”.

Putting content on the blockchain is not the technique that I propose. What you would need to capture on the blockchain is the basic copyright information. This in turn will be governed by smart contracts, that then defines the use of the content that is attached to the copyright information.

The smart contracts become the codified user agreements, and license agreements that make up the final product that oversee the copyright’s executable files. I know it sounds complicated but please stay with me.

The execution of a transaction pushed to a blockchain enabling access to an executable file is not quite a smart contract — there are many more associated with this transaction, rather than a simple “pay and play instruction”, that would benefit enormously from the edition of an array of interdependent smart contracts.

As is common with various intellectual properties, no one smart contract would be sufficient to govern usage — it would be more likely interdependent smart contracts governing complex conditions based on license, license holders, territories, type of usage [be it public or private], age of the copyright and of course transferability and portability.

Smart contracts can be triggered by external conditions, such as a request to trigger an executable file within a certain geographical range or the audience type be it public or private. This outcome request would then dictate the conditions of the transaction and the requirements of the various license holders and parties within the transaction. These would all be resolved in one instance rather than over a long period of time (traditional several calendar quarters).

Perhaps the confusion comes from the fact that Blockchains by default are not retroactively editable. Any data stored directly on a chain would be irrefutable and therefore could only be data based upon the origin or creation date of the copyright. Each block would be like an immovable certification that this copyright was created on and is of a certain type.

Copyrights of course can be added to various bundles or change ownership over time. These of course must be recorded outside of the blockchain in a type of DAPP, but the original creation record would always be attached and remain as the day it was created.

Simple types of copyrights such as music or photographs are usually fairly straight forward as they can be created instantly, as in the case of a photograph, or within a short timeframe by a concise group of individuals such as a song.

More complex types of copyrights such as games or film would benefit enormously from the creation of a decentralised distribution environment wrapped around a blockchain. In these complex cases and although the creation date and the type of copyright remains irrefutable — the conditions and licences attached to that copyright grow and expand as the copyright takes shape into the final commercial product. Whether it’s a points share agreement between the production company and a contractor or an actor , or a license agreement between a software provider and the production company. All these external factors can be represented in co-dependant smart contracts interlinked over the course of and as part of the production.

With more and more technological innovations in the area of content production, there is more so than ever a need to be able to reflect their complexity in the legal aspects of a work.

Recently I was made aware of a type of application that can be used in film content that allows for products placed in a film or game to be interchanged dependant on the location of the viewer. For example, the viewer in Australia may see a bottle of wine on the table whereas the viewer in Poland may see a bottle of Vodka. The copyright becomes a marketing vehicle that has external factors as to how it executes at any one time. The instructions as to how the file is resolved upon execution, based in a territory and or clients, would be contained in a executable contract. The advertiser’s payment would then also be logged in an irrefutable way and the impression from the viewer confirmed. All parties would have their needs resolved and verified.

Of course, these conditions change over time with different marketers and advertisers cycling in and out over the lifecycle of the copyright. These conditions can vary — if dictated and organised within the backend of the DAPP.

In games there is a possibility that a great many licenses would come together to make up any one property. For example, it’s likely that Electronic Arts annual FIFA title would have hundreds of different licensing agreements in the game. These would range from player likenesses, club colours and of course real estate related to stadiums. Add to that all the residuals and software licenses used — and it would all be a very complex product to audit each year.

With the application of smart contracts attached to the end product, or copyright, there would be a realisation of all these complexities contained within the end product, being enforced or resolved at the point of purchase.

As you can see there are many types of copyrights and some are amazingly complex and therefore a complex system of interlinking actions to make them resolve as they should, at the point of use — would be an enormous leap forward, if not in the distribution of content, at least in the auditing of it.

Presently the hundreds of agreements that make up a game like FIFA are all resolved manually by accountants and auditors at the end of each year to ensure the stake holders are paid the agreed amount. With a smart contract driven, blockchain based copyright registry and subsequent decentralised distribution ecosystem — there would be no more need for thousands of accountants and auditors to ensure the integrity of the revenue share.

It would resolve “smartly”

3 views0 comments


Commenting has been turned off.
bottom of page