# NFT License Metadata Standard

## Summary

An interface for a non-fungible token license metadata. The goal is to add license agreements and corresponding metadata to non-fungible tokens.

## Motivation

TODO: The NFT and NFT Metadata standards provides a minimal interface for minting, ownership and transfer of NFT tokens and their associated metadata. This simple interface does not cover many important use-cases of NFTs related to licensing such as Intellectual property (IP) protection, legal compliance, and licensing revenue generation.

License capabilities enhance for NFTs (Non-Fungible Tokens) for several reasons:
- Intellectual property protection: NFTs can represent unique digital assets such as art, music, and video. By licensing these assets, creators and owners can control how they are used and ensure that they are properly compensated for their work.

- Legal compliance: NFTs are subject to laws and regulations related to intellectual property, copyright, and other forms of digital assets. Licensing helps ensure that NFTs comply with these laws and regulations.

- Revenue generation: Licensing NFTs can provide a revenue stream for creators and owners by enabling them to sell their digital assets or charge for their use.

- Transparency: Licensing provides a clear understanding of the terms and conditions of NFT ownership, usage, and distribution. This helps to avoid confusion or disputes over NFTs and ensures that everyone involved understands their rights and obligations.

Licensing is an important part of the NFT ecosystem and helps to protect the rights of both creators and NFT owners supporting the the growth and development of the overall NFT market.

This standard is an extension of NFT standard enabling token creators to set license information and provides for a standard location for consumers of NFTs, such as marketplaces, to retrieve license information from tokens. NEAR's unique storage staking approach makes it feasible to store license parameters, such as personal or commecial use, on-chain to enable smart contacts to programatically interact with the licenses. License information can be set at the contract level or on a per token basis with the license information at the token level having priority.

## Rationale and alternatives

This design is the best because ...

This proposal provides the common scaffolding needed to bind license agreements to NFTs while providing for flexibility in the actual licenses used. This proposal includes per-token granularity for the use cases that require this functionality and a storage efficient per contract option for those that do not.

Other alternative designs considered were:

1. Extend the NFT Metadata Standard. This was not chosen because often times the token owner is not the license administrator. License information should be updatable independent from the token metadata.
2. Only contract level license metadata. This does not enable common use cases such as different license types or different validity periods per token.
3. Only token level license metadata. This would add unnecessary storage overhead for use cases that do not need per token based licensing such as traditional collectibles where all tokens share the same license.
4. Defining specific licenses with corresponding enums. This was not selected because there will be a wide variety of licenses that will be used. This functionality can be built on top of this proposal if desired. Too rigid

## Specification

Explain the proposal as if it was already implemented and you were teaching it to another developer. That generally means:

- Introducing new named concepts.
- Explaining the feature largely in terms of examples.
- If the feature introduces new abstractions, explaining how users and/or developers should _think_ about it;
- If applicable, describe the differences between the existing functionality.

New terminolgy that is now introduced:
- License - A human readable legal agreement between two parties in which the licensor grants the licensee rights to utilize some form of intellectual property.
- License Metadata - A combination of the human readable license agreement and optional machine readable data related to the license.
- Intellectual property: Range of legal rights that protect the creations of the mind and creativity.
- Issuer - The licensor who creates the license agreement and bound by the terms. The license issuer may be different from the minter of the token.
- Token Holder - The licensee who is bound by the license agreement.
- License Hash - The output of a cryptographic function applied to a digital license that can used to validate the linked license has not been modified. Content addressable storage systems such as IPFS have this functionality built in and do not require an external hash.
- Per Contract Licensing - An option where all tokens minted from a smart contract share a common license and license metadata.
- Per Token Licensing - An option where each token has the ability to set its own license and license metadata.

For user-facing NEPs, this section should focus on user stories.

User Story

1. Creator mints an NFT and wants to include a license for the art that clearly describes what rights the token holder has to the artwork.
2. Creator uploads a license on IPFS
3. Links the IPFS license to the NFT through license (and optionally extra, reference and reference_hash)
4. Wallets and marketplaces can read and display the license parameters from the NFT so that current and future buyers are aware of the licensing terms associated with the NFT.
5. Optionally minting contracts, platforms and marketplaces can build smart contracts or other mechanisms that enforce the licensing terms defined in the license metadata.

