ERC-5554: NFT Legal Use, Repurposing, and Remixing

An interface for describing and enforcing the legal use and remix of an NFT. On-chain registry of rights, attribution and derivative links.

Abstract

This EIP extends any other token standard to provide:

• Explicit rights for the token holder related to commercial exploitation, derivative works, and reproduction;
• EIP-5218 interface for creating, viewing, and checking the status of licenses
• Standard format for extended license information in the token metadata;
• Standard events to track off chain creation of derivative works, commercial exploitation, and reproduction;
• On chain tracking of derivative works and reproductions
• Additional required fields in the smart contract to reference the copyright owner
• Function calls for commercial exploitation, derivative works and reproduction.

Motivation

NFTs still face legal uncertainty, and many now realize that the rights associated with an NFT are just as important as the NFT itself. Our goal is to help the ecosystem reach clear consensus and broad understanding of what purchasers of NFTs are acquiring in terms of copyright or other rights.

Today, purchasing the NFT of a digital work is not the same as purchasing the copyright in that work. In most cases, the NFT does not even incorporate the digital work; it only references it via a hash. Hence, the NFT holder owns a unique digital copy of the work, but does not necessarily enjoy the right to reproduce, redistribute, or otherwise exploit that work—unless explicitly provided for by the copyright owner. It typically only includes the right to privately enjoy the work and display it publicly on social media or in virtual galleries.

We aim to create a new set of licenses with modular terms and conditions—à la Creative Commons—in order to enable artists to increase the value of their NFT by associating additional rights to them (e.g. the right to create derivative works, or to allow for the commercial usage of the underlying works). Our solution will allow for any licensed rights to be granted, only and exclusively, to the current holders of an NFT, and to be transferred automatically to the new token holders every time the NFT is being transferred.

An on chain registry of copyrighted material will help in discovery of the rights associated with the NFTs that have been created with this protocol.

Our current work is drafting the legalese and technical specifications.

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.

Every contract compliant with this EIP must implement the IERC5554 interface:

pragma solidity ^0.8.0;

interface IERC5554 is IERC5218 {

    event CommercialExploitation(uint256 _tokenId, uint256 _licenseId, string _externalUri);
    event ReproductionCreated(uint256 _tokenId, uint256 _licenseId, uint256 _reproductionId, address _reproduction, uint256 _reproductionTokenId);
    event DerivativeCreated(uint256 _tokenId, uint256 _licenseId, uint256 _derivativeId, address _derivative, uint256 _derivativeTokenId);

    /// @notice Retrieve the copyright owner address
    /// @dev Throws unless the token exists
    /// @param tokenId The identifier for the queried token
    /// @return address of the copyright owner
    function getCopyrightOwner(uint256 tokenId)
        external
        virtual
        returns (address);
    
    /// @notice Requests to log an execution of a license
    /// @dev Throws unless the token issuance conditions are met
    /// @param tokenId The identifier for the queried token
    /// @return uint256 tracking reproduction ID
    function logReproduction(uint256 tokenId, address reproduction, uint256 reproductionTokenId)
        external
        virtual
        returns (uint256);

    /// @notice Requests to log an executions of a license
    /// @dev Throws unless the token issuance conditions are met
    /// @param tokenId The identifier for the queried token
    /// @return uint256 tracking derivative ID
    function logDerivative(uint256 tokenId, address derivative, uint256 derivativeTokenId)
        external
        virtual
        returns (uint256);

    /// @notice Requests to log an execution of a license
    /// @dev Throws unless the commercial exploitation conditions are met
    /// @param tokenId The identifier for the queried token
    function logCommercialExploitation(uint256 tokenId, string calldata uri)
        external;

    /// @notice Retrieve the token associated with a reproduction
    /// @dev Throws unless the reproduction exists
    /// @param _reproductionId The identifier for the reproduction
    /// @return uint256 The identifier for the token used to generate the reproduction
    function getReproductionTokenId(uint256 _reproductionId)
        external
        view
        returns (uint256);

