-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create a new licensing non-fungible token standard request
- Loading branch information
Showing
1 changed file
with
194 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,194 @@ | ||
| --- | ||
| eip: 4636 | ||
| title: Licensing Token Standard | ||
| author: Bo Lin (@linvictor88), Dongsheng Shen (@d22shen), Danyang Li (@muren102) | ||
| discussions-to: https://ethereum-magicians.org/t/idea-licensing-token-standard-specially-for-licensing-relationshp/7924 | ||
| status: Draft | ||
| type: Standards Track | ||
| category: ERC | ||
| created: 2021-12-22 | ||
| requires: 4635 | ||
| --- | ||
|
|
||
| ## Simple Summary | ||
| Licensing non-fungible token (LNFT) is a standard interface for contracts that manage licensing token(s). LNFT relies on semi-fungible token standard (SFT) to manage types of fungible licenses and transformational non-fungible licenses. | ||
|
|
||
| ## Abstract | ||
| In Blockchain, non-fungible token (NFT) standard has been widely used to transfer the ownership value of digital asset. This standard proposes Licensing NFT which can also be delivered to get the use value. Owners of NFT can monetize more by delivering use/perform/exhibition right. The goal is to guideline LNFT interface and relative basic behavior definition for easy reading, analysis and future integration to LNFT trading platform. Any licensing relative smart contracts can rely on the LNFT to provide unified licensing services. | ||
|
|
||
| This standard defines 4 roles in the licensing service: License, Licensor, Licensee, and Vendor. Their definitions are as below: | ||
| 1. License | ||
| - License is an official permission or permit to do, use, or own something. For example, the license can be endowed to anything with meaningful value. We can wrap NFT to endow use-ability of this NFT to other people while keeping the owner-ship. We can endow CopyRight License on Smart Contract for codes copy-right announcement. We can also endow MemberShip License on Smart Contract as VIP for the dAPP use. | ||
| 2. Licensor | ||
| - Licensors are licensing providers who can buy licensing service and would deploy corresponding smart contracts on needs. | ||
| 3. Licensee | ||
| - Licensees are licensing customers who can buy licenses (LNFT in NFT type) from Licensors or Vendors to get permission of corresponding service use. | ||
| 4. Vendor | ||
| - Vendors are licensing sellers who can buy licenses (LNFT in FT type) from Licensors. | ||
|
|
||
| Based on above roles, licensing smart contract with LNFT supports these following main functions. | ||
| 1. LNFT inherits from SFT which can naturally process semi-fungible like licenses. | ||
| 2. LNFT allows Licensor/Vendor to issue one type of license (FT) to Licensee as NFT. | ||
| 3. Licensor can create multiple types of licenses and define corresponding license agreement. | ||
| 4. Licensee can get/check/activate/validate/trade the license. | ||
|
|
||
| ## Motivation | ||
| Several existing EIPs might be related with license but they are limited to granting ownerships such as EIP-1261, EIP-1753, and EIP-2615. | ||
| EIP-1261 defines membership verification token (MVT) with smart contracts. It can be used to keep track of individual membership in certain on-chain ‘organizations’. Even though, the author claims MVC can be applied in software licensing, it is limited to verify certain identity. The key point is still that MVC can be verified as a mix of multiple types of memberships (one person can have Amazon membership and Netflix membership at meanwhile) rather than apply the token to real commercial licenses. | ||
|
|
||
| EIP-1753 defines smart contract interface for licenses. The mentioned 'license' is more like an official ID or driver license, so the author hopes this eip can be applied by government or other regulations to issue some legal entities such as vehicle registration numbers. Similar to EIP-1261, the author does not consider traditional commercial licenses. | ||
|
|
||
| EIP-2615 tries to endow NFT with mortgage and rental functions by extending the NFT interfaces with renting and lending behavior. The extension is limited to the licensing scope which is not scalable. It is also difficult to implement the interface with existing NFT that will result in a total migration. | ||
|
|
||
| There should be more scenarios referring to use-ship without changing the owner. Music NFT owner can sell the listen-right to listeners, Art NFT owner can approve the show-right to exhibition, Smart Contract owner can permit the codes copyright by defining the License right, and DApp owner can give more benefits to users who owns membership LNFT. Hence, licensing should be taken as an attribute assigned with NFT instead of variety behavior. It's the LNFT owners who define specified licensing behavior and rules. Based on that, they can transfer the Licensing behavior easily like NFT. NFT standard doesn't do any change since LNFT should track licensing value. | ||
|
|
||
| ## 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. | ||
|
|
||
| NOTES: | ||
| - The following specifications use syntax from Solidity 0.8.0 (or above) | ||
|
|
||
| **Smart contracts implementing this standard MUST implement all the functions in the `ILNFT` interface.** | ||
|
|
||
| ```solidity | ||
| interface ILNFT is ISFT, ISFTMetadata, IERC721Metadata { | ||
| /** | ||
| @dev this emits when `_value` of new license type are minted. | ||
| The `_operator` argument MUST be the address of an account/contract that is approved to mint this type of token. | ||
| */ | ||
| event LicenseTypeMinted(address indexed _operator, address indexed _to, uint256 indexed _licenseType, uint256 _value, string _licensorName, string _desc, string _licenseName, string _licenseSymbol, bytes _data); | ||
| /** | ||
| @notice get the license issuer name who is the Licensor. | ||
| */ | ||
| function licensorName(uint256 _licenseType) external view returns(string memory); | ||
| /** | ||
| @notice get the license issuer address. | ||
| */ | ||
| function licensorAddress(uint256 _licenseType) external view returns(address); | ||
| /** | ||
| @notice get the license type name and symbol. | ||
| license name call {ISFTMetadata-semiName} | ||
| license symbol call {ISFTMetadata-semiSymbol} | ||
| */ | ||
| /** | ||
| @notice a simple introduction of this licensing contract purpose, use and some notices. | ||
| */ | ||
| function description(uint256 _licenseType) external view returns(string memory); | ||
| /** | ||
| @notice The license agreement URI of `_licenseType` license. | ||
| call {ISFTMetadata-semiURI} | ||
| */ | ||
| function agreementURI(uint256 _licenseType) external view returns(string memory); | ||
| /** | ||
| @notice create `_value` of new type of licenses. | ||
| @dev the caller would be the Licensor. | ||
| @dev only Licensor can do already minted `_licenseType` metadata change. | ||
| MUST revert if `_to` is the zero address. | ||
| MUST emit `LicenseTypeMinted` event to reflect the new license type creation. | ||
| @param _to address that `_licenseType` tokens assigned to. | ||
| @param _licenseType license type | ||
| @param _data the metadata for `_licenseType` | ||
| @param _value the number of tokens for `_licenseType` | ||
| call {ISFT-semiTypeMint} | ||
| */ | ||
| function licenseTypeMint(address _to, uint256 _licenseType, uint256 _value, string calldata _licensorName, string calldata _desc, string calldata _licenseName, string calldata _licenseSymbol, bytes calldata _data) external; | ||
| /** | ||
| @notice Mint one new license from the `_from` to the `_to`. | ||
| @dev Caller MUST be approved to manage the license being transferred out of the `_from` account. | ||
| MUST revert if `_to` is the zero address. | ||
| MUST revert if `_licenseType` is invalid | ||
| MUST revert on any other error. | ||
| @param _from source address | ||
| @param _to target address | ||
| @param _licenseType license type | ||
| @param _active mint license and set it to be active or not | ||
| @param _data the metadata for `_licenseType` | ||
| call {ISFT-semiMint} | ||
| */ | ||
| function licenseMint(address _from, address _to, uint256 _licenseType, bool _active, bytes calldata _data) external; | ||
| /** | ||
| @notice get the license type of `_licenseId`. | ||
| */ | ||
| function licenseType(uint256 _licenseId) external view returns(uint256 _licenseType); | ||
| /** | ||
| @notice activate/deactivate one license. | ||
| @dev the caller must be approved to do this operation. | ||
| */ | ||
| function setActive(uint256 _licenseId, bool _active) external; | ||
| /** | ||
| @notice check the license is activated. | ||
| */ | ||
| function isActive(uint256 _licenseId) external view returns(bool); | ||
| /** | ||
| @notice check the license is valid for use. | ||
| */ | ||
| function isValid(uint256 _licenseId) external view returns(bool); | ||
| /** | ||
| @notice validate _owner is the owner of `_licenseId` and `_licenseId` is valid. | ||
| */ | ||
| function validate(address _owner, uint256 _licenseId) external view returns(bool); | ||
| /** | ||
| @notice get license expired time with timestamp in seconds. | ||
| 2**256 -1 means inifinite | ||
| */ | ||
| function expireOn(uint256 _licenseId) external view returns(uint256); | ||
| /* | ||
| @notice Get license metadata URI. | ||
| call {IERC721Metadata-tokenURI} | ||
| { | ||
| license_type: _licenseType. | ||
| licensor_name: The entity issued the license who is the Licensor name. | ||
| licensor_address: The Licensor address who first minted the new `_licenseType` licenses. | ||
| vendor_address: The entity sold the product to Licensee. | ||
| is_valid: true/false. | ||
| is_active: true/false. | ||
| factory_time: Licensor first created this type of license (timestamp in seconds). | ||
| issue_time: time when this type of license is minted to Licensee (timestamp in seconds). | ||
| expire_time: time when license is expired (seconds in timestamp). | ||
| } | ||
| */ | ||
| function licenseURI(uint256 _licenseId) external view returns(string memory); | ||
| } | ||
| ``` | ||
|
|
||
| ## Rationale | ||
| Ethereum smart contracts can be used in purposes of license management such as issue/renew/revoke/track licenses. This will improve the efficiency of license government. Due to blockchain, the management process will be more transparent and thus be more fair to the end users. At meanwhile, ethereum blockchain can also protect the end users' privacy data. Since security and trust lie at the root of blockchain and LNFT is completely compatible with NFT standard, licensing-ship can be exchanged freely and securely across the entire world without third-party authentication. This would be a huge advantage for LNFT over other licensing frameworks. | ||
|
|
||
| ## Backwards Compatibility | ||
| All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. | ||
|
|
||
| ## Test Cases | ||
| Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. | ||
|
|
||
| ## Reference Implementation | ||
| **Standards** | ||
| - [ERC-721 Non-Fungible Token Standard](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md) | ||
| - [ERC-1261 XXX](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md) | ||
| - [ERC-1753 XXX](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1753.md) | ||
| - [ERC-2615 XXX](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2615.md) | ||
|
|
||
| **Implementations** | ||
| - [ERC-LNFT Reference Implementation](https://github.com/linvictor88/ERC-LNFT) | ||
| - [ERC-4635 Semi-Fungible Token Reference Implementation](https://github.com/linvictor88/ERC-SFT) | ||
|
|
||
| ## Security Considerations | ||
| All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. | ||
|
|
||
| ## Copyright | ||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |