NFTs & IP 1: Practical Connections of ERC721 with Intellectual Property
How tools of IP can help creators and collectors better protect their rights and monetize
Summary
This article aims to improve understanding of Intellectual Property (IP), as a tool to help NFT creators and collectors. It gives a mini backgrounder on IP, then connects IP to ERC721 NFTs at Solidity code-level implementations.
Follow-up articles explore ERC20, and ERC721+ERC20 for NFTs & IP.
1. Introduction
1.1 “Your Keys, Your Bitcoin”
Ownership of a hundred dollar bill is straightforward: “if you hold it, you own it”. Same for a physical painting. Ownership of real-world objects is defined through physical access control [0]. This has benefits: it’s a simple mental model, it protects the owner, and transfer of ownership is easy.
We’re half a century into the computer era. Yet it hasn’t been easy to translate ownership of physical assets to intangible assets like electronic money or digital art. As a workaround, the world has used human-readable contracts for these intangible assets. Alas, these “wet-code” contracts are tedious to understand, expensive, slow, and error-prone. For example, “this 100-page document says you own it” 😬.
Then along came Bitcoin, a “dry-code” machine-readable approach to electronic money, with blockchain as the basis. Like real-world assets, ownership of digital assets is defined through access control. For Bitcoin this means “Your keys, your Bitcoin”. This gains the benefits of real world assets: simple mental model, protects the owner, and easy transfer of ownership. It’s cheaper, faster, and less error-prone than previous “wet-code” approaches to digital assets. Digital tools can track ownership of physical assets as well.
1.2 IP as a Tool → “Your Keys, Your NFT”
Inspired by Bitcoin, in 2013 we built ascribe for “dry code” digital art and other creative works. ascribe leveraged Bitcoin blockchain. Our mantra was “own digital art the way you own Bitcoin.” Blockchain technology helped creators and collectors secure their work and monetize.
Early on in ascribe, we discovered that Intellectual Property (IP) was an incredibly useful toolbox to help creators and collectors protect their rights and earn a living. The language and laws of IP go back literally centuries. All the books you’ve read, music you’ve heard, and movies you’ve watched have IP language backed up by laws to protect the authors, musicians and filmmakers.
So for ascribe, we used the language of IP to make the rights for creators & collectors maximally clear. It’s a powerful tool, and we leveraged it heavily. We also used legal contracts to help bridge the “wet code” world’s laws of IP.
Whereas ascribe was an early IP * blockchain project, IP * blockchain has now evolved into full-fledged field: NFTs. The mental model is all about access control: “your keys, your NFT.”
Ocean Protocol has been my focus for several years now. It’s about sharing, buying and selling data as an asset, by tokenizing digital access control. Since data is IP, Ocean is about data IP assets. “Your keys, your data.” In Ocean, we also leverage the language of IP and, as a bonus, legal contracts to bridge the “wet code” world’s laws of IP.
1.4 Outline
We’ve realized that our experiences over the last eight years may be helpful to others in the NFT field. The aim of this post (and subsequent posts) is to help clarify. This post is organized as follows.
Section 2 is an IP mini-backgrounder. In it, we introduce key terms from the language of IP — copyright, exclusive rights, licenses — along with a brief history and legal implementation.
Then in sections 3 and 4, we describe what the most popular NFTs standard — ERC721 — is doing from a framing of IP language, and how to leverage IP law for further protection.
- We do this for two specific cases: single-edition ERC721 (section 3) and limited-edition ERC721 (section 4).
- For each section, we first describe definitions — how “publish”, “sub-license”, “base IP”, “sub-licensee” etc is modeled in smart contracts and license terms. Then we provide a sequence diagram to illustrate the actions, followed by a structure diagram to show system state after each action. It’s fairly technical — we found this necessary in order to have enough clarity, all with the goal of protecting rights of creators and collectors.
2. IP Mini-Backgrounder
This section is a mini-backgrounder on intellectual property (IP), which is all about property of the intellectual variety.
IP and Copyright Law. Rights on digital art, physical art, music, books, and data all fall under IP law, specifically copyright law [1]. The Berne Convention of WIPO was signed by 179 countries including USA and Germany. Each country enacts its own laws according to its guidelines.
Copyright. The Convention provides creators “with the means to control how their work is used, by whom, and on what terms”. In it, the “creator of a work doesn’t need to apply for copyright, or to register it.” Rather, copyright automatically exists once it has been put it into “a fixed form”, e.g. as a recording on audio tape or as magnetic bits on a hard disk. However the Convention does suggest registration, to help prove that you’re the creator of the work in the event of fraud.
Exclusive Rights. If a publishing house “buys the rights” to an author’s work, they typically get an exclusive license (a contract) to use that work for their own profit. The base IP goes from the author to the publishing house. If a music label “buys the rights” to a musician’s work, the base IP goes from the musician to the label. And so forth.
Sub-licenses. When you buy an e-book, you’re buying the license to read it, for personal consumption. But you can’t re-sell 1000 copies, since your contract doesn’t include those rights. When you buy a song from iTunes, you’re buying the license to listen to it, for personal consumption. But you can’t re-sell it or play it on the radio, since you don’t have the license for that.
The rest of this article gets more technical. It describes what ERC721 code is doing from an IP perspective. We start with single-edition NFTs.
2. Single-Edition ERC721 code & IP
2.1 Definitions
This section describes how IP legals get implemented in Single-Edition ERC721 [3]. The two main actions are to publish and to sub-license. They’re defined, and represented as follows.
- To Publish means to claim base IP, i.e. copyright or initial exclusive license. This is implemented as ERC721._safeMint() at a new tokenId with to=self . To implement legals, metadata points to a T&C stating that _safeMint() is a claim of base IP.
- To Sub-license means transfer exclusive license to new exclusive licensee. This is implemented as ERC721.safeTransferFrom(). To implement legals, the T&C states that safeTransferFrom() is a sub-licensing action that grants specific rights.
Base IP, Base IP Holder, and Licensee are defined and represented as follows.
- Base IP means the artifact being copyrighted. Represented by the {ERC721 address, tokenId} from the publish transactions.
- Base IP holder means the holder of the Base IP. Represented as the the actor that did the initial “publish” action.
- Sub-licensee is the holder of the sub-license. Represented as the entity that controls address ERC721._owners[tokenId=x].
2.2 Single-Edition ERC721: Sequence Diagram
Here’s a worked example with focus on behavior. The corresponding image is below. We use a UML sequence diagram. Each arrow indicates a Solidity method call to the ERC721 contract. The origin of the arrow is the entity who initiated the call, such as publisher or licensee1. The arrows do not show value transfer, e.g. from publisher to licensee1. The UML structure diagram farther below helps to build intuition on the result of each method call.
Step ❶ is a Publish action. The publisher calls the deployed ERC721 contract’s _safeMint() method, keeping ownership to themselves (to=addressP). An ERC721 contract can hold many NFTs; therefore the publisher must specify which one (tokenId=7). The ERC721’s _owner attribute (a mapping) at tokenId=7 gets updated to addressP.
Step ❷ is an (exclusive) Sub-License action from Publisher to Licensee1. The publisher calls ERC721.safeTransferFrom() to send the NFT to Licensee1 (to=address1). The ERC721’s _owner attribute gets updated accordingly.
Step ❸ is an (exclusive) Sub-License action from Licensee1 to Licensee2. The ERC721’s _owner attribute gets updated accordingly.
2.3 Single-Edition ERC721: Structure Diagram
Here’s the same worked example, showing system state after each action. The corresponding image is below. It roughly follows the format of a UML Composite Structure Diagram .It focuses on which actor has which IP rights, i.e. who owns what.
After Step ❶ (Publish), the value for ERC721._owners at tokenId=7 is set to the publisher’s address (addressP). As the NFT hasn’t been transferred yet, then the entity at this address can be interpreted as the base IP holder.
After Step ❷ (exclusive Sub-License), the value for ERC721._owners at tokenId=7 is now set to address1. The address1 owner is the exclusive licensee. Since the license is exclusive, this entity is also the Base IP holder.
After Step ❸ is like ❷, except now the address2 owner is exclusive licensee and Base IP holder.
3. Limited-Edition ERC721 Code & IP
3.1 Definitions
Limited-edition NFTs means there are several NFT tokens for the same base IP [4]. Each token is its own edition.
Each edition may be considered fungible or non-fungible:
- Fungible if the edition can be swapped with another edition and no one cares. For example, a digital visual artwork in a gif has 10 limited editions available and there are no serial numbers. Or an e-book novel with 1000 limited editions.
- Non-fungible if a swap does matter. For example, the NFT has a history of ownership or usage (provenance) that influences the price. Or collectors assign higher value to a particular edition number (“edition 3 is more valuable than edition 17”).
Here’s the implementation using ERC721. It would be fairly similar if using ERC1155; for ease of reading we will focus on ERC721.
- To Publish means to claim base IP, ready for sub-licensing of limited editions. This is implemented as one ERC721._safeMint() call for each edition. Each call has a unique tokenId input. The IP claim is being made a separate time for each call; this works assuming one address does all initial minting.
- To Sub-license means to transfer one (of many) sub-licenses to a new licensee. This is implemented as ERC721.safeTransferFrom().
- Base IP: represented by the {ERC721 address, tokenId} from the publish transactions.
- Base IP holder: whoever performed the initial publish actions.
- Sub-licensee: the owner of address ERC721._owners[tokenId=x,y,z] (example of 3 editions).
3.2 Limited-Edition ERC721: Sequence Diagram
Here’s a worked example focusing on behavior. There are 3 limited editions.
Step ❶ is a Publish action. The publisher calls _safeMint() method three separate times, specifying tokenId=7, 8, and 9 for each edition.
Step ❷ is a Sub-License action of the edition with tokenId=7, from Publisher to Licensee1. The limited edition for tokenId=7 is sub-licensed to Licensee1 (address1). This method call is a non-exclusive sub-license; compare to an exclusive sub-license for the same call in the single-edition ERC721 case.
Step ❸ is a Sub-License action of the edition with tokenId=7 from Licensee1 to Licensee2.
Step ❹ is a Sub-License action of the edition with tokenId=8.
3.3 Limited-Edition ERC721: Structure Diagram
Here’s the same worked example, showing system state after each action.
When Completed ❶ (Publish), the ERC721._owners at tokenId=7, 8, and 9 are set to the publisher’s address (addressP). As the NFT editions haven’t been transferred yet, the addressP owner is interpreted as the base IP holder.
When Completed ❷ (Sub-License), the value for ERC721._owners at tokenId=7 is now address1, meaning the address1 owner is sub-licensee for edition tokenId=7. The Base IP holder remains the Publisher (addressP). There isn’t an explicit way to do an exclusive sub-license of the base IP. This has a different interpretation than single-edition ERC721, where the same method call means an exclusive sub-licensing of the Base IP.
When Completed ❸ ❹, then the address2 owner is sub-sub-licensee for edition tokenId=7, and the address3 owner is sub-licensee for edition tokenId=8. The Base IP holder remains the Publisher (addressP).
4. Conclusion
This article aimed to improve understanding of Intellectual Property (IP), as a tool to help creators and collectors. It gave a mini backgrounder on IP, then connected IP to ERC721 NFTs in Solidity implementations.
Subsequent articles cover IP*blockchain implementations in ERC20 (link) and ERC721+ERC20 (link).
Acknowledgements
Thanks to the following people who contributed to this article and follow-on articles in this series. Thanks to Ocean Protocol core team for detailed discussions on IP with ERC721, ERC20, and most recently combined ERC721 + ERC20 discussions with Alex Coseru and Andrea Burzi. Thanks to Tim Daubenschütz, Fabian Vogelsteller, Simon de la Rouviere, Wilkins Chung, Lisa JY Tan, and Re’em Sal for reviewing the article. Thanks to RAC, Kevin Abosch, Carlos Moreira, Chris Boos and others for recent invigorating discussions on blockchain * IP.
Thanks to all those who helped lay the intellectual foundations of blockchain * IP all those years ago in ascribe, COALA IP, and elsewhere, including: Masha McConaghy, Bruce Pon, Yanislav Malahov, Greg McMullen, Tim Daubenschütz, Alberto Granzotto, Primavera de Filippi, Constance Choi, Simon de la Rouviere, Juan Benet, and many more.
Finally, thanks to all the awesome creators who inspire us to make better tools. 🙏 to you all!
Notes
[0] Thanks to Fabian Vogelsteller for this framing: “in the physical world, ownership is defined through physical access control”.
[1] Patents and trademarks are also forms of IP, and would mostly fit the token mechanics of this article too. But let’s focus on copyright.
[2] The ascribe Terms and Conditions (T&C) circa 2015 are at: https://web.archive.org/web/20160606190958/https://www.ascribe.io/terms/
[3] Throughout this article, we use the OpenZeppelin Solidity implementation of ERC721 and ERC20, to keep things as tangible as possible. However this generalizes to other implementations, other token standards, and other languages / virtual machines.
[4] In NBA Top Shots and other limited-edition ERC721s where serial number isn’t shown / doesn’t matter, then one ERC721 edition is directly interchangeable with the other editions. That is, it’s fungible. It looks like a paradox, given that NFT = non-fungible token. We can resolve this by simply realizing that the label “NFT” is also a field that merrily includes both non-fungible and fungible concepts. It just happened that that “NFT” label took off, and here we are.
