Today we’re very excited to announce our first alpha release. It might not seem earth-shattering to you at the moment, but to us it marks a giant leap forward for LexPublica. That’s because our first small group of participants is now able to start drafting the first contract – what’s new today lays the groundwork for what’s to come. We hope the more you learn about the project the more interested you’ll be to participate, so I’ll walk you through it.

You’ll first notice that our website is now live. Zak’s been coding like mad to have the site serve two initial major functions. The drafting area is where participants will work on crafting new contracts (more on our workflow plans to come in future blog posts). The first group of participants—consisting of two lawyers, a law student and me, plus Martin and Zak—are here in Vancouver, and our collaboration will take place in the drafting area. In time, people from all over North America will collaborate via our site.

The drafting area is public, so you can watch progress happen over time, from outlining to drafting to reviewing to editing. None of the drafts is intended for use by the public, of course. After a draft has been reviewed and edited so that it’s clear, accurate and concise, it will be published on the main site, covered under a Creative Commons licence for all to use.

The second function debuting today is the issue management system. Participants will manage all tasks, comments, feature requests, questions, etc., related to the development of a contract with the issue tracker. Once a contract is released, the issue tracker will continue to be used as participants manage suggested changes and feature requests.

It’ll be a few weeks before our first contract is ready, and once it’s released we hope you’ll have a clearer idea of what our project is, how it works, and how you might want to get involved.

Want to know more? Check out our new FAQ or leave us a comment.

When we first introduce people to the idea of LexPublica, a common assumption is that we’ll be like Wikipedia.

It’s not a bad assumption. Wikipedia has been phenomenally successful and we could do worse than to emulate them.

The challenge we’d face with trying to be like Wikipedia is that they use a “release, then review” content creation process.^[1]

The “release, then review” approach works well for content where the average reader can evaluate the quality of the article. For example: in a typical Wikipedia article, a reader has many ways to determine how much trust to place in the  information provided. Readers can check citations, cross-reference the information provided in the article with other sources, review the change history and discussions, and so on.

While it is relatively easy for the average person to verify a mundane encyclopedia article, most of us can’t verify legal information (or other specialized and complex knowledge like software or medical information). A consequence of this is that Wikipedia’s model is a poor fit for LexPublica. If we chose to release agreement templates before they were reviewed, we’d be inviting disaster for everyone who chose to use them.

In the Linux and open source software world, most projects fend off disaster by releasing only after review. In Linux’s example, multiple reviews are performed on code (and indirectly, contributors) before it is released to a large group of self-selecting testers for another review. Only after this chain of reviews is code released for general use.

LexPublica will be following a model much like Linux’s, with contributions being reviewed by trusted community members before they are released for general use. These reviews will be part of a larger process to create and improve content. In the coming posts, we’ll write more about this process and the tools that we’ll need to support it.

1. By “release, then review”, we mean that content is published and, over time, may be reviewed by readers and Wikipedia community members. This model is changed in some situations, such as when an article has a chronic vandalism issue. [↩]

In the months that we’ve been telling folks about LexPublica, we’ve heard a lot of different suggestions for the agreements that we should draft up for the alpha release in August. The most common requests for templates have been for:

• Consulting and service agreements
• Confidentiality/non-disclosure agreements
• Employment agreements
• Family agreements (such as pre-nuptial agreements and wills)
• Location and model releases
• Rights assignment agreements
• Website privacy policies and terms of service

If there is something on the list that you need but don’t see (or want to help draft), drop us a comment. We’re not going to promise that we’ll deliver any particular agreement, but the greater the interest in a given area, the more likely we’ll focus on it.

The spelling of English is a small bugbear for websites with an international focus – especially for those few sites like LexPublica that need to dance on the point at the intersection of correctness, comprehensibility and the law. While spelling isn’t the biggest issue we’re facing, it is still important for us to choose a consistent and well-considered approach.

An early example of the issue is “licence”. In much of the English-speaking world, licensing is accomplished through a licence. The licence is the document, while license is the activity. In the United States, however, license may also refer to the document.

Choosing to use licence or license is a small point, but attention to detail is significant because we’re building a legal commons and precision in language matters in the law. It matters especially because one of LexPublica’s long-term objectives is the standardization of contracts and contract language.

When we hashed out the issue, the major choices seemed to be: laziness, provincialism, simplicity or commonality.

The lazy approach is to let spelling sort itself out in the future, as it becomes an issue. We didn’t think that this would be a particularly good approach to take – we’ll have enough trouble with doing this sort of thing by accident.

Provincialism would let us stick to the Canadian dialect of English and subject others to our uncomfortable compromise between British and US English. This approach might nettle our friends to the south and induce them to waste time fiddling with the spelling in LexPublica documents.

Simplicity would let us choose the simplest version of any given spelling, dialects be damned.

Finally, commonality would dictate that we choose the variant shared across the greatest number of dialects.

Of all the approaches, commonality seems to give us the best result. So long as the meaning is consistent with the shared spelling, then the common spelling has the best chance of having the right meaning to the most people.

It’s been a surprising amount of work to come to the decision to use “licence” as the noun and “license” as the verb.

Like many rules, this rule has an exception: when “license” appears in the name of a specific document, or when quoting from a document, one should leave the use as is. For example:

The Creative Commons Attribution License is the licence used by LexPublica to license its blog content.

Of course, this is the kind of issue for which style manuals are written. We’ll write more about our plans for a community-developed style manual for contract drafting in another post.