The Meaning of Blockchains and the GDPR

The Three Waves of Open (Source, Transacting, Data)

Open Source – GNU – Copy-left

In the mid 1980s, a computer scientist at MIT became frustrated, outraged at his inability to make needed modifications to software code that ran on machines at MIT.  The code came from vendors, often the vendors of the machines, and it was locked down – a big blob – “object code.”  Requests to fix problems were often ignored, as were requests for new features.  The team that could make those changes was small, remote and subordinate to the overall objectives of the vendor.

Richard Stallman took umbrage and searched for a solution.  He created the “free” software movement, the “copy-left” license and a great deal of GNU software to begin an incremental revolution.  His objective was both massive and modest.  Massive in that he sought a complete transformation in how software was made and distributed.  Modest in that he eliminated himself as a bottleneck – anyone could carry the project forward.

The key to this was a legal idea, what came to be known as “copy-left.” Instead of the author renouncing their copyright claims – the authors asserted copyright, allowed unlimited use, except that anyone who published improvements or derivations was also required to add them to the stone soup.  This prevented “embrace and extend” strategies that could re-privatize open software by racing ahead and capturing a customer base for a derivation that would eclipse the open one.

Note that in the case of software, “source” was an established idea; the innovation was in the “open” part, the copy-left license.

In the early 1990s, a student in Finland created the base for Linux, which extended the GNU ecosystem, and accelerated the revolution.  Like all revolutions, this one did not follow a path that could be predicted at the beginning. It meandered, but as it did, it drew in very powerful interests.  Open source became the way for a group of actors, even “selfish” ones in the economic sense, to counter a threat of monopoly.  Open source became a kind of hands-on, market-based anti-monopoly mechanism.  It also drew in many of the best coders because it helped their career paths – they could do their work and develop their careers independent of a vendor/employer.  This was important for academics, and then for nearly everyone with ambitions and ideas.  GNU continues, and the revolution has reached into the web, AI, mobile phones – nearly all corners of software.  (This wonderful talk by Eben Moglen from late 2018 takes the story deeper and wider.)

It is important to notice that the forms of licensing that prevailed included versions that were less strict, less comprehensive and “greedy” (in the regex sense) than the original GNU copy-left.  A sweet-spot turned out to be a somewhat diluted copy-left, along the lines of the MIT license.  This idea of dilution, a bit of “water in the wine” is one of the themes of this post.

Payments, Transacting, Blockchains

Despite the pervasive use of open source in computing, it largely failed to penetrate into transacting.  Banks, merchants and others largely ran software that was proprietary, they had systems that were incompatible, they often ran old software patched together into idiosyncratic systems.   These systems were often profoundly “complex,” they mixed the history and “state” of the organization with its tools and logic into inseparable tangles.

Blockchain erupted onto the scene with bitcoin and is having an “open” effect with respect to payments and transacting.  Blockchain was at first a protest, then a hobbyist thing, then a movement, an inspiration for rethinking the possibilities of collaboration, consensus, payment, even government.  It spawned ambitious efforts to right some pervasive inefficiencies and wrongs.  It made things seem possible that had previously seemed impossible.  It also became the scene of wild speculation, including fraud and other disasters.  But through all this, it has been like the open source manifesto, applied to transacting.

Transacting is inherently something that one does with others, and the others do with other others, and so on.  A solution that allows a person to transact with others in their circle must allow transacting with everyone.  Blockchain demonstrates that the barriers to such a system are fundamentally a lack of open source software standards.

We suggest that the most important part of blockchain may be the impetus to create open source transaction functionality (smart contracts) and open source legal templates, together sometimes called “Ricardian Contracts.”  The crypto-money and public database aspects may turn out to be the strong version, crucial to the development of the community, but ultimately not the majority path.  The big problem in transacting may turn out to be the lack of standards, not the existence of intermediaries.  The problems of “trust” may be easier to resolve by legal means – as was the problem of software capture.

My Data, VRM, GDPR

Shared software for transacting can greatly reduce the cost of being an intermediary, but massive aggregations of data still provide an advantage to a large player.  A movement of “my data,” sometimes pushed to “self-sovereign” data and identity developed.  The dangers that this community noticed early on are now widely recognized, by individuals concerned with their privacy and by whole nations concerned with their economic and political autonomy.