## Reference Implementation (Required for Protocol Working Group proposals, optional for other categories)

This is the technical portion of the NEP. Explain the design in sufficient detail that:

- Its interaction with other features is clear.
- Where possible, include a `Minimum Viable Interface` subsection expressing the required behavior and types in a target Near Contract language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
- It is reasonably clear how the feature would be implemented.
- Corner cases are dissected by example.

Interface

License Metadata Type

type LicenseMetadata = {
  spec: string, // required, essentially a version like "lc-2.0.0", replacing "2.0.0" with the implemented version of this spec
  title: string|null, // License agreement title  "Veriken personal license" or "Creative commons license"
  description: string|null, // free-form license description
  issuer: address // Required, NEAR account/contract, must set, may be different than minting account/contract
  license: string|null, // Required, URL to off-chain human readable license agreement,, preferably to decentralized, content-addressed storage
  license_hash: string|null, // Base64-encoded sha256 hash of content referenced by the `license` field. 
  extra: string|null, // anything extra the NFT wants to store on-chain. Can be stringified JSON of license policy rules, version, template library
  reference: string|null, // URL to an off-chain JSON file with more info.
  reference_hash: string|null // Base64-encoded sha256 hash of JSON from reference field. Required if `reference` is included.
}

One new functions **MUST** be supported on the NFT contract that sets the version and provides **OPTIONAL** license parameters that apply to every token:

function nft_license_metadata(): LicenseMetadata {}

A new license attribute **MAY** be added to each Token struct if per token licensing is desired. Per token license data takes priority over license data set at the contract level.

type Token = {
	token_id: string,
	owner_id: string,
	metadata: TokenMetadata,
+	license:  LicenseMetadata,
}

LicenseMetadata:

An implementing contract **MUST** include the following fields on-chain at the contract level **AND** at the token level **IF** per token licensing is used.

- `spec`: a string. Should be lc-1.0.0 to indicate that a NFT contract adheres to the current versions of this License metadata and the Non-Fungible Token Core and Metadata specs. This will allow consumers of the Non-Fungible Token to know if they support the features of a given contract.

An implementing contract **MUST** include the following fields on-chain at either the contract level **OR** the at the individaul token level. If both are set, the token level information takes priority.

- `license`: URL to off-chain human readable license agreement, preferably to decentralized, content-addressed storage

An implementing contract **MAY** include the following fields on-chain at either the contract level **OR** the at the individaul token level. If both are set, the token level information takes priority.

- `title`: License agreement title such as "Veriken personal license" or "Creative commons license"
- `description`: Free-form license description
- `issuer`: Account or contract that issued the license
- `license_hash`: Base64-encoded sha256 hash of content referenced by the `license` field.
- `extra`: Anything extra the NFT wants to store on-chain. Can be stringified JSON of license policy rules, version, template library
- `reference`: URL to an off-chain JSON file with more info.
- `reference_hash`: Base64-encoded sha256 hash of JSON from reference field. Required if `reference` is included.

## Security Implications (Optional)

If there are security concerns concerning the NEP, those concerns should be explicitly written out to make sure reviewers of the NEP are aware of them.

## Drawbacks (Optional)

Why should we **not** do this?

## Unresolved Issues (Optional)

- What parts of the design do you expect to resolve through the NEP process before this gets merged?
- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
- What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?

## Future possibilities

Think about what the natural extension and evolution of your proposal would
be and how it would affect the project as a whole in a holistic
way. Try to use this section as a tool to more fully consider all possible
interactions with the project in your proposal.
Also, consider how all fits into the roadmap for the project
and of the relevant sub-team.

This is also a good place to "dump ideas"; if they are out of scope for the
NEP you are writing but otherwise related.

If you have tried and cannot think of any future possibilities,
you may simply state that you cannot think of anything.

Note that having something written down in the future-possibilities section
is not a reason to accept the current or a future NEP. Such notes should be
in the section on motivation or rationale in this or subsequent NEPs.
The section merely provides additional information.

## Copyright

[copyright]: #copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

---------------------------------------------------

Prior art:

- NEAR Non Fungible Token Standard: #171
- NEAR Non Fungible Token Metadata Standard: #177