Licensing (Module)

Architecture and Concepts

Picture Story Protocol as a global IP Graph, with each node being an IP Asset. Then, we can define licensing as the processes and conditions that determine how derivative IPs get connected into the graph.

Each original IP Asset owns intellectual property rights, such as creating derivatives, being commercially exploited, and being reproduced in different platforms, for its associated IP (represented as an NFT). Furthermore, original IP Assets can programmatically grant permissions for any users to exercise those rights with some autonomy.

Within Story Protocol, such permissions for IP rights are expressed via License NFTs, which point to a particular set of conditions, known as a Policy.

The diagram above displays the general architecture of the Licensing system in Story Protocol.

Licenses

Licenses of IP Assets

The owner address of an IP Asset is entitled to all legal rights of that IP Asset. To transfer (or sell) the full rights, the owner must transfer the IP Asset itself. In other words, transferring an IP Asset means losing rights over the IP associated with the IP Asset.

IPAccounts can also create licenses to give other parties permission to use the IPAccount, where "use" means reproducing IPAccounts, creating derivatives, and commercializing them. This empowers IPs and IPAccounts to be programmable and retain intrinsic value with varying degrees of control.

License Registry

A License in Story Protocol is represented as an ERC-1155 NFT in the License Registry. Thus, all interactions with License NFTs are made on the License Registry.

The core smart contracts of Story Protocol enforce the minting and burning of License NFTs in the License Registry to be only callable by the Licensing Module. Hence, mintLicense in the Licensing Module mints License NFTs via the registry, while linkIpToParents burns License NFTs via the registry.

The License Registry stores these states:

  • Licensor IP ID: a globally unique identifier (address) of an IP Asset that holds the rights of an IP.
  • Policy ID: a globally unique identifier (uint256) for the permissions each license grants. Read more about Policy.
  • License ID: a globally unique identifier (uint256) of a License NFT. They are unique per combination of licensor IP ID and policy ID; they are fungible, just like ERC-1155, so there can exist many units of licenses per one license ID.
  • Licensee: the owner (address) of the rights granted by a License NFT. Tracked by if an owner's balance for a particular License ID is > 0; the balance will decrease when linking a derivative IPA to a parent (burns License NFT).

Example

  • Alice, the owner of IP Asset A, mints 1000 License NFTs to remix according to Policy #4. (Let's imagine Policy #4 is free minting, non-commercial, derivatives allowed).
    • The resulting non-commercial License NFT has ID #1 and a supply of 1000.
  • IP Asset A wants commercial derivatives as well, so Alice creates 50 License NFTs using Policy #5. (Let's imagine Policy #5 defines derivatives allowed, commercial use allowed setting 10% revenue share)
    • The resulting commercial License NFT has ID #2 (same licensor, different policy) and a supply of 50.

It's up to the licensor (Alice, in the case above) to create strategies regarding the supply of each license ID and to set the commercial conditions, other license terms, and upfront minting cost (only if commercial).

Transferability of the License

Licenses might be transferrable or not, depending on the values of the policy terms they point to.

Non-transferable licenses can only be transferred out of the licensor's address. Once the licensor (person who minted the licenses) transfers a License NFT to a licensee, then that license will be locked in the licensee's address.

Licensing Module

The Licensing Module holds the logic and states necessary to maintain a legally coherent IP Graph. In particular, the module stores all licensing configurations, which represent different variations of license terms, such as the terms of Programmable IP License (PIL), in the form of Policy (structs) generated by Policy Framework.

Policy Framework

Let's first discuss the concept of Policy Framework.

A policy framework is a programmable framework that defines various licensing terms, such as "is commercial use allowed," and possible values/options for those terms. In the same example, "is commercial use allowed" might have true/false (bool) as a possible value. These terms and values differ per policy framework.

Using a DeFi analogy,

  1. The Licensing Module is the Uniswap V3 Factory.
  2. Policy Framework is each Uniswap V3 Pool.
  3. One Policy is a particular liquidity position in a pool (policy framework).