The self-sovereign movement gave rise to many innovations, but it may be the European Union’s General Data Protection Regulation that hits the sweet spot, that dilution that preserves the essence and reduces barriers.  The GDPR is presented as a privacy regulation, but the fundamental proposition is that information about people needs to be well-managed, in the interest of the people it concerns.  This means ultimately that people will be able to decide where the information is stored and how it is used.  They can ask for a complete, usable copy, and take it elsewhere, to another fiduciary.  This is impossible unless the information is organized based on standards, that is to say, on open source, common taxonomies.  This provides an alternative path for digital transformation, one based on local management of data, open source software, data minimization and data fiduciaries.

Open Together

The “open” movement is slowly pulling all of transacting and data management into its dynamic.  Open source is largely accomplished – and the fundamental technology is git.  Transacting is on its way, based on shared functionality and shared templates.  Data is also on its way, based on standardized methods for organizing and accessing data.

 

Who Decides What Decides

An attempt to be very descriptive and a little bit prescriptive about the issue of “decision” in transaction systems.

Consider that much of transacting is already mostly automated.  Take a simple situation – can the delivery person leave the package on the front porch? In the first instance, this question will have an algorithmic answer – did the recipient check a box saying that packages can be left on their porch?  On a second level, if there is a history of deliveries, there might be a pattern.  But what if the package is unusually expensive, or perishable, or sensitive to heat or cold?  A computer or puppies?  What if the algorithm says one thing, but experience demonstrates that harm is minimized by another course of action?

Conversely, anti-lock brakes are an example of an algorithm over-riding a human decision.  Except that the human can anticipate that the algorithm will do its work.  The algorithm is also part of the environment in which the human decides.  The recent auto-pilot disaster in Indonesia highlights the problem of what should decide.

A rough schematization of a system of decision could be:

• What makes the decision (in order of increasing authority and effort with some entanglement of 3 and 4):

• 1. Algorithm (formula, protocol, program)
  2. Experience (data, priors)
  3. Rule (text)
  4. Human (applied judgment)
• Who makes the decision.  This list is more approximate.  The decisions include the choice of partner, the parameters of the transaction, adjustments, dispute resolution, dissuasion, interdiction and even punishment. From first instance to systemic:
  1. Parties
  2. Advisors
  3. Interested third parties, e.g. lenders, landlord, spouse
  4. Market-maker
  5. Insurer
  6. Regulator
  7. Legislator

See – Common Trust Fabric

Value-Oriented concept of Prose Objects

Regarding the “datagram” essence of Prose Objects, I’ve just now have achieved better clarity on the model. I’ve long wondered whether a Value should be viewed as the fundamental element, or the Map is the fundamental element. It now seems clear that in a sense we need to think both ways. It is very important to maintain a notion of “file with key=values” as the unit of conversation because this is how so much of conventional computing is organized. From config files to credit card receipts, address card and email datagrams, a file as map of k/vs is a very useful format.

But in understanding the paradigm and in building high-performance systems, it is helpful to focus on the key=values. This is my attempt.

The entire system can be viewed as Values – strings of text whose “keys” are names under which they are stored. For instance, in a file system, a Value is a string stored in a file, and the key is the file name. In a database, the key would be the ID of the database record.

The basic mechanism of Prose Objects is to assign _additional_ names to the Values, to give them additional keys used in the recursive expansion and inheritance.

Let’s express this in git-ish terms (with a nod to Ludovic Dubost, who may have anticipated this mapping).

