This is absolutely the same with science.

Why can't they just use normal English language for contracts? How did it get to be this way?

For everyone commenting "laypeople aren't the intended audience", this monstrosity was a recent Texas constitutional ballot proposal, i.e. all voters in the state were asked to vote on it:

> The constitutional amendment authorizing the legislature to provide for the reduction of the amount of a limitation on the total amount of ad valorem taxes that may be imposed for general elementary and secondary public school purposes on the residence homestead of a person who is elderly or disabled to reflect any statutory reduction from the preceding tax year in the maximum compressed rate of the maintenance and operations taxes imposed for those purposes on the homestead.

I have an Ivy League education and I still could hardly understand it, and I still think some of the language is ambiguous (i.e. I think "the reduction of the amount of a limitation on the total amount" can be interpreted both ways).

https://www.dallasnews.com/news/watchdog/2022/03/25/the-lang...

I've been a CTO at companies in various bits of the Anglosphere, and signed contracts in all of the bits (and some other places).

I'm also married to an Anglosphere lawyer (which gives me lots more exposure than I might have guessed to the idiosyncrasies of the profession).

In my experience, I very much agree with the headline (and abstract) here, but would emphasise that the US is the worst for archaic language, creating a worse barrier to entry. Most other countries in the Anglosphere have been through a "plain english" language push in both contract & legislation, while the US has stuck to "this language is proven through precedent" more stubbornly than anywhere else. This seems to be particularly prevalent in IP law, although that might be my tech bias showing.

I would very much argue against those (even in this thread), that say that the lay-person isn't the intended audience for lots of contracts, particularly for T&Cs where they are often written by a contracts lawyer, for a contracts lawyer or judge, but should ABSOLUTELY be written for the lay-person to understand.

Anyway, I think the legal profession can & should do better.

I think this "poor writing", as in hard to understand writing with long backreferences is due to the same reasons as why many academics are terrible at explaining things, as well as why source code is hard to read.

I should know, others usually like pointing out how terrible I am at explaining things. And I think I know why.

When I make a naive attempt at describing a complex, interconnected concept, such as a piece of math, or a program that does a thing I start with a mental picture - a graph of interconnected concepts. Then I try to describe the picture - the same one would describe a painting. I describe visible part separately, often to great detail, then I try to describe the links and interconnections between parts.

This sort of 'accurate' descriptive style naturally leads to huge backreferences, and people usually have a ton of trouble following along.

However I think there's a way of getting your point across - one basically needs to reproduce the thought process of how one would come up with the given model given the real world constraints, illustrating the issue and its proposed solution with examples. It is often said that people are much better at deriving the rules from a few examples than the other way around.

However this sort of descriptive style takes both a lot of effort, and usually is less precise, which often is not acceptable, such as in the case of contracts or computer code.

I am a lawyer who works with but doesn't do a MASSIVE amount of contract writing like some.

I don't think "poor writing" is the right phrasing here, which implies ignorance or ineptitude.

I think the reason contracts aren't readable to laypeople is because laypeople aren't the intended audience. We all know no one reads these, so we write them to future lawyers and courts who might want to get our clients in trouble. We try to create loopholes for our future selves.

Lawyer and contract-drafting teacher here. The biggest problem with unreadable contracts is that we have too many L.O.A.D.s: Lazy Or Arrogant Drafters. (You can decide for yourself: L.O.A.D. of what?) There's a relevant Dilbert cartoon: [0]

To simplify contract language, the biggest bang for the buck comes from SSSP: Short, Single-Subject Paragraphs, which are much easier to read; to review and revise during contract negotiations; and to reuse in other contracts.

