NFT License View

[joshuahannan]

Description

Builds on the view proposed in https://github.com/onflow/flow-nft/pull/172 that is based on the Flow NFT License Project.

Includes Media links for a badge and a description.

The specific IPFS format, link type, and locations for the links are going to be delayed for now so we can get the basic licenses and their descriptions on chain.

I also removed the JS tests because they were causing issues. We're gonna try to use the Cadence testing framework here from now on.

---

For contributor use:

• [x] Targeted PR against master branch
• [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• [x] Code follows the standards mentioned here.
• [ ] Updated relevant documentation
• [ ] Re-reviewed Files changed in the Github PR explorer
• [x] Added appropriate labels

[bluesign]

nit: do we have plans to register licenses with spdx ? if so it would be nice to use existing License struct, instead of strings in the array.

[joshuahannan]

@albeethekid Do you know the answer to the question about spdx?

[bluesign]

looks pretty good to me; but I have an idea; curious about what you think @joshuahannan

Now we have NFTLicense ( seems like this will be only used for NLP )

It has 5 building blocks:

access(contract) fun personalUse(): NFTLicense {
access(contract) fun votingRights(): NFTLicense {
access(contract) fun commercialRights(): NFTLicense {
access(contract) fun additionalContentExperienceRights(): NFTLicense {
access(contract) fun merchandisingRights(): NFTLicense {

We have 12 licenses. ( combination of these )

What if we take 5 blocks and making them public function (outside struct) , something like:

access(all) fun nlpVotingRights(): String{
    return "NLP-VOTE"  
}

and add a access(contract) setRights([String]) method or just take a string constructor to NFTLicense. (e.g. NLP-VOTE-COM ) depending on the license string we can set description, link, rights in the constructor directly. (with a switch maybe)

[joshuahannan]

@bluesign What is the benefit of the solution you've proposed here over what we already have?

[bluesign]

actually not much benefit just making API a bit smaller. if we make spdx compatible later, we can just put spdx identifier, these views can be generated from that automatically etc. But for now not much difference.