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.
6 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
- the hash of a RDF document
- 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:
- start by embedding an IPFS hash as an annotation at the beginning of contracts
- 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
- as part of a protocol upgrade, introduce a proper field for URI + hash
- optional: introduce a michelson operation to change that field
8 Likes
Great points for discussion and consideration.
Data ownership and privacy issues will become more pressing as the amount and type of data stored on-chain increases.
Regarding confidentiality rights in data/metadata stored on public blockchains - assuming that persons publishing data on-chain have the legal authority to do so - I believe these rights are implicitly waived through publication to a public ‘on-chain’ medium. Where a level of privacy is to be retained, the use of zero-knowledge proofs may assist as the technology continues to advance.
However, zero-knowledge proofs may not solve some of the intractable privacy law issues that arise where personal information (or personally identifiable information) is published without consent, or where consent is obtained but individuals have a statutory right in their local jurisdiction to remove or modify personal information written to an immutable blockchain. A 2019 European Parliament study identified zero-knowledge proofs as a potential solution to this problem but raised doubt about whether the technique can sufficiently anonymize the data.
Regarding ownership of intellectual property rights in published data/metadata/compiled smart contracts (and not the underlying assets they may represent), in most jurisdictions, the persons/organizations publishing data and compiled smart contracts on public blockchains will retain copyrights in the expressive components of their data - and the bigger challenge may be enforcement. In addition to copyright principles generally applicable to software, historical “phonebook” copyright cases that help define rights in the organization of common data may be instructive.
I believe that increased clarity in the ownership, licensing or waiver of IP rights in on-chain data will help encourage broader business adoption of the technology.
Hypothetically, a public blockchain can impose a form of default licensing through its own open-source license.
A more flexible approach may be to adopt data and licensing taxonomies (or ontologies as appropriate) and require a license statement for smart contracts to meet a specific standard. This may prove to be a fairly simple and efficient way to address the IP ownership issues, as smart contracts are more likely to carry data in which copyrights may exist. A reference or implementation standard could also require that every smart contract in that standard adopt a specific form of license (eg. FA 2.0M is MIT, FA 2.0C is CC0, etc.)
Your original posts inspired me to expand on these thoughts in a recent Medium post.
Thank you for pushing this conversation forward.
2 Likes
Thanks for sharing the great information.
