When one speaks of “Open Source,” there are two words and two concepts. “Open” refers to a legal idea: the solution is free of legal restrictions. “Source” refers to the format of the text: it is made available in the format that a skilled practitioner can best use.
In software, the innovation of “open source” was the “open” part, the legal regime of copyleft and the like. Coders had already developed the notion of working with modules in a format that made the programmer efficient. “Source code” contrasted with “compiled code” or “object code.” The problem that copyleft solved was that the source was available only to the proponent, not the user.
In law, we have more or less the opposite situation. Legal documents are nominally subject to copyright and in a few domains copyright assertions have some impact. Those are few. For most legal documents most materials are freely copied without any worry about a copyright assertion. But they are published in a format that resembles compiled code. The ideas are no longer discrete, the alternatives no longer within reach. Deal points no longer separate from forms.
Document assembly goes some distance towards “source”, but mostly only for the author. The output of the process resembles compiled code for the reader. This is not always so and not strictly so, (and systems such as DocAssemble begin to cross the chasm) but as a general matter, the big difference between legal collaboration and software collaboration is the lack of a “source” format.
“Markdown” text is intended to make authoring more structured but remains blobs. LaTeX, used in science, is truly modular, and would be a great tool for legal collaboration, but it is a bit complex.
And legal has the odd characteristic that the “source” version is generally more useful than the compiled. While lawyers and others have grown accustomed to reading long documents of nearly complete repetition, what we are mostly trying to do as we read is to assure that the text corresponds to a paradigm that we already have in our minds. It is much more efficient if we can simply know that that is true because the “source” (in the related sense) of the text is known. We do this all the time with statutes and regulations, and with contract annexes such as statements of work. But this has not been generalized in law, as it has in coding. That is the role of legal document “source” code.
Here we propose a general, simple form of “source code” for legal documents, all of them, as flat files, directly workable in git. Prose Object