ENVITED | Who Owns Our Smart Contract Code? - The problem of data ownership on a blockchain

TL;DR

  • Data ownership in the sense of liability as well as in the sense of intellectual property remain unresolved.
  • The potential of multiple applying jurisdictions complicates the matter.
  • How can publicly deployed smart contract code in Tezos be protected as intellectual proper-ty?
  • Under which license is the smart contract code after it is deployed?

A general question that – to the best of our knowledge – remains unanswered is who owns data stored on a blockchain?

It’s a legal question of great magnitude and complexity, since blockchains are global and distributed networks that are not operated by a central legal entity and thus multiple jurisdictions may apply . It also entails further questions such as:

  • Which rights concerning the data does a contributor need to post data on a (public) blockchain?
  • Which rights concerning the data does a contributor keep or forfeit with posting them on a (public) blockchain?
  • Which rights and liabilities do network participants inherit with replicating and saving the data in their nodes, i.e. their “local blockchain copies”?

The third question is particularly delicate as it could render public blockchains entirely useless if answered “wrongly”: There have been reports on data that is illegal to own or distribute being placed on blockchains, e.g. links to child abuse on the Bitcoin blockchain . Since the dispersion of maliciously planted illegal data can de facto not be prevented in an open and decentralized network, liability of nodes would make participation in the network – even on the lowest possible involvement level – an unacceptable risk.

This is not legal advice, but luckily, jurisdictive interpretation appears to be moving in the direction of acknowledging, that nodes are not responsible for the stored data. Whereas this may (partly) solve the question of liability, it doesn’t answer the question of ownership in the sense of protecting intellectual rights .

It may be argued, that by putting data on a blockchain, one willingly accepts its unlimited replication and dispersion and thus also forfeits one’s rights of data ownership. In that case however, smart contracts in Tezos which are interpreted at runtime and thus originated (i.e. deployed) as readable source code , could legally be “stolen”. The fact that all comments are removed from the source code with origination doesn’t help either – so how do we protect our intellectual property?

For this aspect of the problem, we propose to include a field in every smart contract whose value contains a link to the license it is under . This may be a website or better yet, an entry in a register of the most common license on Tezos itself (as in this case, you cannot manipulate the licensing by plugging in another version of the license on the linked website).

Is this a feasible solution and would it solve the problem?


This work has been published by the work order of BMW AG and been contributed to the open source ecosystem through the ASC(S e.V. ENVITED Working Group with the goal of enabling virtually enhanced homologation processes.

5 Likes

Allowing contracts to carry metadata is a good idea. Software licenses seems like a very sensible field to carry but others could be helpful as well including

  • original source code and compiler version, if compiling from a high level language
  • documentation
  • contact information

This could take the form of a pair between

  1. the hash of a RDF document
  2. a URI where the document can be retrieved

This pair could be programmatically updatable from the contract. That way, it can be changed, but there’s a clear trace of what it was at different point in time. For instance, the user of a contract can retrieve and store the license at the time they use it for later proof. Alternatively, a simpler standard would have the pair remain unchanged after origination.

Suggested roadmap:

  1. start by embedding an IPFS hash as an annotation at the beginning of contracts
  2. develop an ontology for talking about the metadata in OWL or RDFS. Keep it simple to start with. Ontologies of licenses most likely already exist but the way
  3. as part of a protocol upgrade, introduce a proper field for URI + hash
  4. optional: introduce a michelson operation to change that field
7 Likes