LaTeX templates for contracts

[Zeke Vermillion]

Does anyone know of a LaTeX template designed for serious contract-drafting? Or an effort toward one? There are various XML-for-contracts projects, but for various reasons I am leaning toward the view that XML may be a non-ideal approach.

[Flora Vern]

Dear Zeke,

I don't know of any such thing, although I have a draft somewhere. At the moment, my coding backlog is huge, but sometime in the future (not within months…) I would be glad to code one. I am in the academia and don't draft "serious" contracts, hence I need to know exactly what lawyers need.

The one thing we need is specifications. I can code anything fairly quickly if I know what to code, i.e. which tasks require a dedicated macro in order to maximize efficiency, and what should this macro do.

The XML projects you mention probably have all the info we need, if we can get our hands on them (though I agree, XML seems unsuitable). At least they will have encountered the various strings we need to put into macros and the various environments we need to laying-out the page. If one of them has straightforward code or documentation we could use that in order to decide how to do it in LaTeX. Could you provide the most suitable one(s)? And, additionally, a list of what you would expect for serious contract drafting? (i.e. which things do you think should be automated or have a shorthand, and what are the possible values / content types for each of them). You should include anything that relates to tables / lists of things or collections of standard clauses as well, because we can automate that.

As I said earlier, not promising anything will be done shortly because I have a dissertation and all of its LaTeX code on my hands beforehand, but I may be able to create a functional proof-of-concept that someone can elaborate on.

Flora

PS: Nice to see a fellow sea kayaker :)

2016-08-12 1:16 GMT+02:00 Zeke Vermillion <zeke.ve...@gmail.com>:

Does anyone know of a LaTeX template designed for serious contract-drafting? Or an effort toward one? There are various XML-for-contracts projects, but for various reasons I am leaning toward the view that XML may be a non-ideal approach.

--
LaTeX for Lawyers: http://www.latexforlawyers.org/
---
You received this message because you are subscribed to the Google Groups "LaTeX for Lawyers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to latex-for-lawyers+unsubscribe@googlegroups.com.
To post to this group, send email to latex-for-lawyers@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zeke Vermillion]

Flora, thanks for the response and your generous offer to contribute.

If we are to build from scratch, I would suggest we start with a minimal spec (especially if I have to write it!). I would take an opinionated position on style rather than anticipating multiple styles. For example, there is an English habit of numbering nested lists like 1.2.3.4 which is much better and easier to implement than the ad hoc US approach I(a)(i)(1)(A), which I can only surmise is an inauthentic homage to the Romans. I wouldn't bother providing a macro for US-style indented lists. I'm sure there are people on this list who have better taste and stronger opinions about style than I do, and I would gladly defer to their taste if they want to intercede. 

The most comprehensive XML effort I found is by the OASIS LegalXML working group. It appears very ambitious, and probably way more powerful than I could really use without running amok. But it's useful in the same way that the example of Xanadu may have been of interest to the original author of html. 

I will put some thought into a rough spec and update in this space. 

Zeke

PS The kayak was a rental on my honeymoon on Vancouver Island. At home I have a 12' tub designed for fishing, which unfortunately remains in my garage more of the time than it should.

[Flora Vern]

Dear Zeke,

People often focus about the layout / design first, but it is in fact one of the last things we code. List numbering, for instance, is trivial (check language via babel and apply the corresponding counter formatting, set up a default).

The stuff we need in the specs is more about : how many named / signed parties can there be (probably an infinity), how many levels of headings and what they are sued for, how many levels of (sub-)clauses and how they nest, do we need standard clauses books (probably yes) and how to implement them (how do we shorthand the clauses, do we store them in a separate file, with which extension), how do we deal with attachments and how many kinds of them can there be (for list generation). That kind of stuff. And the wording for every macro. Do we use "partyname" or something else, etc. in the internal settings. That's the hardest point. I don't know the english names of all possible things (esp. for court files, contracts are easier).

Basically, one of the best possible document would be a set of fill-in-the-blanks Word templates used in law firms. Complex ones with every possible thing you will need.

Best,

Flora

[Zeke Vermillion]

Aha, that is helpful, thank you! Is there another specification document that you would recommend as an exemplar? 

You received this message because you are subscribed to a topic in the Google Groups "LaTeX for Lawyers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/latex-for-lawyers/_OeJVBJX-P4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to latex-for-lawyers+unsubscribe@googlegroups.com.

[Flora Vern]

Sorry, I don't have a specific one in mind. From a developer's point of view the main question is what should it do and how. LaTeX can automate most things that relate to formatting, so basically whenever you need to use a mouse / keyboard to do anything other than type your contract, there is probably something to be done with LaTeX. If you set something in bold or italics, if you set up lists, if you look up a previous list item / document number / name / date / reference, if you insert a table, etc. Most of those things can have a handy macro to automate them. Indeed, you can suggest the formatting you are using :).

