Archive for the 'Artificial Intelligence' Category

Canadian Smart Contract Law: Is it broke and do we need to fix it?

.

By Richard Stobbe

The idea of a ‘smart contract’ has been a lot of things: it’s upheld as the next big thing, a beacon of change for society, a nail in the coffin of an inefficient legal services profession, and it’s criticized as a misnomer for ‘dumb code’.  Our review of smart contracts continues with this question:  Are ‘smart contracts’ in need of specific laws and regulations in Canada?

In other words, is ‘smart contract’ law broken and in need of fixing?

(Need a quick primer on smart contracts? Can Smart Contracts Really be Smart?)

For those who may recall, the advent of other technologies has caused similar hand-wringing. For example the courts have, over the years, dealt with contract formation involving the telephone, radio, telex and fax … and email … yes, and the formation of contracts by tapping “I accept” on a screen.

There is a very good argument that the existing electronic transactions laws in Canada adequately cover the most common situations where so-called ‘smart contracts’ would be used in commercial relationships. For example, the Alberta Electronic Transactions Act (a piece of legislation that was introduced almost 20 years ago, when people talked about the “information superhighway”), was intentionally designed to be technology neutral.

The term “electronic signature” is defined in that law as “electronic information that a person creates or adopts in order to sign a record and that is in, attached to or associated with the record”. It’s so broad that the term can arguably apply to any number of possible applications, including situations where someone approves a transactional step within a smart contract work flow. Of course, this still has to be tested in court, where a judge would apply the law in an assessment of the specific facts of a particular dispute.

Does that create uncertainty? Yes, to a degree.

But the risks associated with that approach are preferable to the alternative. The alternative is to go the way of Arkansas, or other jurisdictions who have decided to wade in by prescriptively defining “smart contracts”.   For example, a 2019 law in Arkansas – “An Act Concerning Blockchain Technology” HB 1944 – amends that state’s electronic transactions law by defining “blockchain distributed ledger technology,” “blockchain technology” and “smart contract.”  By imposing specific definitions, these laws may have the unintended effect of excluding certain technologies that should be included, or catching use cases that were not intended to be caught.  This would be the equivalent of trying, in 2001, to define an electronic transaction by looking at  Amazon’s 1-click checkout. Sure, it was innovative at that time, but to peg a legal definition to that technology would have been short-sighted and unnecessarily constraining.

A second problem is a lack of standardization or uniformity in how different jurisdictions are choosing to define these technologies. This creates more uncertainty than a reliance on existing electronic transactions laws.

As blockchain and smart contract technology develops, the rush to have legal definitions cast in stone is premature and unwarranted.

Related Reading:

Blockchain Legislation – Too Soon?

 

Calgary – 07:00 MST

No comments

Smart Contracts (Part 4): Ricardian Contracts and the Internet of Agreements

.

By Richard Stobbe

As we’ve reviewed before, the term “smart contract” is a misnomer. (For background, see Smart Contracts (Part 3): Opportunities & Limits of Smart Contracts.) The so-called smart contract isn’t really a “contract” at all : it’s the portion of the transaction that can be automated and executed through software code. Hence, we prefer the term “programmatically executed transactions” — not as catchy, but maybe more accurate.

The written legal prose, or what we might think of as a ‘traditional contract’, sets out a bunch of contract terms, usually in arcane legalese, that describe certain elements of the relationship. Parts of that ‘traditional contract’ can be automated and delegated to software. However, once concluded, the traditional legal contract usually sits in one silo, and the software code is developed and sits in another silo, completely divorced one from the other.

The evolution of research and software tools has permitted the so-called Ricardian contract to function as a bridge between these silos. Based on the work of Ian Grigg, a Ricardian contract is conceived as a single document that has a number of elements that permit it (1) to function as a “contract” in the way the law would recognize a contract, so the thing has legal integrity, (2) to be readable by humans, in legal prose, (3) to be readable by software, like software reads a database or a input fields, (4) to be signed digitally, and (5) to be integrated with cryptographic identifiers that imbue the transaction process with technical integrity and verifiability. This is where blockchain or distributed ledger technology comes in handy.

The document should be readable by both humans and machines. It integrates the ‘traditional contract’ with the ‘smart contract’, since the elements or parameters that can be automated and implemented by software are read into the code straight from the contract terms.

Can this form the basis for software developers and lawyers to play in the same sandbox?

There are a number of developments in this arena where “legal” and “software” overlap, and Ricardian contracts are merely one iteration of this concept: for more background, Meng Wong’s presentation on Computable Contracts is a must-see.  His Legalese contracts are intended to allow legal terms and conditions to be represented in machine-understandable way, with or without a blockchain deployment. OpenLaw is another version of this approach : blockchain-enabled contracts that delegate certain functions to software. There are a whole range of options and variations of this.

In theory, this sets up an “Internet of Agreements” system that is designed to execute deals and transactions automatically with distributed ledger ecommerce technology through interwoven contracts and software across disparate platforms.

How far away is this legal-techno-dream?

For some applications, particularly in financial services, it’s much closer. Versions of these technologies are being beta-tested and implemented by global banks.  Since many of these implementations will be between entities in back rooms of the financial services industry, they will be invisible to the average consumer.  For many sectors – let’s say for example, the development of a full-stack land transfer technology – where smart contracts have to interface with existing immovable legal or institutional structures, this is a long way off.

 

Calgary – 07:00

 

No comments

Smart Contracts (Part 3): Opportunities & Limits of Smart Contracts

.

By Richard Stobbe

