Wednesday, April 21, 2010

Open Source—A Dose of Tomato Juice

A recent exchange between Ron Friedmann and Ken Adams takes differing views on the value of open source repositories of transactional precedent. Ron Friedmann proposes a thought experiment to determine whether a common pool (a Corpus) would increase lawyer efficiency. Open Source Law - How Big a Savings? Ken Adams responds by saying this approach overlooks the fact that "the Corpus would be a dead skunk in the middle of the road, stinkin’ to high heaven." Open-Source Law and Contract Drafting—A Dead Skunk in the Middle of the Road. I would like to add some tomato juice to the discussion.

1. Filtering to Core Language

We have enjoyed access to enormous information resources for a relatively short period of time. For many there still uncertainty whether is it a vast repository of expertise or just noise?

One camp argues for the wisdom of the crowds
; asserting that the many smarter than the few. Others believe crowd-sourcing is inherently unreliable. Indeed, there is the good, the bad and the downright ugly. The problem is that most people of my generation lack adequate filtering tools to handle the volume of information now available. What can we do?

First, we can rely on experts. Indeed, a comment to Ron's article expresses doubt whether the Corpus can replace the tried and true approach of "walking down the corridor" and finding an expert.

Second, we can develop our personal filtering skills. For me, the professional journey has been a passage of exposure to greater and greater amounts of information. When I first started practice, my "world" comprised a few colleagues and one tax treatise. It was a wonderfully comfortable environment with hard edges and nothing beyond its narrow purview: at least as far as I knew. But, for me, this world it doesn't exist anymore and I have no intention of returning to its narrow confines.

Third, we can build advanced technologies. Imagine Westlaw or Lexis without faceted search (court, jurisdiction, subject matter etc.) or validation tools (e.g. KeyCite and Shepard's). The results would be chaotic. They might not reek, but they might have an off-putting odor.

We need different tools to manage the Corpus. Through the lens of contract analysis—virtual tomato juice—you can see that in every deal there is, in fact, a core of standard of non-negotiated language. You can also see a vast penumbra of variability. And, if all you see is the penumbra, then it will likely look very messy.

2. Checklists of Deal Terms

Of course, if the repository is in fact "a motley assemblage exhibiting, in general, deficient and inconsistent language," (Adams) then there would be little point in applying personal, editorial or technical filters on such a collection.

But it is not just a repository of legal terms; it is also—and perhaps more importantly—a compendium of business terms.

For example, it is one thing to know how to write an IP ownership provision in a software development agreement; it is equally important to understand what other business terms should be included to protect the developer, owner and licensee. We gain this experience over years of practice reading hundreds of agreements—some good; some not so good. The problem today, compared to my starting point is that there is so much information: and no librarian.

Our experience in reading voluminous precedent allows us to construct mental checklists of legal and business terms. Just as technology can be applied to vast repositories, such as the Corpus and cut through the noise to the core language, it can construct term sheets of all the different deal elements. Should you, for example, include a clause capturing derivative technologies in the software development agreement? What is a derivative technology clause?

There is a vast amount of knowledge locked up in repositories such as EDGAR. We are just now developing the keys to unlock its wisdom.


  1. I think you hit it on the head, Kinglsey. As a former (and now hobbyist) open source programmer turned lawyer, one of the key benefits from the software world of open source comes from the ease of assembling freely available code snippets or libraries into a project. There is an inherent trust that the snippets or external libraries are accurate, which sometimes is misplaced. Tools have been developed to ensure coding standards are kept, but the challenge is making sure those tools are used and a dependent snippet / library is accurate for your task. But the snippets / libraries are developed for their own sake, not as a part of an assembled program (which differs from open source drafting).

    In open source drafting, since clause development for its I'd see the benefit would come from an extensive analysis of contributed documents to extract out those components and categorize them and to provide systematic analysis of how those documents related and differ. A tool to do this is imperative otherwise the repository is a mere data dump of little value.

  2. Kingsley: I've updated my post with some thoughts prompted by this post. As I noted in a comment to Ron's post, tripartite discussion on our respective blogs is a little tricky! Ken

  3. Kinglsey: your post begs the question - is the knowledge KIIAC is uncovering one that will be disseminated in some respect or is there a possibility for your software to be part of tools behind an "open" transactional document library?

  4. Duncan,

    My apologies for a very tardy response. I need better monitoring tools for tracking comments.

    In answer to your question, KIIAC's primary purpose is commercial. However, from time-to-time, I work with groups interested in standardizing a set of forms. For example, I'm working with the ABA's MIPSA working group to standardize intellectual property security agreements.

    Despite our commercial goals, I believe it is important and in our best interests for the process to be open and to learn from diverse groups. Accordingly, I'm happy to share my research with interested groups and individuals.


  5. Kingsley,

    My response is as tardy as yours.

    I appreciate your response - so if there was an earnest effort to provide open standardization, there might be a way, on a commercial basis, to engage KIIAC to aid in that analysis and standardization, correct?