[Zeke Vermillion]

OK, I need to put some thought into this if it's going to be worthwhile for you to invest your time. Looking around for a non-confidential document set as an example of contemporary contract drafting, I think the NVCA forms are useful. They are an abomination compared to Series Seed, but are useful to show the possible range of dependencies between different contracts and instruments in a non-trivial, multi-stage deal. If someone has already thought about how to turn multi-contract, multi-stage deals into a spec, I would love to hear it. Otherwise I will attempt to do that...

[Flora Vern]

Dear Zeke,

These model documents are indeed useful. We need to determine things such as whether to use glossaries for definitions, etc. If you are going to spend time on a spec, there is indeed to need to make it into a formal document. It is more important to take a thorough look at everything we need in terms of functionalities. You can email them to me a few at a time and we'll see how things go as the prototype evolves with your feedback. Maybe we can start with basic functionalities and grow more complex as we go along, too.

[Zeke Vermillion]

I have a rough draft of the spec ready. Anyone who is interested can view and edit it via the below share link. The intent is for the resulting specification to be free for anyone to use and modify for any purpose, but contributions are taken as-is. Flora or anyone else who wants to build something based on the spec can decide how she wishes to license her work. It would be great if it is permissively licensed of course!

https://docs.google.com/document/d/1nR4HNa4nqudmfr4NxqheDrcHNhpINZuDvjpeD8gpoW8/edit?usp=sharing

Hopefully this will be enough to overcome the initial static friction of the project. I'm sure this needs a lot of polishing before you would want to build a template around it. 

[Flora Vern]

Dear Zeke,

Thank you for your quick response on this point. It looks like a start… but you clearly have in mind a markup language which LaTeX is not. We are never going to be able to just mark things up and wait for compilation to make them beautiful.

In LaTeX I need to define a macro such as \client which outputs the client's name (user defined, of course). So, the difficult part for me is: how to I name the various people we have to name (client, other guy, various other guys). We should probably opt for a user-defined macro name. I assume the best possible way of implementing it would be something like \party{Company 1} or \party{Dude} where the word between braces is user defined with full name (Company X Y Z), short name (The Company) and personal key for it (Company 1).

So, what we need is a list of all of the things that need such macros and an example use of them. When and how should we expand the raw data.

The same goes with all of the placeholders, which need specific macros for defining them. I can output the date, and I can convert numbers into various date formats, but I need to create a macro called \date{2016-08-19} that does it.

What do we need to include in the outline, index and closing checklist? What is the format of a schedule (if not text)? What about the exhibit?

I don't understand what you are saying about tables. What are they and what are the tags in them? What is the class-thing?

About the glossaries, if I understand correctly, you suggest having a glossary printed at some point in the main document, and referring to it in any sub-contract that may or may not be read separately. This sounds fine.

Cross references are possible too with LaTeX, so no problem there although we need to specify a labelling (tagging, for you) policy. I would suggest something like: \ref{article:1.2.4} unless the person has specifically assigned a label to that article such as \ref{LiabilityWaiver}. This way, there is automatic labelling, but you can always override it with a more robust system by adding you own labels. And we may want to also automate it within the clause library.

Once we have that, we can create a template like the one you suggest, in which we will fill a .tex document with dummy metadata and predefined sections for the stuff most contracts will require. But as you can see, this is the final and easiest step in the process.

Thanks again for your input. Will look more into it when I have time and try to provide you with the sample I have already coded (I need to translate it from French though).

Best wishes,

--

[Zeke Vermillion]

It seems the spec I wrote does not describe a template at all. I came here looking for a template to reference, but have gone a bit further afield.

I had in mind a shorthand, intuitive to lawyers, that would allow me to build all the docs for a corporate transaction within LaTeX. Perhaps that is more of a new lightweight markup language, that would be a shorthand for producing a proper tex file that would make use of our macros?

I will think more about how to define the project, and see if we can get to a spec that is worth implementing. If we can define the problem properly, and it needs LaTeX macros, I will be happy to get into an exhaustive list. First, I will try to clarify what I have written to date to describe the larger need.

Z

You received this message because you are subscribed to a topic in the Google Groups "LaTeX for Lawyers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/latex-for-lawyers/_OeJVBJX-P4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to latex-for-lawyers+unsubscribe@googlegroups.com.

[Flora Vern]

