Here I’ll lay-out my proposal for making human-friendly contracts, without sacrificing basic nuance.
This is a WIP, so please don’t assume a finished state. Suggestions are welcome! (warning: I haven’t chosen an open license, yet).
You know what the following have in common:
But I’ll outline them anyways, for emphasis:
The year is almost 2025 and humanity hasn’t fixed this simple issue for decades (millennia, if we’re being unfair).
The following is a list of resources to which I feel grateful:
As a “layperson”, you might wonder:
why can’t orgs and corps simply say “BTW, our terms are the same as Google’s, except for this part” Or any sort of summary?
The whole point of “legally-valid” contracts is that there should be no ambiguity (this is why legalese looks like a programming language), as any omitted detail could become a loop-hole, which is equivalent to a software vulnerability. That’s the reason why there’s so much legalese, because lawyers need to cover everything (every possible scenario in the past, present, and future), to protect the org from “abusive users” exploiting the holes.
This goes both ways: A “legal bug” could be so unintentionally strict, that 100% of the target demographic would be forbidden from using the service.
Even if they could refer to an existing contract in a “rigorous” way, there’s still the problem of stability: What happens if your TOS links to Firefox TOS, and then Mozilla updates it? The update will effect the meaning of your TOS, because it could change arbitrary sentences in a way that you may or may not intend.
Well, then what about versioning? Why not slap a sem-ver number and CIAD?
Because you’re still referring to the contract using whatever identifier the author invented:
Either way, the ID may not be “legally-valuable”, as an org may not be recognized internationally.
Here comes my proposed solution…
An open standard international registry of unique contract identifiers. Each identifier maps (associated) to a complete, clear, unambiguous, legally-sound, document that could be used as-is or as a template for customized docs. Every major (semantically breaking) update must have a different version number, and the previous version must still be available for reference.
To allow custom contracts to specify modifications (diffs), a standard diff description format (like Git’s) should be used for machine-readable text.
For human readers, something like Section 3, paragraph 5, sentence 4, is to be replaced with "blah bleh..." could be used instead, but each one of those “part-numbers” must be rigorously defined by the specification (How exactly do we split sentences?), not the author of the custom-contract. An alternative is to explicitly label each section of the document: this allows automatic TOC generation, and is efficiently searchable by software.
I guess that’s it! It really is “quite simple”.
It’s worth noting that this won’t magically solve the problem of ill-intentioned data-hoarders, which are happily willing to abuse dark patterns such as opaque privacy-policies to deter users from protecting their data