Metadata Views: Full License View

[joshuahannan]

Issue To Be Solved

Flow is working with governments to define a standard for how NFT projects can define licensing rights for NFTs that define permissions for what can be done with them and their metadata by the owner. The current License view does not sufficiently cover the needs for a full license view, so we would like to define a new one that projects can start using.

Suggest A Solution

• Decide if we want to define a new view, or modify the old one. (probably need to define a new one)
• Decide which fields are needed Options:
  • plain text description
  • ipfs hash
  • file
  • multiple licenses?

We'll post and discuss more in this issue

[bluesign]

is this Dapper Labs as Flow Team, or Dapper Labs as Dapper Wallet ? ( called Dapper Studio I guess if not different entity) or is it Dapper Labs as Dapper Foundation ?

In general I don't have problem with this issue, but I feel like that this can be used as a stepping stone of license enforcement on Flow Blockchain ( by Flow Protocol or Service Account ), so I think it would be nice to make that clear from the beginning.

[joshuahannan]

@psiemens @EricLin2004 Would you be able to elaborate a bit more on what is required for this? I want to make sure this is pretty clear

[joshuahannan]

Here are two documents that our legal team has put together for how we envision this. I'll try to respond again later this week with some ideas for how I might want to implement this but any ideas or feedback in the meantime is appreciated. :)

[joshuahannan]

[joshuahannan]

[bluesign]

This is very good idea, as long as Flow Team ( blockchain ) does not enforce this, just for user information and user trust, I think it will be beneficial to ecosystem.

But from the look of the chart seems grouping is not so well.

• Why Voting Rights and Content and Experiences mutually exclusive?

If we exclude the full ownership for a second:

• There are 5 Groups ( 3 Colors ) with first 6 license items out of 10 are same.

We can summarize with 2 questions:

• Do you want commercial license? ( no / limited / unlimited )
• Do you want additional utility? ( Voting / Content / Skip )

I think very poorly designed tbh. Maybe even multiple badges can cover better. ( e.g. base & commercial & voting )

Even technically those rights can be interfaces, and can be combined later. Or you can maybe upgrade your NFT later for another license.

• "subject to potential approval of content creator" I think here can be a little push on the content provider side.

[joshuahannan]

We can summarize with 2 questions: Do you want commercial license? ( no / limited / unlimited ) Do you want additional utility? ( Voting / Content / Skip ) I think very poorly designed tbh. Maybe even multiple badges can cover better. ( e.g. base & commercial & voting )

Are you saying that instead of indicating which group an NFT belongs to in this view, we just provide answers to these two questions with an enum or something? It isn't clear what you are suggesting.

"subject to potential approval of content creator" I think here can be a little push on the content provider side.

Can you elaborate here? I'm not sure what you mean

[bluesign]

Are you saying that instead of indicating which group an NFT belongs to in this view, we just provide answers to these two questions with an enum or something?

I meant If we want to make a generic license view, we should have an array of granted permissions on chain, rest should be up to dapp to show. e.g coloring/badging

Something like this:

License( name='Base NFT License' , rights=
[
   LicenseGrant(Code: License.PERSONAL, Text: 'Use content for personal use', Link: HttpLink('https://license.dapperlabs.com/personal')),
   LicenseGrant(Code: License.RESELL, Text: 'Resell short description', Link: HttpLink('https://license.dapperlabs.com/personal')),
])

Can you elaborate here? I'm not sure what you mean

Content providers will rarely grant this, so it is better to make this separate right. I mean License View should describe in full, it should not leave part like: " depends on provider "

[psiemens]

This is very good idea, as long as Flow Team ( blockchain ) does not enforce this, just for user information and user trust, I think it will be beneficial to ecosystem.

Definitely not something we'd enforce, just an optional tool for NFT developers.

I meant If we want to make a generic license view, we should have an array of granted permissions on chain, rest should be up to dapp to show. e.g coloring/badging

I was imagining something simpler: just a name, optional text and link rather than having all the different components of the license on the chain. A user would have to download the linked license (or read the text) to understand all the parts. Reason being that I'm not sure every license (now and in the future) can be so nicely (and legally) split into pieces.

But I'm not a lawyer! I'll get an opinion from the lawyers who drafted the framework above.

[turbolent]

Maybe the existing license metadata should be renamed to indicate it is a software license?

I really like the idea of machine-readable license information. It would be great to have a Rights Expression Language for Cadence.

