LegalHub: Difference between revisions
Jump to navigation
Jump to search
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 16: | Line 16: | ||
==Overview== | ==Overview== | ||
===What=== | ===What=== | ||
*'''A centralised hub''' with free, unlimited access for everyone whether as a user or a contributor. At first a "legal code" repository that would function as a free open-source template/contract library | *'''A centralised hub''' for standard legal terns and forms with free, unlimited access for everyone whether as a user or a contributor. | ||
*'''Day 1''': At first a "legal code" repository that would function as a free open-source template/contract library: | |||
:*'''Bilateral agreement forms''': confis, engagements, terms of business, etc | :*'''Bilateral agreement forms''': confis, engagements, terms of business, etc | ||
:*Legal agreement components: components of the boilerplate, standard forms | :*'''Legal agreement components''': components of the boilerplate, standard forms | ||
:*Market standard utilities: LMA forms, ISDA forms, ICMA, TBMA etc. | :*'''Market standard utilities''': LMA forms, ISDA forms, ICMA, TBMA etc. | ||
:*Legal opinions and advice. Seems controversial, but those who do will get follow on instructions. The first in gets a jump on the rest! NETTING OPINIONS! | :*'''Legal opinions and advice'''. Seems controversial, but those who do will get follow on instructions. The first in gets a jump on the rest! NETTING OPINIONS! | ||
*'''Day 2''': to develop applications organically. Some potential applications (user demand to determine whether viable: | |||
:*'''Negotiation hub''': online interaction to shift away from paper contracts to authenticated smart digital contracts | |||
:*'''Execution portal''': Free, non-commercial, electronic execution portal | |||
:*'''Document assembly''': User-maintained document assembly application | |||
:*'''KYC hub''': Free, non-commercial, KYC data hub. | |||
:*'''Tokenised digital wallets''': No central repository of sensitive data. Allow peer to peer. | |||
===Design principles=== | ===Design principles=== | ||
*'''Transparent''': Fully version-controlled, transparent — allow people to take, adapt, copy any iteration. | *'''Transparent''': Fully version-controlled, transparent — allow people to take, adapt, copy any iteration. Including the source code of the App (like MediaWiki). Allow people to develop it, augment it, improve it (see: “don’t be a futurologist” below), or implement internal/independent instances if they wish (Like, er, MediaWiki!) | ||
*'''Don’t be a futurologist''': Design it to solve problems we have ''now'': | *'''Don’t be a futurologist''': Design it to solve problems we have ''now'': Don’t try to anticipate use cases/design models of the future. We can only get to a design model through evolution: iterative development that meets ''prevailing'' fitness criteria. Thus open architecture to allow users to develop modules, applications. Design according top the “[[end-to-end principle]]”. | ||
*'''Permissive, open-architecture''': Corollary of the above: ''We are hopeless at predicting the future''. Design with a permissive, open architecture. Expect users to develop it as they see fit, according to their evolving need and use, rather designing for an expected future structure from the outset. | *'''Permissive, open-architecture''': Corollary of the above: ''We are hopeless at predicting the future''. Design with a permissive, open architecture. Expect users to develop it as they see fit, according to their evolving need and use, rather designing for an expected future structure from the outset. | ||
*'''Design and user experience is vital''': Make it intuitively useful and easier than the alternative. | *'''Design and user experience is vital''': Make it intuitively useful and easier than the alternative. | ||
| Line 29: | Line 36: | ||
*'''Digital/creative commons'''. Release all code as open source. Allow/encourage people to use, develop code without limit. | *'''Digital/creative commons'''. Release all code as open source. Allow/encourage people to use, develop code without limit. | ||
*'''User content''': Permit users to store confidentially, but discourage it. Encourage people to make their content, models freely available. Encourage viewing code as a community resource. This is the [[digital commons]]. | *'''User content''': Permit users to store confidentially, but discourage it. Encourage people to make their content, models freely available. Encourage viewing code as a community resource. This is the [[digital commons]]. | ||
*'''Crowd source/ | *'''Crowd source/reputation, management to surface the best bits''': Use reputation management techniques (use, frequency, user ratings etc) and the network effect to surface most popular forms, segments, components. | ||
===Governance=== | ===Governance=== | ||
*'''Ownership model''': Charity-owned. Model: [https://wikimediafoundation.org/ Wikimedia Foundation]. | *'''Ownership model''': Charity-owned. Model: [https://wikimediafoundation.org/ Wikimedia Foundation]. | ||
*'''Operating costs''': Pay for it. All of it. Pay a ''lot''. Consider this a down-payment on the savings you will make by unwinding the [[military-industrial complex]] is current outsourcing arrangements have become over 20 years. Encourage partners to contribute, and also fund their own developments (see “don’t be a futurologist”) | |||
*'''Partners''': Find strategic partners. | |||
:*'''Get the oppo involved''': Engage with firms whose interests nominally conflict with yours. (buy side vs sell-side; broker v broker, law firm v client) | |||
:*'''Encourage trade associations''': Use influence within partners to bring them to table. Encourage them to donate all their IP (enough already of “copyright ISDA”). | |||
:*'''Look to split the bill, but don’t quibble''': Encourage other strategic partners to pay too, but no penalties if they don’t. The more you all pay, the better the product will be. Pay to make it easy for anyone to engage and use. | |||
===Development model=== | ===Development model=== | ||
*'''Build for the long term''': Recognise that adoption and development will be slow at first. Stick with it. | *'''Build for the long term''': Recognise that adoption and development will be slow at first. Stick with it. | ||
*'''Direction''': Start with what we have: traditional text-based contracts — how folks do things ''now'', for better or worse — expect it to a fully digital, networked, authenticated smart contracts world if that is the best fit | *'''Direction''': Start with what we have: traditional text-based contracts — how folks do things ''now'', for better or worse — expect it to a fully digital, networked, authenticated smart contracts world ''if'' that is the best fit. | ||
*'''A phased approach''': Recognise that development will be slow. Start with what we have: traditional text-based contracts — how folks do things ''now'', for better or worse — expect it to a fully digital, networked, authenticated smart contracts world if that is the best fit. | *'''A phased approach''': Recognise that development will be slow. Start with what we have: traditional text-based contracts — how folks do things ''now'', for better or worse — expect it to a fully digital, networked, authenticated smart contracts world if that is the best fit. | ||
==But how do I make money== | |||
*Content providers (reg tech firms, lawfirms) become developers building specific code for the system which they can be paid by partners on a project by project basis. No [[rent seeking]]. | |||
*Industry associations should donate their IP because it is in the interest of their members to do so. | |||
* | |||
==Implementation== | ==Implementation== | ||
Revision as of 17:51, 25 November 2020
|
Bringing GitHub to the legal eagles. Credit to Graeme Johnston of https://www.juralio.com for the nub of this idea.
So the idea is very very formative, but in a nutshell it is like an open-source GitHub, only for legal code — that is, legal text. Words. The challenge is to keep the simplicity but not throw away the opportunities provided by the network and the digital commons.
How is this different to existing platforms?
All existing platforms are in some way proprietary, limited in access, intended as commercial enterprises in themselves with a pre-defined solution. The future not being as predictable as we would like, any platform designed on a controlled, owned basis has inadvertently designed-in obsolescence.
Therefore (i) they are unresponsive to real-time demand; (ii) they are expensive and high maintenance; (iii) they unnecessarily extract rent, and encourage down-stream rent-seeking behaviour from participants (iv) they preserve confidentiality and a worldview which regards as proprietary an element of market infrastructure (boilerplate) that is in fact a public utility.
ClauseHub would be managed more or less like the MediaWiki Foundation: open architecture, non-proprietary. Participants would donate their proprietary technology, and would be free to develop utilities for it based on emerging demand.
Just “boilerplate”?
We take a wide view of what counts as “boilerplate”. All legal documentation that would not feature on a one-page term sheet is “boilerplate”.
For the underlying economic/systems rationale, see: ClauseHub: theory
Overview
What
- A centralised hub for standard legal terns and forms with free, unlimited access for everyone whether as a user or a contributor.
- Day 1: At first a "legal code" repository that would function as a free open-source template/contract library:
- Bilateral agreement forms: confis, engagements, terms of business, etc
- Legal agreement components: components of the boilerplate, standard forms
- Market standard utilities: LMA forms, ISDA forms, ICMA, TBMA etc.
- Legal opinions and advice. Seems controversial, but those who do will get follow on instructions. The first in gets a jump on the rest! NETTING OPINIONS!
- Day 2: to develop applications organically. Some potential applications (user demand to determine whether viable:
- Negotiation hub: online interaction to shift away from paper contracts to authenticated smart digital contracts
- Execution portal: Free, non-commercial, electronic execution portal
- Document assembly: User-maintained document assembly application
- KYC hub: Free, non-commercial, KYC data hub.
- Tokenised digital wallets: No central repository of sensitive data. Allow peer to peer.
Design principles
- Transparent: Fully version-controlled, transparent — allow people to take, adapt, copy any iteration. Including the source code of the App (like MediaWiki). Allow people to develop it, augment it, improve it (see: “don’t be a futurologist” below), or implement internal/independent instances if they wish (Like, er, MediaWiki!)
- Don’t be a futurologist: Design it to solve problems we have now: Don’t try to anticipate use cases/design models of the future. We can only get to a design model through evolution: iterative development that meets prevailing fitness criteria. Thus open architecture to allow users to develop modules, applications. Design according top the “end-to-end principle”.
- Permissive, open-architecture: Corollary of the above: We are hopeless at predicting the future. Design with a permissive, open architecture. Expect users to develop it as they see fit, according to their evolving need and use, rather designing for an expected future structure from the outset.
- Design and user experience is vital: Make it intuitively useful and easier than the alternative.
- Secure: It should be fully secure, store no customer data etc. No central repository of sensitive data. Encourage APIs and peer to peer interaction with existing systems.
- Digital/creative commons. Release all code as open source. Allow/encourage people to use, develop code without limit.
- User content: Permit users to store confidentially, but discourage it. Encourage people to make their content, models freely available. Encourage viewing code as a community resource. This is the digital commons.
- Crowd source/reputation, management to surface the best bits: Use reputation management techniques (use, frequency, user ratings etc) and the network effect to surface most popular forms, segments, components.
Governance
- Ownership model: Charity-owned. Model: Wikimedia Foundation.
- Operating costs: Pay for it. All of it. Pay a lot. Consider this a down-payment on the savings you will make by unwinding the military-industrial complex is current outsourcing arrangements have become over 20 years. Encourage partners to contribute, and also fund their own developments (see “don’t be a futurologist”)
- Partners: Find strategic partners.
- Get the oppo involved: Engage with firms whose interests nominally conflict with yours. (buy side vs sell-side; broker v broker, law firm v client)
- Encourage trade associations: Use influence within partners to bring them to table. Encourage them to donate all their IP (enough already of “copyright ISDA”).
- Look to split the bill, but don’t quibble: Encourage other strategic partners to pay too, but no penalties if they don’t. The more you all pay, the better the product will be. Pay to make it easy for anyone to engage and use.
Development model
- Build for the long term: Recognise that adoption and development will be slow at first. Stick with it.
- Direction: Start with what we have: traditional text-based contracts — how folks do things now, for better or worse — expect it to a fully digital, networked, authenticated smart contracts world if that is the best fit.
- A phased approach: Recognise that development will be slow. Start with what we have: traditional text-based contracts — how folks do things now, for better or worse — expect it to a fully digital, networked, authenticated smart contracts world if that is the best fit.
But how do I make money
- Content providers (reg tech firms, lawfirms) become developers building specific code for the system which they can be paid by partners on a project by project basis. No rent seeking.
- Industry associations should donate their IP because it is in the interest of their members to do so.
Implementation
Phase (a): publish
- Establish platform
- Publish in downloadable templates in word or PDF format and say to everyone "have at it. help yourself." Sponsor then as XYZ content, open source. Standard agreements — NDAs etc.
- Grant pre-approved users (with low threshold) ability to do likewise
- Develop navigation methodology - metadata tags, Boolean search etc.
- Reputation management for templates
- Strip back and break out all the boilerplate - governing law, reps and warranties etc.
Phase (b): modularise
Build an open architecture to participants can start to interact directly, either by reference to the hub itself (for legal terms) or directly through it. Basically, make an online, simple, doc assembly tool, free for anyone to use and play around with as they wish. Like GitHub.