4 ms·

English isn't really a better exchange format for licenses than legalese. Arguably it's even worse due to the lossy conversion. What we really need is a common

by moe 11y ago

English isn't really a better exchange format for licenses than legalese. Arguably it's even worse due to the lossy conversion. What we really need is a common legal markup language[1]. Sadly, the few efforts that I've heard about seem to be stagnating. [1] https://en.wikipedia.org/wiki/Legal_XML https://en.wikipedia.org/wiki/Legal_XML

jzwinck 11y ago
The problem with legal markup is the same as with FIX, the financial data protocol (which is widely used). Lawyers (finance people) will never stop innovating (increasing complexity), and they will not be one moment delayed by a protocol which falls short of their aspirations for sophistication (bamboozling). Therefore, the only adoptable protocols are mere transports. They might rigidly specify some commonly used things like property titles (stock orders) but foreseeing unusual or unknown requirements, such protocols will include custom extension features (user defined fields). The end result is a protocol which is sort of useful but still does not suffice for the development of generic tooling. An example from FIX is the field which tells whether an order added or removed liquidity. The standard didn't have such a field, so now every exchange has its own different one.
- dogweather 11y ago
  Naive first thought: it seems like an active standards body is required. Like for HTML. That took care of e.g. The CENTER tag.
  - jzwinck 11y ago
    There is one. It cannot possibly move as fast as all the individual actors. Standards bodies can provide high quality at slow pace. Participants here want fast pace and only adequate quality.
- moe 11y ago
  I don't really see that as a problem, that's how all popular protocols evolve. If all exchanges have invented a liquidity-field, then there's a good chance the next version of FIX will standardize it, no? Imho the legal system is very much ripe for digitalization. Both on the low-end (where it pretty much consists of overhead), and even more so on the high-end, where the complexity of legal contracts between companies or states has long exceeded what any team of lawyers (much less a mere mortal) can comprehend.
  - jzwinck 11y ago
    The next version of FIX can try, but everyone stopped upgrading FIX versions years ago. Also, once you standardize the liquidity field, you need to think about its values. These expand continuously...it used to be two or three values, now some systems use a dozen or more. Basically, if you want a protocol for legal documents, you may as well use an existing one, such as PDF, XLS, TeX, etc. Trying to embed more domain knowledge in the protocol will never work at a highly generalized level. It would be like asking HTTP to standardize e-commerce.
    - moe 11y ago
      Well, let's not forget we're talking about lawyers here, who already work with a versioned single source of truth (The Law). All I'm asking is that we upgrade their tooling and process. Your outlook for the abstraction potential seems overly pessimistic. Most of Law boils down to a cascade of intermingled conditionals, nothing a computer couldn't handle. Of course a bit of human intervention will always be required, for value judgements and the "hard questions". However, in my (limited) experience with lawyers, very little of the time and money that a lawsuit consumes goes into the actual decision making. The overwhelming majority is wasted on process and formalities.
      - reagency 11y ago
        There is no single source of truth. Every court case creates a new version of kaw, called case law.
        moe 11y ago
        Well, the body of this case law (and all other laws) is what I refer to as "single source of truth". Yes, "single source" is very much an euphemism. In practice it's far from a single source, but rather a poorly synchronized mess. Which is exactly what I'm proposing to fix. If we were to wrap it into a github-style model then cases could be represented as branches. Case-law would evolve in the form of patches and pull-requests.
  - 11y ago

by moe 11y ago

jzwinck 11y ago

The problem with legal markup is the same as with FIX, the financial data protocol (which is widely used). Lawyers (finance people) will never stop innovating (increasing complexity), and they will not be one moment delayed by a protocol which falls short of their aspirations for sophistication (bamboozling). Therefore, the only adoptable protocols are mere transports. They might rigidly specify some commonly used things like property titles (stock orders) but foreseeing unusual or unknown requirements, such protocols will include custom extension features (user defined fields). The end result is a protocol which is sort of useful but still does not suffice for the development of generic tooling. An example from FIX is the field which tells whether an order added or removed liquidity. The standard didn't have such a field, so now every exchange has its own different one.

dogweather 11y ago
Naive first thought: it seems like an active standards body is required. Like for HTML. That took care of e.g. The CENTER tag.
- jzwinck 11y ago
  There is one. It cannot possibly move as fast as all the individual actors. Standards bodies can provide high quality at slow pace. Participants here want fast pace and only adequate quality.
moe 11y ago
I don't really see that as a problem, that's how all popular protocols evolve. If all exchanges have invented a liquidity-field, then there's a good chance the next version of FIX will standardize it, no? Imho the legal system is very much ripe for digitalization. Both on the low-end (where it pretty much consists of overhead), and even more so on the high-end, where the complexity of legal contracts between companies or states has long exceeded what any team of lawyers (much less a mere mortal) can comprehend.
- jzwinck 11y ago
  The next version of FIX can try, but everyone stopped upgrading FIX versions years ago. Also, once you standardize the liquidity field, you need to think about its values. These expand continuously...it used to be two or three values, now some systems use a dozen or more. Basically, if you want a protocol for legal documents, you may as well use an existing one, such as PDF, XLS, TeX, etc. Trying to embed more domain knowledge in the protocol will never work at a highly generalized level. It would be like asking HTTP to standardize e-commerce.
  - moe 11y ago
    Well, let's not forget we're talking about lawyers here, who already work with a versioned single source of truth (The Law). All I'm asking is that we upgrade their tooling and process. Your outlook for the abstraction potential seems overly pessimistic. Most of Law boils down to a cascade of intermingled conditionals, nothing a computer couldn't handle. Of course a bit of human intervention will always be required, for value judgements and the "hard questions". However, in my (limited) experience with lawyers, very little of the time and money that a lawsuit consumes goes into the actual decision making. The overwhelming majority is wasted on process and formalities.
    - reagency 11y ago
      There is no single source of truth. Every court case creates a new version of kaw, called case law.
      - moe 11y ago
        Well, the body of this case law (and all other laws) is what I refer to as "single source of truth". Yes, "single source" is very much an euphemism. In practice it's far from a single source, but rather a poorly synchronized mess. Which is exactly what I'm proposing to fix. If we were to wrap it into a github-style model then cases could be represented as branches. Case-law would evolve in the form of patches and pull-requests.
- 11y ago