The Creative Commons organization has done a lot in this space over the years, maybe we can adopt their ccREL?

W3C's ODRL looks even more expressive.

[psiemens]

I clarified a few things based on the discussion here.

• The columns in the chart are not mutually exclusive. For example, an NFT can be in both group 2A and 2B, in which case the holder will have both voting rights and access to content/experiences. It's a union of the checked cells.
• The chart above is not a license itself, but rather a visual representation to help holders understand their rights and allow wallets, marketplaces, etc to parse and display the rights in a human-readable way. A developer would still need to link to a separate license document.
  • I flagged that this would likely cause confusion. IMO most developers will assume that they can use this view in the same way as a ready-to-use software license (e.g. like Apache, MIT, etc). Waiting to hear back on other possibilities here.

[joshuahannan]

So what I am hearing from the discussion here is that we can do something simple like @psiemens suggests, but it would still be good to have the information accessible on chain, like @bluesign says:

Here is a basic view structure that might work. let me know if I am not understanding something properly here

pub enum LicenseCategory {
    pub case PERSONAL
    pub case VOTING
    pub case CONTENT
    pub case LIMITED_COMMERCIALIZATION
    pub case UNLIMITED_COMMERCIALIZATION
    pub case FULL_OWNERSHIP
}

// Not sure what to name it here
pub struct NFTLicenseInfo {

    pub let rights: LicenseCategory

    pub let description: String

    pub let httplink: HTTPLink?

    pub let ipfslink: IPFSLink?