(It's not unlike modularity and orthogonality in software.)

For more ranting on that subject — with some pathological before-and-after examples — see my online course materials (this version isn't pretty; I'm almost done refactoring it). [1]

[0] https://dilbert.com/strip/2008-08-28

[1] https://toedtclassnotes.site44.com/Notes-on-Contract-Draftin...

Same with academic papers. Most of my efforts go into dealing with constant loss of attention that happens when I have to look up unnecessarily complex words or improperly defined symbols and variable names. I feel stupid until I realize that the paper is actually about a very simple concept. It doesn't have to be this hard to read.

The plausible explanation for "center-embedded clauses"(CAC) is this: whenever there is an issue of ambiguity about a concept in the main clause, CAC will clarify that ambiguity. If one makes CAC as an independent clause, this independent clause can clarify, or reduce ambiguity, in all clauses of that paragraph or the whole contract (all paragraphs). In some unforeseen circumstances, making CACs as independent clauses may cause problems.

I see CACs as footnotes, directly attached to the clause.

> (b) suggest such processing difficulties result largely from working-memory limitations imposed by long-distance syntactic dependencies (i.e., poor writing) as opposed to a mere lack of specialized legal knowledge;

It seems like a misrepresentation to call “long-distance syntactic dependencies” in a legal document the same thing as poor writing when comparing to other genres of written English including those that are written for pleasure. When exploring law the question an individual usually has is “If I do X, does Y happen?”. But legal frameworks don’t cover individual situations, they paint broad strokes over the human experience.

Shameless plug here but my startup's mission is to solve this problem. It seems wrong to me that in this day and age you have to hire someone to be able to read a legal document or TOS: https://layman.ai/

TBF those structures do exist for a reason. Just take the “Total Compensation” as an example. Breaking it out as shown in the paper does work, but now some language is repeated; in an edit (and most contracts are edited rather than being created de novo) one of the duplicated clauses could be edited and the other overlooked, especially if they become separated by successive edits.

I’m sure there are obscurantist

IANAL, but I AM a patent agent, which means I passed the Patent Bar. So I haven't dealt in contracts, but a lot of the same considerations apply to patent claims.

There is some claim language which is absolutely not required and any lawyer who uses it is just showing off. The article mentioned "aforesaid" which is a prime example in contracts (in patent claims, it's just "said").

For example:

A TCP packet, comprising TCP header and body, where said header comprises etc. etc.

-- or --

A TCP packet, comprising TCP header and body, where the header comprises etc. etc.

The second is absolutely as valid as the first. "The" is just as good as "said."

Another example:

What is claimed and desired to be secured by US Letters Patent, is

-- or --

I claim

The first one is just pretentious. It adds nothing.

Maybe you don't like "comprising"? Well, that one is specialized language.

A chair, comprising four legs, a seat, and a back

-- or --

A chair, consisting of four legs, a seat, and a back

The second is not just as good as the first. "Comprising" allows for the chair to have arms, while "consisting of" does not.

A lot of this is driven by inertia. When a lawyer goes to write a contract, she'll typically start with a prior contract or form agreement. This will either be used as a template, or large chunks will be borrowed and modified as needed. In either case, the lawyer is unlikely to reword a bunch of provisions in an attempt to improve readability. It's like the legal version of Chesterton's Fence — if you don't know why a particular clause is phrased a particular way, you leave it as-is. Your client/partner might ding you if you include a boilerplate provision you shouldn't have, but you'd probably get in more trouble if you affirmatively reworded something and broke a cross-reference or other logical linkage that was supposed to remain in place.

As a result, language that was written a long time ago is still circulating in modern agreements. Note: I'm not defending any of this. As a lawer-turned-founder, I try to keep my agreements as short as possible!

My experience working as a patent examiner agrees fully with the title: legal texts tend to be hard mostly because they're poorly written. (DOC lawyers make me add this: This post is just my personal opinion, not that of the USPTO, DOC, US govt., etc.)

I've been trained in patent legal terminology, which isn't that bad. Patent documents are still frequently difficult to understand. I have one application on my docket where I'm going to have to rewrite one of the claims to understand what it's saying, and no, that shouldn't be necessary... And the situation with patent documents is worse than the situation described in the abstract as many attorneys write vaguely.

The argument that "lawyers are the intended audience" isn't legally sound either, as under 35 USC 112(a), patents are supposed to "enable a person skilled in the art [...] to make and use the [invention]". If an attorney argues that patents aren't supposed to be understood by non-attorneys, they're wrong, full stop.

Unfortunately, I'm not really allowed to do 112(a) enablement rejections. I'd do those sorts of rejections frequently if I could, but I think I can count the number of times I've done 112(a) enablement rejections on one hand. The law in other countries seems more strict than in the US. I'm told that Japan in particular takes enablement a lot more seriously than the US does.

This is not just a legal thing. In the industry it's not uncommon to work with some partner or customer who is deliberately obscure about specs / requirements so they can always find a way to be right and demand more free goodies.

At my job I have to deal with the structural design part of the building code for US and Canada (ei. calculating loads on structure). Part of my job is to find the differences in each new version to see if we need to implement anything new in our software.

For seismic, the Canadian code is easy enough to understand that teachers use it in college instead of manuals or notes. To calculates something (eg. a specific wind load or seismic load), you just read the section from top to bottom and follow the recipe. Things are actually placed in the order that an engineer would use them.

With the US code, you have to deal with triple negations and 80% of the usefully information is presented as references to other sections. It's really not fun trying to understand it when a single sentence will link you to 8 paragraphs, 6 of which are in a completely different chapters or sub-chapters. And as you can imagine, these 8 paragraphs will also have their own references to other part of the code. It's a complete mess that is impossible to follow unless you write your own summary and/or take screenshots and rearrange them in order.

You end up with a situation where even experienced engineers can't understand it and have to rely on notes from colleagues, college textbooks, calculation examples, or they just blindly follow the design software they bought.

Working the support line for a high end structural analysis and design software has really opened my as to how incompetent and lazy a lot of the senior engineer from highly reputable firm can be. It would be a lot safer for the public if the "easy to understand" version of the code came from those who wrote the original. I suspect it's the same in other professions too.

Here's a good example of 'center-embedded clauses' making a paragraph difficult to interpret - it's from the revamped USA-Canada-Mexico trade deal, specifically a side agreement between the USA and Canada on energy-related trade:

> "Each Party shall endeavor to ensure that energy-related activities that do not result in a facility exceeding its previously authorized capacity and that are limited to performing maintenance work on, or ensuring the safety of, existing cross-border infrastructure may be undertaken under the initial authorization and shall not require a new authorization."

Unpacking all this is rather difficult. The intent appears to be ensuring that energy-related activities should not require periodic re-authorization by a regulatory body after an initial authorization is granted. An example would certainly help - a cross-border power grid interconnect, say.

The embedded clauses are of two different kinds. If our grid interconnect doubles its capacity, this would be a violation of the first (restrictive) clause, and would thus require a new round of authorization. Under the second (permissive) clause, one can shut down the grid interconnect for safety or maintenance reasons. Taking the grid interconnect offline to restrict supply and jack up prices would thus be a violation, although one could monkey around with this (see Russia shutting down Nordstream to Europe for 'maintenance' at present).

That's just one paragraph, the document is hundreds of pages of this kind of thing.

I lay a fair bit of fault also at an almost visual/UI level of how we write laws.

If you look at our law books, they are almost all words/text. Yet in a lot of areas of regulation (or to use a simple example, just think of when a map is needed), graphical explanations are rarely used when they would clarify immensely.

Lawyers / politicians are by default writing in long, wordy, text to try to lay out complicated systems. This is often not ideal, when a diagram or schematic of what you mean to have happen would be more clear.

It also produces an effect where laws tend to just bolt on more text, and have little contextualization of what already exists or what is being modified. I seriously believe our hundred books of CFR/laws are a significant result of this.

If people were forced to summarize how a proposed law interacts with current laws, etc. I think there would be more hesitation and better thought about what is being enacted.

This is the most painfully obvious headline I have ever read. I wonder when they'll realize that the writing is intentionally poor in order to prevent comprehension.

Congress should pass a law requiring every software end user agreement to be written at a sixth grade level and to be no more than 800 words in length. If it's a federal law, then companies will just figure out how to do it.

This is 100% the case.

I've been a consultant reading legal documents hammered out between the senior partners and VPs of the supplier - the language is so straightforward a child could understand what each party is getting.

This is of cours entirely the point.

Regular people are not meant to understand what it says and means.

If it was spelled out in plain simple English for everyone to read a lot more people would object to the terms and feel upset.

When it is obfuscated nearly to the point of encryption no normal person will be able to, or at least spend the time it would take to decrypt it.

This seems like a job where AI could be utilized to read legal language and output a plan English interpretation.

It also has to do with job security. You need lawyers to read them, because other lawyers write them.