Status: Draft
This document specifies data-structures, data-streams, and transaction-models that are used to publish and verify machine readable licenses and contracting rules on the Content Blockchain.
Allow people and machines to find license information and easily purchase, own and prove ownership of content licenses. Allow content owners, resellers and distributors to offer, monetize and verify content licenses.
A Smart License is a JSON data structure that holds information about licensing conditions by a given publisher and for a given content. Applications can construct a human readable textual license contract based on Smart License data. A Smart Licence may constitute a public license offering when published to the Content Blockchain. It may also constitute a targeted license offering if it is published as a Confidential Smart License.
A Transaction Model describes a series of verifiable on-chain events that trigger the formation of a Smart License Contract between licensor(s) and licensee(s). They also describe the procedures to find, display and verify such contracts based on data available on the blockchain. We propose three basic Transaction Models with different strength and weaknesses:
The current idea is to allow multiple Transaction Models per Smart License. We should consider to only allow to set one Transaction Model per Smart License, because it might turn out to be tricky to verify contract formation/triggers with an overly flexible model.
Dictates that a license contract becomes effective between Licensor and Licensee when an on-chain attestation originating from the Walled-ID of the licensor has been confirmed on the blockchain. An on-chain attestation has to include references to a Smart License and the Wallet-ID of the licensee.
A Smart License that specifies CHAIN_ATTESTATION as one of its allowable Transaction Models can be triggered by the publisher of the Smart License independent of a price or payment method. The Licensor does this by attesting to the license grant with an on-chain entry to the data-stream smart-license-attestations that references the Licensee by Wallet-ID and the Smart License itself by UUID4.
Dictates that a license contract becomes effective between Licensor and Licensee when an on-chain payment of amount price X from the licensees Wallet-ID to payment_address Y has been confirmed on the blockchain.
A Smart License that specifies CHAIN_PAYMENT as one of its allowable Transaction Models must also specify a price in one or multiple on-chain currencies (native or token) that are accepted as a payment that triggers the verifiable formation of a Smart License Contract.
A Smart License that specifies CHAIN_TOKENIZATION as one of its allowable Transaction Models must reference a specific token that securitizes the formation of a contract between the licensor and the token holder. This effectively means whoever holds such token is automatically a licensee of the Smart License that is bound to the token.
A Smart License is published as a JSON object to the smart-license stream on the Content Blockchain. The primary key for the stream-item is a self generated UUID4.
The ISCC codes of the licensed materials should be used as secondary keys of the stream-item.
By default the Wallet-ID of the transaction that publishes the stream-item (the stream-item publisher) is assumed to be the Licensor of the referenced content and also the recipient (payment address) of any on-chain payments that the Smart License defines as acceptable. Both assumptions may be overridden by the contents of the Smart License json object. Future Smart License versions might allow for multisig stream-items. Until then multisig-stream items are to be treated as invalid by applications.
Alternatively a Smart License may be published to privately controlled streams that are Smart License compatible. A list of Smart License compatible streams will be published and maintained by a community of elected users with write permissions to the closed smart-license-streams stream.
A Smart License supports the following json object fields:
Version number of Smart License specification. Assumed to be 1 if the field is empty or omitted.
SHA256 of the Template data that must be used to render the textual version of the Smart License. The default template engine is Jinja2 v. 2.10.
Extensibility: applications must check for the optional field template_engine to make sure that they use the appropriate template engine. Templates may be published to the smart-license-templates stream with the SHA256 hash as key and the value being a json object with the fields: name, description, template_data, default_rights_modules.
The template engine used to render the human readable contract. If empty or omitted it is assumed to be Jinja2 v. 2.10.
The licensed material(s) referenced by a list of one or multiple identifiers.
If this field is empty or omitted the licensed material(s) are assumed to be referenced by the secondary keys of the Smart License stream-item. By default and for reasons of discoverability (stream indexing) and storage space efficiency the licensed materials should only be referenced by secondary keys of the stream-item. The default identifier type is an ISCC.
This field allows the Smart License data model to work as a message outside of the context of a Content Blockchain stream-item. If this field is used, the secondary stream-item keys must either be non-existent or an exact match of those secondary keys. Any other combination must be treated as invalid.
The type of identifier used to reference the licensed material. Assumed to be an ISCC if this field is empty or omitted.
If this field is empty or omitted the Wallet-ID of the stream-item publisher is assumed to identify the Licensor. Else only this list of one or multiple Wallet-IDs are assumed to identify the Licensors of the referenced materials.
If this field is empty or omitted an application must assume that the licensor is identified by a Content Blockchain Wallet-ID.
List of Rights Modules (contract clauses) to be effective for and included in this Smart License. If no Rights Modules are provided the referenced template will decide about the the modules to be included by default.
Where do we specify validation logic and/or extended data that might be needed to assemble meaningful combinations of Rights Modules?
The Transaction Models supported and accepted by this Smart License.
A set of one or more of the constants: CHAIN_ATTESTATION, CHAIN_PAYMENT, CHAIN_TOKENIZATION. If this field is empty or omitted the Smart License is purely informational and there is no defined way to close a license contract on-chain.
A list of prices (amount, currency) per license to be acquired in different currencies or cryptocurrencies. At least one price in an accepted on-chain currency/token must be given if the transaction_models field contains the CHAIN_PAYMENT constant. In this case an on-chain payment to the payment_address that includes a reference to this Smart License (UUID4) and matches the specified price is to be interpreted as a verifiable formation of contract between the payee and the licensor.
The Content Blockchain Wallet-ID to which the payment must be sent to acquire a license. If this field is empty or omitted the stream-item publishers Wallet-ID is assumed to be the payment_address. Only relevant with CHAIN_PAYMENT activated.
Duration of license effectiveness in seconds. If this field is empty, omitted or 0 the duration of the license is assumed to be unrestricted.
Start time of license effectiveness in seconds of UTC time since Unix epoch (1970-01-01T00:00:00Z). If this field is empty, omitted or 0 the start time of license is assumed to be the time of activation. Time of activation means transaction block time of a contract triggering chain payment, attestation or token transfer.
A list of one or more ISO 3166-1 alpha-2 country codes where the licensed material can be used. If this field is empty or omitted it is assumed that no territorial restrictions apply.
An url that can be used by the to retrieve the licensed material.
The access_url is expected to deliver a WebPage or Api service that is
able support features like:
Ultimately the content delivery system behind the access url is
application specific. In the future we might define a standard protocol
for a content delivery system.
The online Rubik’s Cube solver helps you to find the solution for your unsolved puzzle.
The act of publishing a Smart License is implicitly also an unverified claim of ownership or re-licensing rights by the publishing entity for the respective content. The publishing entity can present cryptographic proof of being the source of a given Smart License on the blockchain and can also create a cryptographic Proof of Data Possession of the claimed content at the time of blockchain registration. It is important not to confuse this with a proof of authorship or intellectual property ownership of the referenced content (yes even blockchains can´t do that). This becomes less relevant In light of the fact, that the content itself is not stored on the blockchain and content access authorization is managed by blockchain-external applications that can define their own trust-rules.
To further protect intellectual property rights and prevent abuse the Content Blockchain offers various features: