Link Search Menu Expand Document
Cybersecurity Research
  1. 8 Methods
    1. 8.1 Practical Tokenized Drafting (PTD)
      1. 8.1.1 Core Principles
      2. 8.1.2 Core Design Practices
        1. Minimum Technical Requirements
        2. Drafting Legal Prose
        3. Minimum Automation Requirements
        4. Programming Software Components
        5. Prose & Software
        6. Draft Commentary
        7. Test Template
        8. Audit Template
    2. 8.2 Automating Legal Prose
    3. 8.3 Automated Music License Methods

8 Methods

8.1 Practical Tokenized Drafting (PTD)

In developing our automated music license, we developed the Practical Tokenized Drafting (PTD) method, a set of core principles and design practices for drafting RCs that interact with Web3 technologies (with an emphasis on blockchain and smart contracts) (hereafter “RC-Web3 Templates”). Our PTD method is an outgrowth of legal engineering and automated transactions. PTD is an outgrowth of legal engineering because we are tokenizing a simple system, here being the copyright in musical works, with the aid of RCs and Web3 technologies.968 PTD is an outgrowth of automated transactions because the method explicitly describes practices for utilizing machines to execute and store some dimension of an exchange of value, and this is actualized through the Tokenized Music License (TML).969 Our PTD method was derived from Veri Media’s Minimum Viable Data (MVD) standard, our Literature Review, and our interviews with a music composer and Coopérative Kleros.

In PTD, we approach drafting with three (3) core principles and ten (10) core design practices in mind from creation to testing to finally release, from the viewpoint of a legal practitioner (used synonymously with drafter) working individually or in partnership with a software engineer(s) (i.e., a programmer).

The three core principles of PTD are:

  1. Stay On-chain970;

  2. Seek Minimalism; and

  3. Jurisdiction Agnostic.

The ten core design practices of PTD are:

  1. Minimum Legal Requirements;

  2. Minimum Technical Requirements;

  3. Drafting Legal Prose;

  4. Minimum Automation Requirements;

  5. Programming Software Components;

  6. Prose & Software;

  7. Draft Commentary;

  8. Test Template;

  9. Audit Template; and

  10. Release Template.

8.1.1 Core Principles

Stay On-chain The first principle, Stay On-chain, is to guide the legal practitioner to always approach PTD with an on-chain rst mindset. In other words, the legal practitioner should always be looking for ways to keep the interactions between the parties, and the execution and enforcement of the RC-Web3 Template, on the blockchain, online, or handled by another Web3 technology. By keeping matters on-chain, the legal practitioner can reduce the variability that may arise because of different types of users, territories, and legal systems.

968Supra Section 1.7.6.

969Supra Section 1.7.1.

970On-chain is a term often used to signify that something is stored and created on, or interacted with, wholly or partially on a blockchain.

Seek Minimalism The second principle, Seek Minimalism, is directly inspired by Verifi Media’s MVD standard. As applied to PTD, the legal practitioner should try to simplify the agreement (i.e., reduce complexity) to its most essential parts (this will also help in figuring out the MAR practice) that can be specifically handled reasonably well with Web3 technology by a RC-Web3 Template.

Jurisdiction Agnostic The third principle, Jurisdiction Agnostic, is to guide the legal practitioner to avoid using multiple jurisdictions or try to find a common ground on jurisdiction between the parties because the parties in a RC-Web3 Template context are likely to span multiple jurisdictions. By keeping the jurisdiction limited to one or few, it will be easier for the parties to know what to expect when utilizing a RC-Web3 Template and reduce the chances of unexpected legal occurrences arising from the different legal frameworks of jurisdictions. A good way to apply this principle is to look for jurisdictions that have adopted international treaties and agreements applicable to the subject matter of the agreement.

8.1.2 Core Design Practices

Minimum Legal Requirements The Minimum Legal Requirements (MLR) practice requires the drafter to consider the legal frameworks that prescribe the boundaries and minimum requirements of the legal subject matter of the agreement. For any RCWeb3 Templates, the drafter will need to evaluate the following laws, rules and regulations applicable in their jurisdiction(s):

  • Electronic Signatures;

  • Electronic Transactions;

  • Contracts971;

  • Evidence;

  • Alternative Dispute Resolution;

  • International Treaties;

  • Tax Liability;

  • Conflict of Laws;

  • Data Privacy; and

  • Web3-specific laws and regulations.972

Minimum Technical Requirements

The Minimum Technical Requirements (MTR) practice requires the drafter to consider the technical frameworks for the desired Web3 infrastructure and best practices for developing Web3-interactive programmable software components. For example, since the OpenLaw platform is on Ethereum, the drafter will need to consider the following:

971Especially contractual remedies.

972Additionally, a drafter may need to consider securities laws and trade laws.

  • programming frameworks and best practices for deploying a smart contract on the Ethereum blockchain973; and

  • how transactions on OpenLaw are conducted and stored on the Ethereum blockchain.

For an additional example, if the drafter wants to deploy an ERC-20 token to the Ethereum blockchain, the drafter should examine the ERC-20 token standard and good practices associated with ERC-20 tokens.

The Drafting Legal Prose (DLP) practice requires the drafter to draft the legal prose of the RC-Web3 Template in accordance with the MLR practice and the purpose of the legal document.

Minimum Automation Requirements

The Minimum Automation Requirements (MAR) practice requires the drafter to consider which parts of the legal prose are ripe for automation. Generally, the objective and computable provisions can be automated (e.g., payments, dates and times), while the subjective or di cult to compute provisions should be left as legal prose. Additionally, any existing assets or rights are generally tokenizable.

Programming Software Components

The Programming Software Components (PSC) practice requires the drafter to program or cause to program, if not already programmed, the software components of the RC-Web3 Template (generally in accordance with the MTR practice). Additionally, the drafter needs to consider if they can directly embed the legal prose into the metadata of any le containing a digital representation of the agreement’s subject matter.

Prose & Software

The Prose and Software (P&S) practice requires the drafter to combine the legal prose, considerations for automation, and software components to produce one complete draft of the RC-We3 Template.

Draft Commentary

The Draft Commentary (DC) practice requires the drafter to draft commentary explaining to the relevant parties (licensor, licensee, drafters, etc.) the provisions of the RC-Web3 Template, the legal and technical contours of the RC-Web3 Template, and any disclaimers and licenses. Generally, this practice is akin to a cover letter explaining the agreement to a client.

Test Template

The Test Template (TT) practice requires the drafter to test the RC-Web3 Template on the Web3 infrastructure. For example, if the RC-Web3 Template is developed on the OpenLaw platform on the Ethereum blockchain, the drafter should execute the RC-Web3 Template on one of the Ethereum blockchain test networks, such as the Rinkeby network, or on a private Ethereum network.

Audit Template

The Audit Template (AT) practice requires the drafter to have a third-party audit (public or private) of the RC-Web3 Template’s software components for security and optimization purposes.

973However, if the drafter is working with a software engineer well versed in Web3, then these considerations can be left with the software engineer

Release Template The Release Template (RT) practice requires the drafter to release the RC-Web3 Template to the parties involved, or make available to the public, in an easily accessible and editable manner, such as a template on the OpenLaw platform. Additionally, if the RC-Web3 Template is made available to the public, the drafter should also include any copyright distribution licenses associated with the template, any preferred audiences, and the commentary for the RC-Web3 Template.

Automating legal prose raises serious issues concerning how to translate subjective terms in a legal document into objective programmable software.974 An additional concern is also implied covenants in contracts, which are included even if the parties did not consider them. This is often the case for a duty of good faith and fair dealing.975 Generally, terms that are easily computable (i.e., quantitative or tending to be quantitative) are the easiest to translate into programmable software (the programmable software we are most concerned with are smart contracts and we shall refer to smart contracts for the rest of this section), while terms that are subjective, indeterminable at the time of contracting, or ambiguous, are the hardest to translate into a smart contract.976 Our perception of the di culty of translating legal prose, speci cally provisions in a copyright license, into smart contracts is described in the table below.

974Giancaspro, “Is a ‘smart contract’ really a smart idea? Insights from a legal perspective”.

975Ibid.

976Giancaspro, “Is a ‘smart contract’ really a smart idea? Insights from a legal perspective”.

Provision
Difficulty
Reasoning
Royalties
Easy to Medium

Royalties are generally quantitative in nature, and can be easily computed from the outset, including payment splits.

Recurring payments can be done as well.

Accounting
Easy to medium

The bulk of the accounting can be handled by the blockchain itself

Party Information
Easy to Medium

Party information is generally ascertainable, each of the parties has a unique public address on the blockchain, and parties can verify personal information on the blockchain

Notices
Easy to Medium

Notices can easily be sent via a transaction between the parties, such as signing a message and giving the hash to the counterparty

Reporting
Easy to Medium

Reporting can be handled on-chain by utilizing a block explorer to track the number of uses by a public address

Grant
Medium to Hard

Grant conversion can be handled by tokenizing copyright and licenses. However, difficulty may arise if the grant language contains subjective (or requiring o -chain interaction) terms.

Dispute Resolution
Medium to Hard

Dispute resolution may occur online or  offline. If offline, then it becomes harder to resolve because the parties may not know each other and if a dispute gets sent to a court of competent jurisdiction.

Remedies
Medium to Hard

Equitable remedies will be hard to enforce unless the dispute can be resolved on-chain. Certain remedies may also be unavailable depending on the jurisdictions of the parties. Liquidated Damages, Penalties, and other Fines are easier to implement because they are computed at the time of contracting.

Choice of Law
Easy to Medium

Choice of Law can be explicitly stated in the Ricardian contract.

Representations, Warranties & Indemnification

Medium to Hard

RWI is hard to enforce because of the pseudonymity of the parties, and the potentially large cost of conducting a background check on the parties.

Termination
Easy to Medium

Termination can be handled on-chain by codifying the termination events into the smart contract. By doing so, the smart contract will not be removed from the blockchain, but it will for all intents and purposes become inactive. Additionally, the cause for termination may be disputed through on-chain or online dispute resolution.

Signatures
Medium to Hard

Signatures can easily be handled with cryptographic signatures and public key infrastructure. However, the signature may not be valid under a jurisdiction’s electronic signature laws and issues arise concerning the identity of the signatories.

Identity
Medium to Hard

The identity of the parties will be di cult to ascertain because blockchain public addresses are pseudonymous, unless the parties have made their identities known to each other. We expect the licensor (musician, rights holder, etc.) to make their identity public, while not requiring the counterparty to make their identity public because of the cost of KYC procedures.

Additional Agreements
Medium to Hard

Having the parties enter into additional agreements can be codified in the smart contract but faces follow-on intent complications as described by Giancaspro.977

Given some of the headaches of translating prose to software, we believe a middle ground approach such as a contract management platform that offers functionality with blockchain and other Web3 technologies (e.g., OpenLaw) would be the one of the best approaches for increasing adoption of Web3 technologies among legal professionals and music industry stakeholders.978 Additionally, if the contract management platform allows the contracts made on the platform to integrate with DApps (built with smart contracts), then it becomes easier for musicians, other music industry stakeholders, and smart contract developers to build DApps using contracts that are legally-compliant while achieving transaction cost savings979

8.3 Automated Music License Methods

The OpenLaw platform, as discussed in Part I, is a Ricardian Contract (RC) development and hosting platform that interacts with the Ethereum blockchain and associated ecosystem.980 OpenLaw provides a public repository for storing and extending RC-Web3 Templates, and has its own markup language for writing RC-Web3 Templates.981 On OpenLaw, a record of all signed and executed RC-Web3 Templates is stored on the Ethereum blockchain, excluding the rich text (the legal prose, user-de ned variables and options, and party identification other than Ethereum public addresses drafted in the markup language) of the RC-Web3 Template.982 This record includes all the required information for a transaction stored on the Ethereum blockchain, including the:

  • public addresses (i.e., the proof that the parties exchanged cryptographic signatures) of the parties,

  • timestamp of the transaction,

  • Gas fees and Gas limit, and

  • creation, interaction and/or execution of any smart contract functions (e.g., creating tokens, transferring tokens)983

We utilized OpenLaw to develop our automated music license standard form, aptly named the Tokenized Music License984, an RC-Web3 Template standard form for music licensing in a Web3 technologies context. Additionally, we created a form and ow for the TML to guide users of the TML through the contracting process. The TML form and ow is designed to guide users through the contracting process by first providing contact information, then filling out the particulars of the TML, and finally ending with signatures.

Before using the OpenLaw platform, we read through the OpenLaw Docs to understand how:

  • to design a template,

  • to design a form and low, and

  • OpenLaw RCs can interact with the Ethereum blockchain (e.g., cryptographically signing transactions and recording transactions on the blockchain) and associated ecosystem (e.g., DApps and data oracles)985

We heavily referenced the First Draft, Sign & Store, Forms & Flows, and Token Forge pages.986 From the PTD method, we relied on the MLR, MTR, MAR, DLP and P&S core design practices. We determined our MLR,

978Finck and Moscon, Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0.

979Finck and Moscon, Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0; Bodó, Gervais, and Quintais, Blockchain and smart contracts.

980Overview | OpenLaw Docs; Finck and Moscon, Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0.

981Overview | OpenLaw Docs.

982Ibid.

983Ibid.

984The Tokenized Music License discussed in this report is Version 0.5 (V0.5), and a draft of V0.5 is included as an appendix to this report

985Overview | OpenLaw Docs.

986Ibid.

MTR, MAR from the Literature Review in Part 1.987For P&S considerations, we referred to COALA-IP’s Licensing Protocol documentation and OpenLaw’s documentation.988 For DLP, we relied on our previous knowledge of intellectual property licensing and referred to two licenses:

  1. ASCAP’s Music-in-business Blanket License; and

  2. Kadion Henry’s Music License Agreement from Docracy.

989 Lastly, we relied on two interviews, one with a music composer and the other with the Kleros team, to aid in tailoring our TML for our intended circumstances.

987Supra Section 1.

988Supra Section 1.

989Kadion Henry. Music License Agreement. url: https : / / www . docracy . com / 6931 / music - license - agreement (visited on 12/10/2019); ASCAP Music License Agreements and Reporting Forms. en. url: http://www.ascap.com/music-users/licensefinder (visited on 12/10/2019).

Table of Contents