placeholder

/dev/lawyer

>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

Flat Formsplain language should come in plain pieces

Some colleagues and I have enjoyed passing around this link for the past week. The author reproduces what they believe might be the first commercial software copyright license, from IBM. Hat tip to this piece from the American Institute of Graphic Artists about ethical licensing of fonts for bringing to my attention.

Having skimmed through Big Blue’s old form, a number of things struck me. The first was the simplicity of its structure. There aren’t any section numbers, enumerated lists, or nested, outline-style complexities. Just three and a half pages of italicized headings followed by paragraphs and some lists. Some terms are defined, but not in the way American lawyers are used to seeing now (hereinafter, the “Usual Way”). More than anything, the form resembles routine if somewhat stuffy communication between actual human business people unmolested by legal training.

From one point of view, this comes across incredibly quaint. Few conventions of legal drafting make appearance. It looks, feels, and even reads a lot more like everyday, unspecialized writing.

On the other hand, my colleagues and I have found ourselves working our way back toward this style. We can see it in the changes to our own forms, over time, like my Doormat privacy policy. And we can see it in some projects we’ve taken together, like Blue Oak and PolyForm.

So is IBM’s ancient terms format the past or the future?

Resolved: Legal terms should be written, structured, and presented as flat lists of headings, paragraphs, and lists. Sections should not contain sections.

Of, if you prefer: Plain language alone does not a plain document make. Plain structure is just as important.

In Favor

Flat forms are easier to read. And not just for not-a-lawyers. Complex structure isn’t just intimidating, it is also more complex.

Nested sections force readers to track not only the last heading they’ve seen, but a list of headings they’ve seen. To know where you are as you read, you can’t just look at the nearest heading above. You can have to remember that the heading is within another heading, and potentially a few of them.

This is so even with the benefit of formatting hints. Indentation can set inner sections further from the margin than outer sections. But it’s very hard to tell how far something’s indented just looking at the page without the use of a ruler. Compound numbering schemes, which produce numbers like 5(a)(1) or 7.3.1, can help gauge depth. But if you’re in, say, section 5(a)(1), that number does not tell you what section 5(a) is called, or what section 5 is. The part about my side’s obligations, or the other side’s? You have to try and guess from the content in front of you, pageful or screenful.

Flat forms are also easier to write, and not just in word processors like Microsoft Word, but in e-mails, HTML pages, Markdown files, and everywhere people type. All lawyers have had knock-down, drag-out bouts with automatic numbering. We’ve all screwed up margins and got cross-references to deeply nested sections wrong. We could not be stepping into so many holes, instead of crawling our way out of them all the time. And our results would be easier to read.

Against

Nested sections afford some benefits. They make terms look technical, for example, and that can’t hurt when setting our rates. But when it comes down it, the only really worthy virtue I see is that nested sections help us group related sections together and refer to them as a whole, without ambiguity.

Sometimes this is done unnecessarily, as when six sections get shoved under a “Confidentiality” heading so the drafter can refer to them later in exemptions from a limit of liability. They could just as easily say “confidentiality obligations under this agreement”, and that would be just as clear. But in other cases, like calling out vendor terms that a customer must flow down, it makes more sense. There’s no pithy plain-terms description of the terms the drafter has in mind. They need to grouped semantically, and that’s cleaner and easier to do by putting them under one heading than by listing out sections, as we sometimes see in survival provisions.

There are only trade-offs, and there is still one here. There are definitely use cases out there where the readability hit is negligible, or readability is even improved.

Verdict

I’m not sure yet. I have to try. But I will definitely be revising some forms going forward, and looking for chances to pound them out flat. Because the reasons for nesting sections make sense to me, but they’re also rather narrow. And at least in my shop, when drafter convenience and reader comfort collide—my interest with my client’s, most of the time—the reader wins.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history