License parameter compatibility precompile

[Ramarti]

Current status

L1s have economic security, but since we are the IP L1 we should have “legal risk security”.

We are currently checking compatibility only for some terms when doing multiparent derivation.

IP Derivation of well intentioned but mistaken participants might result in increasing number of inconsistencies that could overwhelm Dispute Module, lowering the quality and legitness of the IP Graph. The effects may compound if we introduce custom licensing terms, multi app composability, multi License Term composability…

The costs of resolving disputes and “repairing” a big derivation tree are not well understood in practice yet, and the level of growth we project is ambitious. Say, a term incompatibility conflict is found via successful dispute in level 3 of a 100 level IP tree with multiple parent inheritance and royalties. How do we roll that back? That could happen by honest mistake (imagine Pudgy has only PG derivatives in their license, and a mature themed derivative is minted without anyone noticing for a time, and derivatives of that are created). Malicious license trees that aim to create a “dispute DoS” are a possible attack vector.

On the other hand, Story governance having to evaluate one by one the terms proposed by teams is going to become increasingly complex, with a higher chance of introducing something that disrupts the previos state without a clear way to test.

Proposed Solution

“Rolling back” disputed trees and parameter testing/review are needed anyway but OOO for this issue. We could however introduce standardization measures that will

• Reduce the need for disputes by eliminating at least low hanging fruit conflicts, with room to be more complex later
• Make creating testing processes for licensing compat. more feasible

Flows

Registering LicenseTemplate adds terms to the engine

Completely new template

Registering additional terms to a License Template

This could help supporting PIL “Additional Licensing Parameters”

Verification on IP Derivation

This will revert if would be IP Parents are not compatible.

Instead of checking for compatibility in Solidity like now, the licensing terms are expressed as RPL encoded bytes data, that can be safely parsed in go using existing geth libraries, to iterate over all the parameters more efficiently

Schema:

Since attempts at doind this in Solidity were proven too hard on Dev X, we introduce a precompile that supports user’s ability to register custom licensing terms, in a format that is

• Expressive, like JSON metadata , RPL or similar
  • It should be able to express at minimum PIL terms.
  • It should be flexible and easy enough for apps to create and governance to review.
• Estandarized in a way that supports compatibility across apps
• In a format efficient enough to be
  • Stored in a blockchain DB.
  • Evaluated fast in golang for multiparent derivation.
  • Allow for future more complex oracles to plug in.
• Can be passed as a 1 bytes/string param, instead of one or multiple big structs

Parameter definitions (JSON)
{
   [
	   name: "Parameter XYZ",
	   type: "uint",
	   constraints: "0-1000"
	   available_ops: "gte"
   ],
   [
	   name: "Parameter 234",
	   type: "multiple_choice_string"
	   constraints: ["BLUE", "RED", "YELLOW"]
	   available_ops: "equal"
   ],
}

Parameter definition (RPL)
[
  [
    ["Parameter XYZ"],
    ["uint"],
    ["0-1000"],
    ["gte"]
  ],
  [
    ["Parameter 234"],
    ["multiple_choice_string"],
    ["BLUE", "RED", "YELLOW"],
    ["equal"]
  ]
]
RPL encoded result (to be stored in Geth DB)
something like
f8a2f84cb84a8c506172616d65746572 2058595a84 75696e7486302d31303030 83677465f852b850 8c506172616d6574657220323334 96 6d756c7469706c655f63686f6963655f737472696e67 8d424c55452c5245442c59454c4c4f57 85657175616c

Parameters

After previously analyzing [the PIL terms](https://docs.storyprotocol.xyz/v0.1-beta/docs/universal-medial-license-for-devs-and-creators#parameters-implemented-on-chain) we could generalize compatibility into:

• bool : true or false. For example, derivativesAllowed
• short_text : max 32 bytes, so it fits on 1 storage slot.
• uint256 : unsigned number
• single_choice_<type> : from a set of options (of type bool, short_text, or uint256) , defined by the rule creator as an array, we choose one by providing the index in said set. For example

Parameter:
Name: Reproduction Media
Type: single_choice_short_text
Available options on creation: ["TV", "STREAMING", "CINEMA_THEATHER"]
Input in license value: 1 (Meaning "STREAMING")

• multiple_choice_<type> : from a set of options (of type bool, short_text or uint256), defined by the rule creator as an array, we choose one by providing the index in said set. For example

Parameter:
Name: Merch Types
Type: multiple_choice_short_text
Available options on creation: ["APPAREL", "VIDEOGAME_SKINS", "SHOES", "MUGS"]
Input in license value: [2,3] (meaning Shoes and Mugs)

• single_choice_<type>_ranked : from a set of options (of type bool, short_text or uint256), defined by the rule creator as an array sorted from less restrictive to more restrictive, we choose one by providing the index in said set. The difference with normal single choice is that we can apply operators that will grade “restrictiveness”
  For example:

Parameter:
Name: Age Rating
Type: single_choice_short_text_ranked
Available options on creation: ["All Ages", "Teens", "Adults"]
Input in license value: 1 (meaning Teens). Operators could be <= Teens, so "All Ages" and "Teens"

• long_text_url : URL to long form text parameter

Operators (assuming 2 operands)

• optimistic : operands might be incompatible, but no compatibility verification is done on registration time on chain, only after the fact via disputes. This is the current situation for licensing terms except:

commercialUse
derivativesReciprocal
derivativesAllowed
derivativesApproval
commercializerChecker

• indifferent :
  • This parameter has no effect on compatibility. For example attribution . Parent A may demand attribution, Parent B might not care about it. Remixing is still allowed
• equal :
  • Both operands must be identical to be compatible
  • Applicable to types: all
• some_equal :
  • One or more of the values must match in both operands
  • Applicable to types: multiple_choice
• gt, gte, lt, lte:
  • Arithmetic value (or rank of choice) must be greater than, greater than or equal, lower than, lower than or equal to be compatible
  • Applicable to types: uint256 , single_choice_<type>_ranked
• oracle :
  • an address of the oracle contract that must implement an interface like

interface ICompatibilityOracle {
	function verify(termA, termB) returns (bool);
}

this can be used as source of truth for more complex terms/logic, integrations between projects, IPFi, etc

• Applicable to types: all, (including long_text_url )