    /// @notice Retrieve the token associated with a reproduction
    /// @dev Throws unless the reproduction exists
    /// @param _reproductionId The identifier for the reproduction
    /// @return uint256 The identifier for the license used to generate the reproduction
    function getReproductionLicenseId(uint256 _reproductionId)
        external
        view
        returns (uint256);

    /// @notice Retrieve the token associated with a reproduction
    /// @dev Throws unless the reproduction exists
    /// @param _reproductionId The identifier for the derivative work
    /// @return address The address of the reproduction collection
    function getReproductionCollection(uint256 _reproductionId)
        external
        view
        returns (address);

    /// @notice Retrieve the token associated with a derivative
    /// @dev Throws unless the derivative exists
    /// @param _derivativeId The identifier for the derivative work
    /// @return uint256 The identifier for the token used to generate the derivative work
    function getDerivativeTokenId(uint256 _derivativeId)
        external
        view
        returns (uint256);

    /// @notice Retrieve the token associated with a derivative
    /// @dev Throws unless the derivative exists
    /// @param _derivativeId The identifier for the derivative work
    /// @return uint256 The identifier for the license used to generate the derivative work
    function getDerivativeLicenseId(uint256 _derivativeId)
        external
        view
        returns (uint256);

    /// @notice Retrieve the token associated with a derivative
    /// @dev Throws unless the derivative exists
    /// @param _derivativeId The identifier for the derivative work
    /// @return address The address of the derivative collection
    function getDerivativeCollection(uint256 _derivativeId)
        external
        view
        returns (address);

}

Token based Attribution/ Remix

On chain derivative works and reproductions

• Reproductions and derivative works are tracked in the contract.

Event based attribution

For commercial exploitation or other off-chain uses of a creative work, this EIP defines events to be emitted to track the use of the work.

event CommercialExploitation(uint256 tokenID, string uri)

function logCommercialExploitation(uint256 tokenId, string calldata uri) external returns bool;

Example:

When a token holder uses an NFT for off-chain merchandise, log a reference to the off-chain work in the event uri

Required fields

function copyrightOwner(uint256 tokenId) external returns address;

Copyright owner per tokenID. Could just be the tokenID owner in a simple use case, or something else if desired by the creator.

Rationale

We expand here upon the Motivation section to justify every decision made with regard to the specs of the standard:

The getLicenseId() function takes a tokenID as a parameter, making it possible for different tokenID to be associated with different licensing terms.

LicenseURI links to a content-addressed file that stipulates the terms and conditions of the license in actual legal language, so that the license can be read and understood by those who want to understand which rights are associated with the work of authorship, and which additional rights are granted through the acquisition of the NFT.

When the license allows for the reproduction and/or for the creation of a derivative work only to the token holders, there needs to be a way to verify that the new NFT or the derivative NFT was created legitimately. The standard ensures this by enabling the current token holder to call a function, e.g. logDerivative which checks that the caller has a valid license to execute

For commercial exploitation or other off-chain uses of a creative work, the standard implements the logCommercialExploitation() that makes it possible to keep track of which commercial exploitations have been made, and when. This makes it possible to verify that all commercial exploitation were legitimately done.

The standard introduces a new field, copyrightOwner, which indicates the address of the current holder of the copyright in the work. If multiple copyright owners exist, a multisig address (or DAO) can be used.

The artist address is not registered as an on-chain variable, but rather as part of the metadata, because it is an immutable field.

If any, the parents of the work (i.e. the works that it is derived upon) must be part of the metadata information, so that people can verify that the NFT has obtained a DerivativeWork for each one of its parents.

This licensing framework is intended to create a system to facilitate the licensing of rights that “follow the token” through a public licensing framework. This is not meant to be used for cases in which an exclusive right is licensed through a personal license to a specific actor (e.g. the copyright owner providing a third-party with the right to commercially exploit the work, regardless of whether they hold the token). This also is not designed to account for the sub-licensing case (e.g. licensing the right to one party to license third parties to engage in commercial exploitation), since this should rather be done via a personal copyright licensing scheme.