The Value is a file whose name is the hash of the string. This is how git stores files. A Map is a tree (directory/folder) that references those files using meaningful names (the kind of names we now use for keys). These trees are organized into other trees (directories). These higher level (2nd-Nth level) trees correspond to both: 1) the current system of organization of files into folders [G/Z/ol/*] and 2) the links among Prose Objects. The trees can be traversed in two ways: 1) to add a collection of Values to a namespace of a tree (as is done currently by a link to another file) and 2) to obtain a Value’s string ({G/Z/ol/z6#sec}?). This unifies two concepts that seemed to want unification – the folder hierarchy and the system of links.

Note that this somewhat complicates the notion of a file in the current implementation – each k/v becomes a separate file (or is treated as such). This translation can be handled in interface – each line of a file can be saved as a new file and the “file” can be a folder. But there is a problem or needed refinement because while order does not matter for normal k/vs, it does matter for links (“=[top-priority.md] \n =[second-priority.md]” is not the same thing as “=[second-priority.md] \n =[first-priority.md]”). This needs further thought.

This Value orientation simplifies and adds power.  For instance, you can traverse the file-folder tree for a Value or Map in a way that seems natural but wasn’t possible.  The Values also automatically de-duplicate and connect.

For Prose Objects generally – https://commonaccord.wordpress.com/fulcrum/data-model/

Opining on Opening Law via OpenLaw1 vs #ProseObjects (version 1)

I usually don’t comment directly on “competing” approaches to document automation, but am making an exception for the new www.openlaw.io (@openlaw1).  This is a serious effort by a serious group, with close ties to some of the people who have contributed to CommonAccord.  (I’ll call it OpenLaw1 because there are some other “Open Law”s, including our friends www.openlaw.fr.)  I learned about it today, just before the COALA/MIT workshop on blockchain and governance.

From my brief review, OpenLaw1 is a clean approach to document assembly and a great integration with two important technologies – IPFS and Ethereum.  I fully endorse both those integrations.

It’s approach to document assembly is great in that it uses a few simple embedded bits of code to enable insertion of parameters and alternatives.  It does this with a much more complete interface than CommonAccord’s software, almost all of which was done by Primavera De Filippi, one of the close connections to OpenLaw1’s team, and the co-organizer of COALA.

However, OpenLaw1 represents an important step backwards from #ProseObjects and the goals of a Centre for Decentralised Governance (slideshow for COALA/MIT and IACCM).  I’ll try to state with clarity why the document part is a step backwards.

The basic problem is that OpenLaw1 is a form of document assembly.  You end up with bunches of documents instead of an “object model” or “graph” of relationships.  The documents are much cleaner than Word, but still unstructured.

It’s much more useful to disassemble documents and refer to the components.  This expresses the object model, as a graph.

Some of the consequences of document assembly as opposed to document disassembly are:

1. After filling in the blanks and making choices, the result is a full, not-very-structured document – a “blob.”  A better approach (#ProseObjects) is to keep the info structured – the “document” is the list of differences and completions plus the link to the form and objects for identities, etc.  When you want to view or save the full text, you render.  By retaining the structure, both machine and human reader have a structured representation of all aspects of the transaction, including its variances.
2. The things that a person can modify in the OpenLaw1 document assembly model are limit to things decided in advance by the author of the form.  This kind of prescriptive prediction is the root of the failure of document assembly systems to lead to real codification.   If the author of the document wants to modify some other aspect of a document, they have to do it in the resulting output (e.g., in Word).  This makes the blob non-conforming in ways that will have to be picked up by NLP/AI, and it fails to leverage the knowledge represented in the set of changes for future work.  In CommonAccord, all elements of the document can be changed by adding to the list of changes, so everything stays structured and linked.  The author of the form does not have to predict and manage all variations – use makes the system into a quasi-neural learning system.
3. The OpenLaw1 form is a flat document instead of being itself a set of references to components.  For instance, OpenLaw1 demonstrates the four SAFE Notes done from a common form, but the components of the form are not structured and available for codification and reuse.  In our codification of the SAFE Notes, each document is made from a common set of deal points and the forms are made of components (www.commonaccord.org/index.php?action=list&file=F/Demo/Note_YC/).   In the demo of the Series Seed documents extended by CooleyLLP, we show closing binders of sets of documents made the same way.  The “assembly” should be able to have as many layers as needed to express anything as a compilation of smaller components.  A graph (or Lego) all the way down.

In sum, the integration with Ethereum is to be applauded.  It represents a version of the  “parameters, prose and code” Ricardian contract model.  (Wise Contracts paper with Helena Haapio.)  At the COALA/MIT workshop over these next days, I hope to explore this intersection from a number of perspectives, including with Henning Diedrich and Florian Glanz of the Lexon project.

The integration with IPFS is also great.  IPFS hashing provides a great way to assure the availability and conformity of prose and code.  In a model of Prose/Code/Access/Hosting/Analytics, IPFS seems very useful part of the hosting layer.  (BanqueChain demo for a hypothetical global banking system expressed as nested file folders, with reliance on IPFS.)

#ProseObjects offer a way to keep all transacting information in structured form.  They are necessary to the project of open-sourcing all legal forms and compliance, for the IACCM’s project of general codification of commercial documents, and for a legally-inclusive peer-to-peer transaction system.

#ProseObjects are certainly necessary for Centres for Decentralised Governance.

Linked Chains: the First-, Second- and Third-Person of Blockchains

The three parts of a transacting system can be expressed as three roles:

1. A first-person role – “I” want to write a program that describes the transaction and will cause it to occur. For instance, I want to buy something by selecting the item, specifying the price and delivery, and clicking “order.”

2. A second-person role – “I” need to communicate this to the relevant “you,” and have “you” understand and agree.  If I’m using your website, you website handles this. A blockchain provides a way that is shared, consistent and neutral, where you and I are peers.

3. A third-person role – If “we” have a disagreement, then there must be a third-person who reviews the facts and decides. The third-person may be abstract – a community – and is not always very sharply defined. At the outset, it might even be the second-person, thinking more deeply.

Conventionally, this third-person is often implicit.  Both parties may know people in common, live in the same community.  Our reputations precede us and will be affected by our behavior.  In more formal relationships, the third-person role can be a company supervisor, a school principal, a police officer or court.

In any dispute, there is the problem of proving “facts”, knowing rules and the availability, patience, competence, cost and neutrality of the decision-maker.

Blockchains address some of these problems in a way that can be applied across a very wide domain. For the first-person, the author, blockchains provide patterns for transactions, often called “smart contracts.”  For the interaction with the second-person, they provide a communication method and reliable records, including signature.  For the third-party role, they provide a community that validates the state of the record (the documentary facts) and can automatically enforce some types of interactions, notably operations on tokens.

Blockchains of course address only some of the facts and some of the enforcement that is relevant for “real world” transacting. For contracts that touch on outside “reality” (the world we live in), the parties must depend on people and institutions for facts and trust. The documentary trust function and token escrows that a system of records provides can be very important in reducing disputes, but when the performance involves facts or actions that are not merely records, the ultimate trust lies in these conventional third-persons.

Because blockchains have significant disadvantages from the perspective of information security, speed, cost and flexibility, they will supplement, not fully-supplant conventional systems such as databases, email, web interfaces and newer systems such as IPFS and graph databases.

CommonAccord generalizes the first-person role – authorship or programming of transactions. It provides a common data model for referencing both prose and code aspects of transactions, independent of the platform.

In the Ricardian paradigm, it simplifies programming/authoring as the creation of a “record” consisting of parameters and references to the context of the record.  Most records will resemble credit card receipts – a list of a few key facts – and a link to the context.  The references will have a “prose” component and a “code” component.  By referencing them using names that are independent of the infrastructure (e.g., by hash), they can be used across different platforms. The code – smart contracts – can become commoditized and standardized in a granular, iterative manner, as can the prose.  The granularity resembles the Unix model of small modules with discrete functions, chained together.

Because this record format can work with blockchains and conventional IT systems, it can knit them together.  Blockchains will fill the gaps that conventional systems have left.  But blockchains, as the standard for interoperability, will cause standardization of the conventional systems.  Enterprises will be re-automated from the outside, as a result of their need to work with their customers and suppliers.  The blockchain movement can be the cause of the transformation of all of IT and law, even as it is only a part of the solution.

The combination of blockchains, decentralized access management systems, IPFS and graph databases, can make a truly peer-based system of transacting.  This can encourage the democratization of transaction “programming”, greatly reduced complexity in IT and legal, and reduce the need for centralized “hubs” – both human and tech – to manage people’s affairs.

Contract Standards Codification Roadmap

For the reasons set out in the IACCM Contract Principles, the contract forms and clauses at CommonAccord are intended to provide a base for contracting among parties. In addition, these materials are made available in the way of open source software, which allows easy sharing and improvement.

There are many perspectives from which to approach contract standards. The IACCM Contract Principles approach standards from the perspective of refining and defining basic contracting ideas.  Analytic software approaches standards by finding common denominators in collections of actual contracts.  “Legal Design” approaches standards from the perspective of communication with users.  Model forms projects create complete solutions for sharply-defined uses.

The joining point of these efforts can be said to be an outline of the ideas and kinds of documents that express the ideas.  The outline:

• should be organized to correspond to basic ideas;
• have actual forms and clauses arranged on it, as in systems such as KM Standards and RAVN; and
• be presented to the parties in a simple and compelling way that allows direct use and can be complemented with guidance and other aids to decision.

Such a shared system should “learn” — become better over time — from the experience of participants, the teachings of analytics and the interventions of experts.

The system should fit with two critical trends in IT:

• “distributed access control,” such as UMA; and
• “smart contracts.”

We suggest a starting point for the outline would be a list of some common contract types, each one populated with a list of common section headings …. (to be continued).

Prose Objects for Enterprise

Eve Maler (@xmlgrrl) contemplating enterprise engagement with prose objects, wrote:

I would guess that making sure this system works would be a combination of a) suitably sophisticated and complex parameterization that meets real-world use cases and b) a “stack” of base prose that does right by individuals before it ever gets to organizations, but then (c) is still appealing to orgs and the corporate contract-editing tools they use.

That thought meets mine in the middle.

(c) Integration with Contract Management Systems:

The one thing the entire community (global, business, govt, advocacy, everybody) is missing is a way to codify legal.  So the clear win for all end-users (from Adrian’s autonomous patients to GE) is “prose objects” hosted and improved by collaboration on Github (and also published by IPFS or equivalent).  Use of publicly-available prose objects with clear “provenance” (@findthomas) will:

1. accelerate negotiation via common starting points (see the purpose of IACCM Contract Principles introduction);
2. give the clarity benefits of stable legal provisions (the basic function of legal “codification” and the great advantage of codified legal domains over uncodified domains);
3. allows weaker, busier, less diligent parties to benefit from the sophistication and even the leverage of experts and peers.

Even sophisticated contract management systems (CRM) don’t cause general legal codification.  For organizations that are happy with their CRM, they might use prose objects “merely” as sources for legal text.  They might use them as legal forms, or might interface to them for more functionality.   Enterprises might find that they want to contribute to prose objects in order to influence the direction of legal standards.  They might do that by publishing prose objects on their own sites, or (better) by forking on Github, or (even better) through organizations such as the IACCM and legal groups.

(b) Individual Perspective:

While it is possible to address the problem of legal standards from the perspective of the individual, and ultimately a major impact will be (and should be) to empower the smaller actor (individual, company, country – almost all of us are small sometimes) it seems likely to me that the legal materials will originate from the more systemic partner.  For instance, the UMA Legal materials, the IACCM Contract Principles or the Y Combinator SAFE Notes.  It will be found that legal documents are not terribly complicated – despite the apparent endless variations and length.  The issues recur and improve with recursion.  The purpose of legal terms is to facilitate good behavior by both parties, to enable the relationship, to reduce the cost of inter-personal collaboration (Coase).  The smaller party will no longer be alone.

(a) Parameters

The choice of parameters is very important.  The easiest way to be sure to select parameters that cover the critical issues is to use existing forms – forms that persons (organizations) actually use.  “Accordifying” an existing form immediately pops-out the terms that the actors thought important.  Iteration will validate (or invalidate) their choices and find others.  The type-less model of CommonAccord, where all elements are parameters, means that we don’t get stuck with early choices.  Iteration will reveal the truth of what actors actually need.

For those organizations that directly use the prose object format for negotiation and signature, adoption leads to a true P2P data model, compatible with access-based approaches such as UMA and with GDPR and PSD2.

Eve adds:

• UMA Legal home page
  • Drilling down: Deliverable #1 on the way to our legal framework: Use Cases for Analyzing and Determining a Legal Framework (requires permission), which includes lots of use cases (mentioned in a) )
  • Draft model text (very old at this point and likely to change, informed by the eventual legal framework)