commonaccord/cmacc-org

The full CommonAccord.org website, including many of the sub repos.

cmacc-org's Issues

Standardized Section Lists!

With the #fchack team from #UMKC - @bryangw1 and @zmon -we have been working on a Universal License Object Model (ULOM). (For same project, @zmon is creating an interface for data entry. https://github.com/UMKC-Law/cmacc-ui.)

The idea is to treat all license agreements as fruit (actually, leaves) of a common tree. To build an agreement from the trunk up, branch it for things like patent, copyright, TM, database, know-how, space (a ticket to a show or use of a desk at an incubator is often a "license"), use of personal information (!), etc.

We do the branching via section headings. The trunk of all contract agreements can include the back matter (Term, Limit, Dispute, Remedy, Misc). With a bit of shoehorning, we can think of that as TL;DR, appropriate to each context. TLDRMD becomes Term, Limit, Dispute, Remedy, Misc, Def. (There can be variations, of course, and arguments for including Notice as a separate heading instead of it being in Misc, and so on. But it's a mnemonic.) This is the back matter (TDLR.Secs).

In front of that we add sections for the business part of a license. Grant, SubLic, Comp, Conf, etc. Exact names are not fixed, just a starting point for iteration. They will vary according to the subject matter of the license (patent, copyright), the business purpose, the jurisdiction, etc.

The subsections are further branching, handled the same way (a subbranch is to a branch as a branch is to the trunk). Twigs, etc.

The actual text forms the leaves. Here is a trunk for an outline-based tree of agreement - Law/Out/.

Because the CommonAccord data model is a Euler "graph" (think of a map with lots of routes to each place), people can repurpose branches and twigs to their own purpose without interfering. (Squirrels hop from branch to branch, drivers use different routes.) They will make their agreements by referencing a point on the tree (if the tree already has what they want) or by referencing a couple of points (mashup) or by adding a branch, twig or leaf.

Eventually, the tree will cover a lot of ground, providing legal shelter and jumping off places. By starting with the sections, we can sketch out a large part of the tree, even if it will originally have only a few twigs and leaves. A springtime promise of shade to come.

Peace.

Hello-World

Eve asked, Marc has long militated for:

Cmacc for Dummies

Learning the system is easy because there is not a lot you can do. Just a few things. Cmacc mostly just ties together stuff you already do (or should do) - make files, reference files, edit a page. Much of this can be done via a GitHub account, and that is the preferred way to collaborate on helping us create legal standards. Soon we hope to have a browser-based "parser," which would mean that you would never have to do more than use GitHub or your own choice of hosting for files, for instance Mediawiki. And soon we hope that transacting platforms will include a parser in their interface so that you never have to leave your phone. In the meantime, however, to get full benefit, you have to do an "install." If you are a techie, this can be one minute (clone github.com/commonaccord/Cmacc-Org to a place with LAMP capabilities). Otherwise, you may have to find a techie or brave the installation of https://www.mamp.info/en/ and figuring out how to clone on GitHub. We have some help for you on that. How to Deploy Locally

We assume that you have a local install.

Make a file:

Use a text editor. Save a file where you want in /Doc/. /Doc/ has all the Cmacc files. It is recommended, but not necessary, to end the file name with ".md". You can continue to edit in the text editor or navigate to the page in your browser and click "Edit". If you are Eve and want to play go to http://www.commonaccord.org/index.php?action=source&file=S/Sandbox/Eve/1_v0.md

Make a "document":

Type the following:

Model.Root={HW}

Save (in your text editor) and then click "Document". You'll see {HW} in red.

Go back to editing (click Edit) and add a line (either above or below the previous one, but it is good practice to add above.

HW={H} {W}

Save and click Document. Now you have {H} and {W} in red, because {HW} was expanded by HW=.

Now click Edit and Complete - you'll see that H= and W= are there, waiting for you to type "H=Hello" and "W=World" (without the quotes). Save and click Document. Hello World

Now click Edit and add at the top(priority counts) "H=Bonjour". Leave the H=Hello in the document. Click Save then Document. "Bonjour World".

You are halfway there.

Next, add a line at the top:

=[Z/ol/5]

"Comment out" the Model.Root={HW} by changing its name to, say, /Model.Root={HW}. Click Save, Document. You should see an outline of five points, nearly all of it in red.

Next click on Edit and Complete:

You will see that the only thing you are offered is "Ti=". Complete it with Ti={HW}. But also write 1.Ti=English and 1.sec=Hello {W}. Save, Document. You should have a section with a title "Bonjour World" and a section 1 titled "English" with content of "Hello World". (You will also notice that each of the subsections defaults to the same title. This is because of "de-prefixing" - a very useful feature, often extremely natural seeming, but sometimes also veodd, like here.)

Click edit, and add (either above, or below your last work) 2.Ti=French, 2.sec={H} Monde. Etc.

You have done overriding, both in the file and vis-a-vis the =[Z/ol/5].

Now, add an intro to the paragraph sections. In Edit, add:

0.sec=Here's how you say hello in different parts of the world:

Save, Document. You'll see that there is now an intro. (It defaults to no intro because deep in [Z/ol/5] is an 0.sec=, which presents as nothing. (HTML is oddly sweet about these things.)

You can do the same for an extro -

90.sec=That's all for now.

Now let's do "prefixing." Let's say you want to do the variations on English - UK, US, Aussie, etc. In Edit, type:

1.=[Z/ol/3]

and

1.1.Ti=UK

1.1.sec=Top of the marnin'

1.2.Ti=Australian

1.2.sec=G'day

1.3.Ti=US

1.3.sec=Howdy

1.4.Ti=Geek

now - CHANGE the key on 1.sec=Hello {World} to 1.4.sec=Hello {W}

(Notice that the position in the file doesn't matter, except that if there are two (or more) keys with the same name, the FIRST one is what counts.)

LMK - done blind.

Docs that would be useful for a startup

• Agreement to hire consultant
• Agreement to hire employees
• Agreement to sell stock or give stock options
• NDA (mutual and non-mutual)
• MOU
• Generic contract (just the standard stuff with anything related to an actual deal into an appendix - scope, price, schedule)

Deal examples

Please let me know any thoughts about this way of organizing:

http://new.commonaccord.org/index.php?action=list&file=Dx/Acme/

I expect that when sharing, Acme and, say Quake, will want to chose a folder name that combines them - Dx/Acme-Quake/ - or, of course, based on their identities. But this is a rough start.

LMK

WHERE IS THE DOCUMENTATION!

Per @dazzaji and everyone else, this looks promising, but how does it work??

Enable TLS / https

Would be great to add a secure certificate so users can be sure that we are connected to the right site. Let's Encrypt is recommended: https://letsencrypt.org

What is the naming scheme?!

@HazardJ has been fiddling with naming schemes for some years. With this repository, it is proposed that we take advantage of found objects - to wit, the WorldWideWeb and GitHub. So, files can be organized according to the web domain of the proponent, or according to the Github organization and repo name. These can be managed as local files, or the whole of GH/ and W/ (or GitHub/ and WWW/ ?) can be aliases for files at those destinations.

See https://github.com/CommonAccord/Cmacc-Startup2/blob/master/Doc/include.php (@dazzaji, someone else, how do I make a link to a file in the repo?)

This defines, in essence, a proponent's exclusive space.

Within that space it is suggested (by me and my experience) that we suggest a type of organization. This is of course not mandatory, but might be helpful. My experience is that two folders are helpful - one for forms and the other for components. Most components of most forms will be "sections" so, Form/ and Sec/. Note the initial caps. This distinguishes from the web domains, and CamelCase is easier to read (@dazzaji has made this point, too).

From there, we get into mostly details, but one of them stands out. The "extension" of the files (.md, but could have been .cmacc or the like), is important. It tells GitHub how to present the file when you go to the source there. It tells your computer what editor to use when you double-click the file. We have been using .md and had good experience with that. It has been objected that we are overloading the .md extension name. That a Cmacc file is not markdown. It's something else. That seems accurate as a technical matter, but pragmatically, .md works well. So if/until GitHub makes special accommodation for .cmacc or the like, I suggest we stick with .md. (Note that some common files don't have .md, such as the ones that make outlines, in Z/. It seems pedantic to have those rarely edited bits have .md, and adds a bit of cruft when you use them.

The next most systemic issue is probably the names that denote parts of a document. In the Z/ folder, there are lots of little widgets that make it easy to put documents together or cut up an existing document and automate it. These are of course not exclusive, they are just more folders of files, and we can always make more. They assume an organization of sections as "Sec" means a section and its title. "sec" means the content of the section (without its title). "Ti" (chosen because it works in English/French/German and probably a lot of places of romance) means Title/Titre/Titel. Within the content of a section (the "sec" part) there is the possibility of an introductory line or paragraph, then a list, and then an extroductory line or paragraph. There is a naming convention for those, too, built into the stuff at Z/. The intro is 0.sec, the extro is 90.sec (if you have more than 89 paragraphs in a section you either rethink it or make your own). They could be Intro.sec and Extro.sec just as easily (remember that everything is just names, there is no calculation).

Into the weeds:

The name of the actual files (as opposed to the folders that organize them) could be long and expressive. I've played with that a lot. But, that seems cumbersome and a bad tradeoff. More sensible is to make the file names short and merely state their function. So ... Wx/org/nvca/SPA/Sec/cRep_v01.md is the Company representations. This could be made more expressive - /CompanyRepresentations_v01.md, though if you work with these files a bit, cRep is a bit less work to read. But, skipping that weed on a weed, the point is that I didn't name the file NVCA_SPA_cRep_v01.md. Because that info is already in the path. This works fine as long as the file is in the file system. Which is where it should be, so this seems a better than the repetition of Wx/org/nvca/SPA/Sec/NVCA_SPA_cRep_v01.md.

Out onto the fields:

Of course all of these things can be further automated. The Z/ things could be done as some bit of code that provided quicker responses, had more features and didn't take some 800 files to count to 40. The W/ could actually fetch from the web, and GH/ from GitHub.

The form of a variable - {some thing} - allows spaces, so one can put programming expressions into a document and your parser could default (after looking to see if there was a literal keyname match) to a programming environment. This has lots of potential uses, and is totally necessary for even such common tasks as adding price times quantity. Automatic numbering of cross-references is another common example. There is a pretty good way to do it natively, but perhaps people will want this to be fully automated.

Above our heads:

All this CommonAccord text is legal fodder for real deals. It can be used natively (Be-Bound does.) But it is most likely to be a resource for real transaction systems - such as blockchain. So, the fit with identity and place (U/) and with automation (adding price times quantity and applying a discount) will be done in those systems. CommonAccord, and the Cmacc document model, is a place to do text.

The URLs are long and ugly

The URL of a page has something like this in it:
/index.php?action=source&file=

That is not beautiful, and distracts from understanding the content.

The only part that is meaningful is "source" which is the type of view of the page. The alternatives are (or should be) "doc" (for rendered) "edit" for ..., editcomplete, print, etc. It would be great to get the URLs whittled down to only meaningful elements: the file name and the view. I presume that view could come after the file name (as in Google docs and Mediawiki), but don't know if that would feel better or worse. My sense is that it would feel better, but someone else would have to push for that before I would think it worth experimenting. Maybe @zmon could give us a hand?

Issues to follow up:

Law Insider has a bunch of documents available, but their terms of service do not permit anything beyond "personal use" https://www.lawinsider.com Currently there is one clause we have included from their website as part of the ULOM, but in the future this is something that would need attention.https://github.com/CommonAccord/Cmacc-Org/blob/master/Doc/GH/FutureCommerce/ULOM/Bryan/Sec/Grant_Sublicense_v1.md

Cmacc data model -

Breaking this out from the discussion of IPFS:

What is the core Cmacc data model. This is an active discussion now because @wilmveel has done great work on a somewhat different model. - Here is my best abstraction:

Cmacc can be described as three levels of expansion (2 currently implemented, 1 speculative):

1. {variablename} in a value (k/v), expanded by matching "variablename" with a key name in a dictionary.
2. [filename] in a dictionary, expanded by matching the name of another dictionary, from a default list of dictionaries.
3. [[folder]] in the dictionary (or an included dictionary), expanded by matching another list of dictionaries.
   All this can be understood as files in folders. It can also be done in any other format, including databases. It may be helpful to consider files in folders as the canonical form of dictionary since they are i) widely used and understood, even by casual users, ii) the format of git and software collaboration.

.3. is currently not implemented, the sole dictionary is /Doc/ (though with the [?http://...] convention one can include another dictionary ad hoc.)

.2. [file] has an "include as" notion - if the key is not blank, then the keys in the linked dictionary will be treated as prefixed by the key. ( 1.=[Z/ol/4] ). The {variables} in values in the linked dictionary will also be i) treated as prefixed, ii) if no match is found, treated by removing the prefix. Where there is recursive prefixing, the right-most prefix is removed first. (This deprefixing works exactly in Primavera's implementation. It is a consequence of her use of objects, not as a result of my specification. That is a very satisfying confirmation of the logic of the model.)

Additional features:
A. [[folder]] in the dictionary (or an included dictionary), expanded by matching another list of dictionaries. (See above.)

B. "Magic folders". A special file that can be put in a folder and acts like a .zip file - i.e. it expresses a sub-tree of the folder. But calculated instead of being a bunch of actual files. Useful for such things as the thousands of section widgets - http://www.commonaccord.org/index.php?action=list&file=G/Z/. The magic folder should return a file if there is no actual file there. If an actual file exists, then that file overrides the magic folder. (Same override paradigm. Failure to find a file causes the system to look up the folder tree, recursively, looking for a file with a particular name, e.g. "MagicFolder.cmazip".) Some uses will seem very text-oriented, for instance specifying the exact selection of exceptions to confidentiality. (Here is the use case to be solved: http://www.commonaccord.org/index.php?action=source&file=G/Agt-NDA-CmA/Sec/Relate/Conf/Except/Item/0.md.) But this will also allow some uses that approach "algorithmic" law. A complex structure can be programmed as a string that pretends to be a file name. A bridge between "codification" and "code-ification."

C. Generally, integration with graph queries. The current model can be understood as a specific form of graph query. In a graph, with node A as root, starting at node B, using key C, expand and return this as "document" or "print" view, or tell me all the possibilities for matching key "D". Etc.

Update repo description: http://commonaccord.org

Per CommonAccord/Site-Org#42, AFAICT this seems to be the correct repo for commonaccord.org? If so, please add that website to the repo description and remove from CommonAccord/Site-Org repo.

Name of Repo

Since this is no longer about startups only, we should rename the repo. Cmacc-Org could be a good option.

What is the CommonAccord initiative? Who, what, why ....

I (HazardJ) was asked (edited to separate into a list):

1. Who founded the initiative?
2. how was the 'transition' or turn involving the Paris people?
3. what is Kantara and how does it relate?
4. What industry/commercial players are relevant on the slack?
5. which plans do they have in relation to CommonAccord?
6. What is your role?
7. Is this a full time engagement for you?

IPLD implementation of Cmacc -

The advantages of an IPLD implementation of Cmacc seem huge.

The goal of this Issue is to identify any issues in doing so.

At the Kantara Initiative BSC group, I (HazardJ) laid out what I see as a difference in the linking semantics - the use of "/" to denote transitions from one record to another and across indents (what's the name for this?) in a record.
https://kantarainitiative.org/confluence/display/BSC/Charter?focusedCommentId=81429144

Other than that, they look compatible to me, and IPLD is richer. It has the indent notion, which is very helpful, and has other data types, which would, I presume, allow integration of computational information along with the Cmacc text objects.

Fire away.