Examples

Bored Koalas merchandising

Vigdís creates a PFP collection of Bored Koalas, which is subject to standard copyright restrictions: no one has the right to reproduce, distribute, communicate, commercialize or remix these works. However, she wants to give specific permissions to those who hold a NFT from the collection. She mints the collection with this EIP, introducing a conditional license that allows for the current token holder to display the Bored Koala associated with each NFT and commercialize it for the purpose of merchandising only.

Neža has purchased one of these Bored Koalas. She wants to produce merchandising to be distributed at his blockchain conference. She goes to a print shop and asks them to make t-shirts with the Bored Koala image of the NFT she has purchased. The print shop can verify that she has the right to commercially exploit the work by verifying that they are the holder of the Bored Koala NFT, and verifying the terms of the license associated with it. (NB: this does not require a sub-license to be granted to the print shop, because the commercial exploitation implies the right to commission third parties to engage in such commercial exploitation). Neža brings the t-shirts to her conference and puts them for sale. When doing so, she calls the logCommercialExploitation() function from the NFT smart contract in order to track that the commercial exploitation was done at a time while she was the token holder.

Musical Remix

Matti is an up and coming songwriter in the emerging web3 music ecosystem. For the upcoming crypto conference, he creates a hit song called “Degens in the Night”. Instead of listing the song on a web2 platform, Matti mints the song as an NFT using this EIP, with a dual licensing scheme: a general public licenses that allows for the free reproduction and redistribution of the work, given proper attribution (e.g. Creative Commons BY-NC-ND) and a conditional license which allows for the token holder to remix the song, in exchange of a particular lump sum (e.g. 1ETH) and under the condition that the derivative work is released under the same licensing terms as the original work Lyyli wants to create a cover of that song, which she calls “Degens in the Parisian Night”. She purchases the NFT and mints a new derivative NFT under a new smart contract using this EIP standard. She then calls the requestDerivativeToken() function and send 1ETH to the original NFT smart contract, in order to request that a DerivativeToken be assigned to the new smart contract she has created. The smart contract automatically approves the request to assign a Derivative Token to the new smart contract of Lyyli. This can be used as a proof that the derivative work is indeed a legitimate work, which has been approved by the copyright owner of the original work. During the conference hundreds of other web3 music creators host a side event with Degens in the Night remixes playing until 4am.

Royalties Remix

Alice created a 3D model of a motorcycle, which she wants everyone to remix, under the condition that she gets royalty from the commercial exploitation of all derivative works. She release her work as an NFT with this EIP, with a dual licensing scheme: a general public licenses that allows for the free reproduction and redistribution of the work, given proper attribution (e.g. Creative Commons BY-NC-ND) and a conditional license which allows for the token holder to remix the song, under the condition that the derivative work is released under the same licensing terms as the original work, and that there is a split of the royalties between himself and the remixer.

Jane wants to create a derivative work of the motorcycle. She purchases the NFT and mints a new derivative NFT under a new smart contract that uses this EIP, which includes a royalty split for Alice. She then calls the requestDerivativeToken() function from the original NFT smart contract in order to request that a DerivativeToken be assigned to the new smart contract she has created. Alice decided that the smart contract shall not automate the approval or rejection of the request, but rather wait for her to validate or invalidate the request, after she has verified that the design and provisions of the new smart contract, namely that it does indeed replicate the same terms and conditions as the original work and that it incorporates the proper amount of royalties. She approves the request to assign a Derivative Token to the new smart contract of Jane. When people purchase Jane’s NFT, the royalties are split to ensure the proper redistribution of the generated profit to Alice.

Backwards Compatibility

The interface defined in this standard is backward compatible with most NFT standards used in the Ethereum ecosystem as of this writing.

Security Considerations

Needs discussion.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Isaac Patka (@ipatka), COALA Licensing Taskforce <info@coala.org>, "ERC-5554: NFT Legal Use, Repurposing, and Remixing [DRAFT]," Ethereum Improvement Proposals, no. 5554, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5554.