Open proposals
Making it easier for software to stay within the law
Proposals LexLint puts to the wider community, offered for anyone to adopt, so that the lawful path is the easy one for the software people build and run.
The legal responsibilities are the same for everyone who writes software: tell people what you do with their data, keep the records a regulator can read, report what went wrong within the hours the law allows. What is missing is not the law but the plumbing. The facts those responsibilities turn on, above all which jurisdiction's law reaches each party to a piece of work, have no agreed way to travel between the systems that do the work, so every team either invents one or goes without.
A mechanism nobody owns is the one everybody can adopt. Each proposal here is a small model with its bindings, written so that a protocol engineer with no knowledge of LexLint could build from it, and offered under a license that lets anyone take it, change it or carry it into a standards body without asking.
Each mechanism says which requirements it meets, and the requirements themselves are stated in the papers, not here. The proposal below, Jurisdictional context, meets R1 to R9, which the paper Whose law was that? states for any record of a piece of work, so that the law's deadlines can be read. ACTIVITIES.md, a file at the root of a repository that says what its code performs or enables, meets D1 to D7, which the paper You already think about law states for any declaration of what code does; it lives beside the activity registry it draws on. An options paper, Paths into standards, sets out where each mechanism could be standardized and what each route costs.
-
Jurisdictional context
A small, vendor-neutral way for software to carry, for each party to its work, which jurisdiction's law reaches that party, from the first hop to the last
Draft 2 · comments to open@lexlint.io · not yet before any standards body
Summary. A law reaches a piece of work through where one of its parties is: where the person it serves is sitting, where the data subject lives, where the operator is established, whose machine was read. Those facts exist at different hops of the work, and the hop that can see one is rarely the hop that needs it. Nothing standard carries them, so each system either guesses from its own socket, which yields the location of a point of presence, or records nothing at all. This proposal gives software one small way to carry them: a reading per party, never merged into one country code, with its source and a commitment to its evidence, as a structured HTTP header across trust boundaries and as baggage inside them, recorded at each hop exactly as given. It says how it meets each of the nine requirements in the paper Whose law was that? and why the readings stay out of the authorization credential. It is for any distributed software, agents included, and it is offered for anyone to adopt.
-
Paths into standards
Where each mechanism could be standardized, and what each route costs
Draft 1 · comments to open@lexlint.io
Summary. Two mechanisms, the repository declaration and jurisdictional context, are texts anyone may adopt today. Each could also be carried into a standards body, and the bodies differ in who decides, what a contributor licenses, how long a text has taken there and what could go wrong. This paper sets out those options venue by venue, beside option zero, in which the text stays where it is: how each venue decides, its terms and its record of time as its own pages state them, and what it would own and what could go wrong as this paper reads them. It opens with the order an earlier text followed, the specification behind the license identifiers in files and packages, from a community text to tools to an international standard a decade later, and both mechanisms are at the first of those stages. The requirements the mechanisms meet are cited, not standardized. A reader can reject a venue and keep the mechanism, or reject a mechanism and keep the need.
LexLint proposes, the community decides, and LexLint adjusts to what lands.
How this works
- A proposal is text anyone may adopt, fork or improve. Every document here is published under Creative Commons Attribution 4.0, so a vendor, a working group or a competitor can take it as it is, with credit, and need not ask.
- Draft numbers move when the text changes in substance. The date beside each proposal is the day of its current draft, and a later revision of the same draft is dated beside it. An earlier draft is never silently replaced; the change is said on the page.
- Comments go by email for now. Write to open@lexlint.io. There is no repository yet; one is opened the day a second organization wants to edit the text rather than comment on it.
- Nothing here is legal advice, and adopting a proposal meets no legal responsibility by itself. Each one says what it does not do.
The argument for why this is needed is made at length in the LexLint whitepapers. The proposals are the mechanisms those papers ask for.