    init(category: LicenseCategory) {
        switch LicenseCategory {
        case PERSONAL:
            self.description = "Use content for personal use"
            self.httplink = HttpLink('https://license.dapperlabs.com/personal')
            self.ipfslink = IPFSfile(....)
         case VOTING:
            self.description = "Use for voting purposes"
            ...
            ...
            /// and so on and so forth

}

pub fun getLicenseInfo(category: LicenseCategory): NFTLicenseInfo {

    return NFTLicenseInfo(category: category) 

}

// The actual view that the view resolver could return
pub struct NFTLicenses {
    pub let rights: [NFTLicenseInfo]
}

[satyamakgec]

So what I am hearing from the discussion here is that we can do something simple like @psiemens suggests, but it would still be good to have the information accessible on chain, like @bluesign says:

Here is a basic view structure that might work. let me know if I am not understanding something properly here

pub enum LicenseCategory {
    pub case PERSONAL
    pub case VOTING
    pub case CONTENT
    pub case LIMITED_COMMERCIALIZATION
    pub case UNLIMITED_COMMERCIALIZATION
    pub case FULL_OWNERSHIP
}

// Not sure what to name it here
pub struct NFTLicenseInfo {

    pub let rights: LicenseCategory

    pub let description: String

    pub let httplink: HTTPLink?

    pub let ipfslink: IPFSLink?

    init(category: LicenseCategory) {
        switch LicenseCategory {
        case PERSONAL:
            self.description = "Use content for personal use"
            self.httplink = HttpLink('https://license.dapperlabs.com/personal')
            self.ipfslink = IPFSfile(....)
         case VOTING:
            self.description = "Use for voting purposes"
            ...
            ...
            /// and so on and so forth

}

pub fun getLicenseInfo(category: LicenseCategory): NFTLicenseInfo {

    return NFTLicenseInfo(category: category) 

}

// The actual view that the view resolver could return
pub struct NFTLicenses {
    pub let rights: [NFTLicenseInfo]
}

I like the idea of keeping it simple, however, It seems confusing to me when we divide the license category as per the voting or whatnot. I like the idea of @bluesign, where the license can be broadly divided into two categories, and we can have subcategories. ex - Utility (voting/content/skip). Right now, it is a flat structure that can also work unless it creates confusion

[satyamakgec]

@joshuahannan, I think we need to look into this as well. Today a16z released this https://a16zcrypto.com/introducing-nft-licenses/ they are using what @turbolent proposes creative common stuff.

[satyamakgec]

@joshuahannan, I think we need to look into this as well. Today a16z released this https://a16zcrypto.com/introducing-nft-licenses/ they are using what @turbolent proposes creative common stuff.

They have more or less the same as what we have above.

[jrkhan]

I believe this might be well outside the scope of the current proposal, but leaving room for further elaboration on "derivative works" might be helpful (a separate view perhaps?). I believe there's an opportunity to facilitate licensing of IP through smart contracts, and having a more expressive language for this would likely be helpful. Pie in the sky examples:

• A musician gives away NFTs of their latest track - the NFT contains a NFTDerivitiveWork royalty of 5% -> a YouTube/TikTok user holding the NFT could then use this as background music in their video, and the original musician would receive 5% of any revenue from the video.
• A major IP holder would like to temporarily support officially licensed fan art for an upcoming project , but the cost of contract negotiations with individual artists is high -> an artist could obtain an NFT granting them the right to create a derivative work, but the derivative work would be "subject to approval of the content creator". This would allow NFT holders to submit derivative works for the original content creators approval (in the form of an on chain transaction).
• An IP holder wishes to subdivide the rights to different products for their IP, granting the rights to produce merchandise of a variety of categories as separate NFTs.

While I understand it's likely outside the scope of this proposal, I believe a more expressive language for granting derivative works rights would be helpful, and hoping we can find a way to represent this as a gray area here in the short term in cases where content creators are not satisfied with a bool.

[bjartek]

Maybe the existing license metadata should be renamed to indicate it is a software license?

That was never the intention from my part. The intention was always that the view was content lisence and that you should use relevant identifiers in SPDX that are content based like https://spdx.org/licenses/CC-BY-4.0.html.

[bjartek]

Another relevant post popped up recently https://a16zcrypto.com/introducing-nft-licenses/

[bjartek]

Another aspect to all of this that I personally feel is important is the mutability of said license. Changing the license of an NFT is problematic at best horrible at worst. There are examples on projects doing this in ETH and it was nasty.

[bjartek]

> pub struct NFTLicenseInfo {
>     pub let httplink: HTTPLink?
> 
>     pub let ipfslink: IPFSLink?

>

the links should be MetadataViews.Media here IMHO, as they have both a file/url and a content/type. Somebody might want to store a PDF version in ipfs and a html/plan-text version in http.

[bluesign]

Another aspect to all of this that I personally feel is important is the mutability of said license. Changing the license of an NFT is problematic at best horrible at worst. There are examples on projects doing this in ETH and it was nasty.

I think mutable is the correct way legally although I agree with you totally on problematic side.

Btw @psiemens can we invite some ecosystem people ( like Dapper Studio etc ) to this discussion directly ? I mean obviously licenses are designed to protect their rights, not user’s

[bjartek]

I also think we kind of need mutability, but should we have some way then to track when this license was changed? and have a version to check when the previous version was added or something?

[bjartek]

This view would be very useful for Doodles, can we try to get this through the door?

[bluesign]

Yeah covers #150 too @bjartek , I think minimal solution is the best for start, we can call it SimpleLicenseView or something, with grants inside

[bjartek]

I would think so yes

[joshuahannan]

Yeah, I'm pinging the relevant people to see if any of their ideas have changes and I'm gonna get them to join in the conversation on this thread as well. I also closed #150 so we can concentrate discussion here.

[franklywatson]

Hi All,

Flow core team is seeking legal guidance on NFT licenses and we believe that a standard view for licenses declared by the NFT minter remains the right path forward. We will be calling for a community working group to advance this topic forward once we have more clarity but this is one of the top priorities for the ecosystem. We will soon follow up with an update on our proposal for licensing in NFT views and then brainstorm in the working group. We recognize that, despite the options, licenses won’t be right for every project, and that the licensing needs of projects will change as rapid innovation tirelessly drives the space in new directions. Thanks for your patience

[louisguitton]

Flow core team is seeking legal guidance on NFT licenses and we believe that a standard view for licenses declared by the NFT minter remains the right path forward. We will be calling for a community working group to advance this topic forward once we have more clarity but this is one of the top priorities for the ecosystem.

My legal counsel colleague might be able to help @franklywatson. I'll DM you.

[joshuahannan]

@albeethekid Shared a new proposal that the Flow team is working on with Creative Commons for NFT Licenses. We'd like to utilize some of what we've discussed here to make the standard metadata view for this initiative, but we want to make sure that the proposal itself is sound before we do too much technical work on the view. Please leave any feedback you have about the core proposal in the forum post.

Also, If you'd like to take a stab at implementing the metadata view based on this, please share your ideas here and we'll be happy to support you! If nobody volunteers to lead this, the Flow team will make some proposals.

Thanks for your support!

[joshuahannan]

I posted a new PR with the license proposal based off Bjarte's that I am looking for feedback on: https://github.com/onflow/flow-nft/pull/173