Policy frameworks are responsible for:

  • Providing a link to the actual, off-chain, legal contract template, with all the parameters, their possible values, and the correspondent legalese, in licenseTextUrl.
    • For a licensing framework to be compatible with Story Protocol, the legal text must be clear and parametrized, with each licensing parameter establishing the possible outcomes of each value.
    • The parameter values in each policy drive the legal text for each license agreement.
  • Defining a struct with the particular definitions of the parameters in accordance, which must be encoded into the policy struct (described below).
  • Providing registration methods for the framework policies, and getters.
  • Verifying that both the minter and the address linking a derivative are allowed by the policy parameters to perform those actions.
    • These conditions could be enforced by the policy framework itself or through hooks. They can range from limitations on the derivative creations, token-gating LNFT holders, creative control from licensors, KYC, etc. It's up to the implementation of each policy framework.
  • Verifying that the policies are compatible if a derivative has or will have multiple parents

πŸ“˜

Programmable IP License Framework

To learn about the first implementation of a Policy Framework, read this page.

Policy

A policy is a particular combination of values for the licensing terms defined in a policy framework. Indeed, there can and will exist multiple policies (variations) for each policy framework. You can imagine that a policy framework generates many policy variations.

In other words, custom conditions and permissions of policies are defined by their policy frameworks.

Internal Representation of Policy

Story Protocol currently has a few mandatory, protocol-wide terms for all policies registered on the protocol. Outside those terms, a policy can have any terms and values according to its policy framework. Since the Licensing Module is designed with extensibility in mind, the terms and values from policy frameworks are encoded as bytes in a policy.

Below is the Policy struct used on Story Protocol (description afterwards):

/// @notice A particular configuration (flavor) of a Policy Framework, setting values for the licensing
/// terms (parameters) of the framework.
/// @param isLicenseTransferable Whether or not the license is transferable
/// @param policyFramework address of the IPolicyFrameworkManager this policy is based on
/// @param frameworkData Data to be used by the policy framework to verify minting and linking
/// @param royaltyPolicy address of the royalty policy to be used by the policy framework, if any
/// @param royaltyData Data to be used by the royalty policy (for example, encoding of the royalty percentage)
/// @param mintingFee Fee to be paid when minting a license
/// @param mintingFeeToken Token to be used to pay the minting fee
struct Policy {
    bool isLicenseTransferable;
    address policyFramework;
    bytes frameworkData;
    address royaltyPolicy;
    bytes royaltyData;
    uint256 mintingFee;
    address mintingFeeToken;
}

Protocol-wide Policy terms:

  • isLicenseTransferable: the transferability of licenses minted from this policy.
  • mintingFee: cost of upfront fee to be paid when minting a license from this policy.
  • mintingFeeToken: ERC-20 token to be paid when minting a license from this policy.
  • royaltyPolicy: a custom Royalty Policy to be employed by this policy when interacting with the Royalty Module, which manages the flow of royalty capital according to the commercial terms of a policy.
  • royaltyData: encoded data to be passed into royaltyPolicy.

πŸ“˜

Royalty Module

The Royalty Module is closely integrated with the Licensing Module to enforce economic terms.

Learn more

Guarantees for Policy

Once registered, a policy is immutable β€” it can't be tampered with or altered, even by the policy framework that generated it. All policy states are maintained in the Licensing Module.

Additionally, policies are unique with a global numeric ID, which makes them reusable. For example, a particular set of term values of the PIL Framework, such as non-commercial usage + derivatives allowed + free minting, defines a unique policy with a global ID.

Note: a policy of non-commercial usage + derivatives allowed + free minting in PIL Framework is also known as the Social Remixing policy.

Policy attached to IP Asset

One can attach a policy to IP Asset to either allow for permissionless licensing or link to one or more parent IP Assets (becoming a child). Each IP Asset can have two sets of policies attached:

  1. Non-Inherited Policies: set by the IP Asset owner to signal to other users that they can mint License NFTs of this policy to create a derivative of this IP Asset.
  2. Inherited Policies: set during the process of IP derivation (remixing). These policies are set by burning one or more License NFTs when calling linkIpToParents. Having inherited policies indicates:
    1. If an IP Asset has inherited policies, it's considered a derivative IP Asset.
    2. If an IP Asset has inherited policies, the owner of an IP Asset cannot set new policies.
      (This is a restriction in Beta!)

πŸ“˜

Derivation loop

To learn more about Story Protocol loop to create derivative IPAs (remixing), go to this page.