ERC-5635: NFT Licensing Agreements

Abstract

---

This EIP standardizes an NFT licensing oracle to store (register) and retrieve (discover) granted licensing agreements for non-fungible token (NFT) derivative works, which are also NFTs but are created using properties of some other underlying NFTs.

In this standard, an NFT derivative work is referred to as a dNFT, while the original underlying NFT is referred to as an oNFT.

The NFT owner, known as the licensor, may authorize another creator, known as the licensee, to create a derivative works (dNFTs), in exchange for an agreed payment, known as a Royalty. A licensing agreement outlines terms and conditions related to the deal between the licensor and licensee.

Specification

---

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

In general, there are three important roles in this standard:

• oNFT: An original underlying NFT. The holder of an oNFT is a licensor. An oNFT can be any NFT.
• dNFT: A derivative work based on one or more oNFTs. The holder of a dNFT is a licensee.
• Registry: A trusted smart contract able to verify whether a credential is signed or released by the holder of oNFT.

Every dNFT contract must implement the IERC5635NFT and IERC165 inferfaces.

Every Registry contract must implement the IERC5635Registry and IERC165 inferfaces.

The Registry contract MAY implement the IERC5635Licensing and IERC165 inferfaces.

Rationale

---

Licensing credentials from a dNFT's contract can be retrieved with authorizedBy, which specifies the details of a licensing agreement, which may include the oNFT. Those credentials may be verified with a registry service.

Anyone can retrieve licensing royalty information with licensingRoyalty via the registry. While it is not possible to enforce the rules set out in this EIP on-chain, just like EIP-2981, we encourages NFT marketplaces to follow this EIP.

Two stages: Licensing and Discovery

Taking the moment when the dNFT is minted as the cut-off point, the stage before is called the Licensing stage, and the subsequent stage is called the Discovery stage. The interface IERC5635Licensing is for the Licensing stage, and the interfaces IERC5635DNFT and IERC5635Registry are for the Discovery stage.

Design decision: beneficiary of licensing agreement

As soon as someone sells their NFT, the full licensed rights are passed along to the new owner without any encumbrances, so that the beneficiary should be the new owner.

Difference between CantBeEvil Licenses and Licensing Agreements.

CantBeEvil licenses are creator-holder licenses which indicate what rights the NFTs' holder are granted from the creator. Meanwhile, licensing agreements is a contract between a licensor and licensee. So, CantBeEvil licenses cannot be used as a licensing agreement.

Design decision: Relationship between different approval levels

The approved address can license() the licensing agreement to dNFT on behalf of the holder of an oNFT. We define two levels of approval like that:

1. approve will lead to approval for one NFT related to an id.
2. setApprovalForAll will lead to approval of all NFTs owned by msg.sender.

Backwards Compatibility

---

This standard is compatible with EIP-721, EIP-1155, and EIP-2981.

Reference Implementation

---

Examples

Deploying an EIP-721 NFT and signaling support for dNFT

Checking if the NFT being sold on your marketplace is a dNFT

Checking if an address is a Registry

Security Considerations

---

Needs discussion.

Copyright

---

Copyright and related rights waived via CC0.