Sure! I will try to send you a version of my own contract template when I return from my holiday (don't have it with me at the moment). We can do templates, but they won't look like a markup language. This isn't a huge backdrop, if you look at LaTeX's  capabilities, but we do have to frame things in a consistent way so that the macros are easy to remember for the end user. This is the biggest problem. I believe it is possible to create something really straightforward, but real life law practice is needed in order to craft the proper macros. We need to find which macros to create and how to create them so they become part of a handy, integrated workflow. I just don't have enough law firm experience for that.

[Scott Young]

Dear Zeke,

Looking at your "LaTeX Contracts Template", it sounds like we are interested in the same problem – bringing the benefits of free software, plain text source code, version control and high-quality typesetting to legal documents.

Unfortunately, after looking at this problem for a few years, I have reached the conclusion that a solution that is accessible to the average lawyer is a long way off!

I have developed a system which uses Pandoc to compile documents written in Markdown to PDFs formatted using a custom LaTeX template. It sounds like this would satisfy a few of your design goals, so I've just written a README page and uploaded my work to Github.

• Example input Markdown
• Example output PDF

It is not a very user-friendly system: you must compile your documents on the command line, and if you want to depart from the template I've created, you'll need a bit of LaTeX, Pandoc and potentially even Haskell knowledge.

Despite investing considerable time into this problem, I still do most of my legal writing in Microsoft Word, because the cognitive overhead of a non-WYSIWYG editor slows me down too much to use this system for composition. However, it would be possible (with a lot of work) to create a very nice web application which makes it easy for technical authors across all disciplines to collaborate using Markdown, LaTeX and Git without needing to understand how each of those technologies work behind the scenes.

Authorea seems to be an attempt at this, although it may use different technology under the hood. I am hopeful that a free software alternative will emerge one day, perhaps targeting HTML rather than LaTeX. Pollen might be a suitable backend, although I am interested in a system which can be extended to produce any kind of document, so I am more optimistic about the flexibility of Pandoc and Haskell. Unfortunately, I think there are a few years of work to be done here and I don't have the time to do it!

Kind regards,

Scott

[Zeke Vermillion]

Wow, thank you Scott! It is great to have this. It's amazing that I started down the same track without being aware of your work. I think the premise is a good one, and I feel more confident about that now that I know you went pretty far down the same road (even if eventually hit a roadblock). I understand that it is very, very difficult to break out of the current workflow, and there is a low likelihood of commercial success. Still, I am only one guy and my personal requirements for success are quite low! 

[Flora Vern]

In any event, LaTeX is mostly using free software licences for distribution purposes (so people can get automatic updates), so no one expects to make money out of the code. In my opinion, the only way anyone could reasonably market a LaTeX product is by selling related services (installation, tutoring, problem solving, etc.). Any such project will first and foremost be free for anyone to use and improve.

Scott's sample could be a good starting point for a spec. We just need to know which (generic) information goes in which place, what the macro should do and what type of information we need to store / retrieve from it. Then we can create simple end-user macros that just pack a lot of information together, like \maketitle (which inserts all of the header / preamble) or \makesignature (all of the signature blocks).

[Zeke Vermillion]

I was kind of joking about commercial success -- I have no commercial plans for this. Maybe I should just start with the list of macros, as a prototype, and then worry about how to make them accessible later...

[Zeke Vermillion]

Hi Flora, Scott, LfL list -- 

I wanted to follow up, if belatedly. First thank you Flora and Scott for humoring me and providing very interesting info and offers of assistance in this quixotic pursuit. When I initially posted to the list, I had just discovered LaTeX and was very excited about its capabilities. After some research and experimentation, I am still a rank amateur here but have started to form a healthy appreciation for the complexity of the project (using LaTeX within the contract drafting / negotiation workflow). 

I also have found that the existing packages for LaTeX are probably more than sufficient for my purposes. Or at least, any imperfection in already available macros is the least of my worries. The much larger task is in figuring out how to make the drafting and typesetting workflow expedient for practitioners. I think a markup interpreter may be the answer, but I need to go to my cave and ruminate on this for some time, maybe a year or so. 

If anyone else is further along on this path, I would love to talk more. However, I don't think I know enough yet to make productive use of anyone else's time on this effort. 

Thanks

Zeke

[Robert Semenoff]

If you are into quixotic, I would recommend "markdown" as part of your google search terms. Similar to markup but simpler for writing content.

[Zeke Vermillion]

Yes, that's exactly what I was grasping for...

[Flora Vern]

Markdown is one way to go, indeed. As for the workflow / process, I probably won’t have time before yet another year, but I will try to look into it eventually. Still if someone comes up with some ideas about what kind of workflow lawyers could want, it would be good to share them or create some kind of online list.

To unsubscribe from this group and stop receiving emails from it, send an email to latex-for-lawy...@googlegroups.com.
To post to this group, send email to latex-fo...@googlegroups.com.