> Why are legal documents recorded in a format that requires expensive software to access?

Because lawyers can afford it, and don't really feel like expending effort evaluating software alternatives instead of just doing their work. And because of legacy/network effects. And because no one has pitched an alternative right for that audience.

> Because lawyers can afford it

Lawyers can afford free software too.

There's a reason that there is an “and” followed by a bunch of other things after the bit you quoted.

I have nothing to say about those points. I don't know enough to support or reject them.

It's clear what was meant was "cost is no object, so it's not an issue" - law firms probably pay more per-employee for things like travel expenses or coffee each year than for MS Office licenses.

I have seen that MS Office suite has become a hammer used to drive many non-nails in various businesses, and would like to see people using more open standards. But I totally understand that for many use cases it's good enough and that people consider the cost to be not particularly significant

edit: misplaced reply, moved to parent (too late to delete)

Ehhh ok? That’s kinda what I said

An individual business license of MS office 365 costs about 10 dollars a month per user. So even at minimum wage fully loaded costs this is approximately an hour. It's more like a minute or two for a lawyer.

Do you think having access to a tool with the least communication friction saves you 2 minutes/month of your lawyers time? 30 min of your junior marketing person? This isn't a hard call to make usually.

I'm more concerned about the people who are subject to the laws being written and (imo) deserve to be able to read them for free.

As for lawyers, just because they can afford to use expensive software doesn't mean they should. I can afford to write software in Word, but I don't plan to try that any time soon.

Also, I think people seriously overstate how "easy" it is to use Word. I have spent litteral days of my life in classes that taught me how to use Word. I have spent hours relearning MS Office interfaces as they've changed over the years. I'm pretty sure I picked up GitHub-flavored Markdown in less than 15 minutes.

Your first point is valid but quite separable, I think access is an important issue.

My point about the cost is that the network effects of the tool here are more important than the tool itself. You might be able to have a better local workflow using other tools, but if everyone you collaborate/work with doesn't use them then the cost of communication is far higher than any savings.

Realistically, legal work isn't much like coding. Although lawyers do spend time editing documents that isn't where the real time is. For that reason I'm not convinced that changing to a putative VCS workflow would have enough efficiency impact to pay for the training etc. except on a very long term. This sort of thing makes it very difficult to win out against network effects.

This is much the same reason that excel is used for a lot of things where better tools exist. The combination of network effects and having better things to do than learn a new approach and toolchain are hard to shift.

> Why are legal documents recorded in a format that requires expensive software to access?

Because the cost of the software is trivial compared to the cost of incompatibility or friction in communication.

Not for the citizens who just want to read the laws they're expected to follow.

Whose final form is probably PDF anyway. Even if it were .docx, there are lots of free softwares that can read or translate those.

So your real problem here is with the access to said laws, which is not a software problem.

Plain text wouldn't allow for annotations, TOC, references, etc. These get ignored more often than not but they're still requirements and some do use them properly. Something like latex would be better, but apparently it's too much to expect these highly educated lawyers to learn some basic markup.

I'd bet a tool like lyx (https://www.lyx.org/Screenshots) would go along way to being a better solution. It's a great document writer (as opposed to a word processor) and apparently has some VCS support (although I haven't tried this) and diff viewing and is a lot more reliable for annotations and all that stuff than word.

I've done some legal automation work before, it would have been so much easier (and get better results) to have a plaintext format we could manipulate with shell scripts than working with docx and word.

    - But doesn't plain text suck for difs?
    + But doesn't plain text suck for diffs?

    - Especially when you have a really long, multi-line
    - paragraph that has bmore than one change? And if we
    - relied on word wrap, then the scope of change would
    - be the paragraph and all hope is lost. At least 
    - this way we might eventually regain some 
    + Especially when you have an exceptionally long,
    + multi-line paragraph that has more than one change?
    + But if we relied on word wrap, then the scope of
    + change would be the paragraph and all hope is lost.
    + At least this way we might eventually regain some
      equivalency by chance and it's clear that nothing
      after that point has changed.

Git is great, but it's designed for code. Legal documents are probably structured more like code than any other prose with clear identified chunks and frequently breaking out into lists, but it's not the same thing.

(For clarity, I think probably a sentence-by-sentence diff would work well. But then it's not plain text; you're relying on some processor to collect sentences into paragraphs.)

Don't use plaintext, use LaTeX. Since paragraphs are separated by an empty line, you can have each sentence on a separate in a paragraph on a separate line and have it still formatted as a paragraph in the final document. This allows for better diffs. Here is an example:

https://github.com/dart-lang/language/blob/master/specificat...

> Don't use plaintext, use LaTeX

Markdown or Asciidoc has the same benefit as far as paragraphs.

Markdown doesn't address table of contents or references which were mentioned above.

Asciidoc does, and there are TOC tools for markdown, though they are add-ons to markdown processors.

The diff algorithm/display is orthogonal to the data format; for example, I use the --color-words option to the git tools to use a word-oriented diff everywhere. I've even seen plugins floating around online for visual image diffs in git!

But again, all those tools are built for developers, and especially the ones used by git for internal purposes like for conflict resolution make some strong assumptions that don't hold for prose.