In Part 1 (Can Smart Contracts Really be Smart?), we looked at “smart contracts”, what might be called “programmatically executed transactions” or PETs. This concept refers to computers programmed to automatically executes certain transaction steps, provided certain conditions are met, illustrated by the vending machine analogy.

In Part 2 (Smart Contracts (Part 2): Intermediaries? We Don’t Need No Stinkin’ Intermediaries!), we pointed out that users of private shared (DLT) ledger systems must be aware of the attendant costs of switching to new intermediaries, and the legacy costs of continued dependence on old intermediaries.  To borrow a phrase from The Who, “Meet the new boss… same as the old boss.”  In other words, don’t be fooled into thinking that intermediaries will disappear; they merely change. Managing the intermediaries remains a challenge.

In this final instalment of our series, we look at the opportunities and limits of smart contracts. I want to emphasize a few points:

  1. Placing Smart Contracts in Context: First, it’s worth emphasizing that smart contracts or PETs are merely one element of the whole DLT permissioned ledger ecosystem. The smart contract enables and implements certain important transactional steps, but those steps fit within the broader context of a matrix of contractual relations between the participants. Many of those relationships will be governed by “traditional” contracts. This traditional contract architecture enables the smart contract workflow.  The take-home point here is that traditional contracts will remain a part of these business relationships, just as intermediaries will remain part of business relations. Let me provide an example: the Apple iTunes ecosystem contains a number of programmatically executed transactions. When a consumer chooses a movie rental, a song download or a music subscription, the order fulfilment and payment processing is entirely automated by software. However, users cannot participate in that ecosystem, nor can Apple obtain content from content producers, without an overarching set of traditional contracts: end user license agreements, royalty agreements, content licenses, agreements with payment providers. Those traditional contracts enable the PET, just as the PET enables the final transaction fulfillment.
  2. Changing Smart Contracts:  Once a PET is set loose, we think of it as a self-actuating contract: it cannot be changed or altered or stopped by humans.  The inability of humans to intervene is seen as a positive attribute – it removes the capriciousness of individuals and guarantees a specific pre-determined machine-driven outcome. But what if the parties decide (humans being humans) that they want the contract to be suspended or altered? Where humans control the progression of steps, they can decide to change, stop or reverse at any point in the workflow. Of course we’re assuming that this is a change or reversal to which both parties agree. But what is the mechanism to hit “pause”, or change a smart contract once it’s in midflight?  That remains a challenge of smart contracts, particularly as PET workflows gain complexity using blockchain-based technologies.
    • One solution may be found within those traditional contracts, which can be drafted in such a way that they allow for a remedy in the event of a change in circumstances to which both sides agree, even after the PET has started executing the steps it was told to execute. In other words, the machine may complete the tasks it was told to do, but the humans may decide (contractually) to control the ultimate outcome, based on a consensus mechanism that can override the machine after the fact.  This does have risks – it injects uncertainty into the final outcome. It also carries benefits – it adds flexibility to the process.
    • Another solution may be found in the notion of “hybrid contracts” which are composed in both machine-readable form (code) and human-readable form (legal prose).  This allows the parties to implement the consensus using a smart contract mechanism, and at the same time allows the parties to open up and change the contract terms using more traditional contract methods.
  3. Terminating Smart Contracts:  Finally, consider how one party might terminate the smart contract relationship. If the process is delegated to self-executing blockchain code, how can the relationship be terminated?  Again, where one party retains the ability to unilaterally terminate a PET, the final outcome is uncertain, and one of the chief benefits of smart contracts is lost. Too much flexibility will undermine the integrity of the process.  On the other hand, too much rigidity might slow adoption of certain smart-contract workflows, especially as transaction value increases. A multilateral permissioned mechanism to terminate the smart contract must be considered within the system. Participants in a smart contract permissioned ledger will also have to consider what happens with the data that sits on the (permanent, immutable) ledger after termination. When building the contract matrix, consider what is “ledgerized”, what remains in non-ledgerized participant databases, and what happens to the ledgerized data after contract termination.

 

If you need advice in this area, please get in touch with our Emerging Technology Group.

 

Calgary – 07:00 MST

1 comment

AI and Copyright and Art

.

By Richard Stobbe

At the intersection of this Venn diagram  [ Artificial Intelligence + Copyright + Art ] lies the work of a Paris-based collective.

Obvious

By means of an AI algorithm, these artists have generated a series of portraits that have caught the attention of the art world, mainly because Christie’s, the auction house,  has agreed to place these works of art on the auction block. Christie’s markets themselves as “the first auction house to offer a work of art created by an algorithm”.  The series of portraits is notionally “signed” (𝒎𝒊𝒏 𝑮 𝒎𝒂𝒙 𝑫 𝔼𝒙 [𝒍𝒐𝒈 𝑫 (𝒙))] + 𝔼𝒛 [𝒍𝒐𝒈(𝟏 − 𝑫(𝑮(𝒛)))]), denoting the algorithm as the author.

We have an AI engine that was programmed to analyze a range of prior works of art and create a new work of art. So where does this leave copyright? Clearly, the computer software that generated the artwork was authored by a human; whereas the final portrait (if it can be called that) was generated by the software.  Can a work created by software enjoy copyright protection?

While Canadian courts have not yet tackled this question, the US Copyright Office in its Compendium of US Copyright Office Practices has made it clear that copyright requires human authorship: “…when a work is created with a computer program, any elements of the work that are generated solely by the program are not registerable…”

This is reminiscent of the famous “Monkey Selfie” case that made headlines a few years ago, where the Copyright Office came to the same conclusion: without a human author, there’s no copyright.

Calgary – 0:700 MST

Photo Credit: Obvious Art

 

 

No comments