Rafe Needleman wrote a review of Agree2 today: Agree2 creates binding legal documents that won’t hold up in court

I am proud of his comments about the technical aspects of the site, however the title about the legal documents that not hold up in court I find problematic. That said, I am really glad Rafe brought this up. There are plenty of myths and misunderstandings about this.

Technically, I have no beef with the service. I think it’s pretty cool, actually. But although I’m not a lawyer and even though I hate trying to decipher legal agreements when I need to, the service’s tacit encouragement to create my own non-lawyer-approved agreements scares the bejeezus out of me. Sure, I could write an agreement between me and someone I’m hiring to re-wire my house. And if the contractor I’m working with were new, he or she might even sign it. But it would still, probably, be a crappy agreement. A court might agree that the electronic edits and signatures were binding, but that doesn’t mean the agreement would be legally sound. Certainly it wouldn’t be complete.

I object to the title

Saying that Agree2 agreements don’t hold up in court is like saying agreements written in Microsoft Word, don’t hold up in court.

Agree2 is a media and a framework for you to write agreements. We take care of all phases of the contract from drafting, versioning, inviting and legal binding acceptance from the parties. We provide evidence as Rafe points out in a very easy to use manner and allow you to come back and find your contracts in the same place 2 years later.

We hope to foster a community of people to share contract templates. People have already been doing this for many years, informally emailing word documents around.

Due to California law, we can not take an active part in analyzing the contract text. However we try to provide as many tools as possible for this to be easy for you and your advisors to do.

The OAuth standards group recently used Agree2 to create their OAuth Non-Assertion Covenant and Author’s Contribution License. This has been signed by amongst others Digg, Twitter, Google and AOL. I am sure Google’s legal department would not allow them to use Agree2, if they found a problem with it.

Contracts are not between your lawyers, they are between the parties

A common misunderstanding about contracts is that they have to be scary legal documents written by lawyers.

First of all a contract is not the document itself. It is the concept of an agreement the two parties have. The written contract is a handy document that writes down the terms of the agreement in such a way that there aren’t misunderstandings of each parties duties.

We perform contracts everyday. Many of them through our actions like ordering a meal in a restaurant others written like signing a credit card slip or accepting a user agreement.

Generally speaking it is a good idea to write contracts into a document to avoid disputes in the future. This is the whole reason behind writing a contract down. Avoiding disputes. If a dispute should happen in the future this document is used by a dispute resolution institution such as arbitrators or courts.

Opaque legalese is all about fear and power

When I have had to sign long contracts in the past, I can be pretty certain that the person giving me the contract doesn’t understand it one bit. They expect that I don’t understand it either. These contracts still serve their purpose, by keeping us both too frightened to cause a dispute.

That said disputes still happen, and they happen mostly because there is some disagreement between the parties about what The Party of the First Part or some such legalese foolishness actually means. (See more)

Courts are used to standard legalese terms, that is true. There are complex hidden meanings between these. However they are also perfectly able to understand plain English. More importantly if you write your contract in Plain English yourself you are probably less likely to end up in court in the first place, because you and the other party both understand your duties under the contract.

Lawyers are needed for many things

There are definitely cases where you want to bring in lawyers. I think it’s definitely a good idea for large complex contracts. Please do NOT write up a term sheet for a large investment yourself. However in most cases it is a good idea to write the meat of the contract yourself and then have a lawyer go over it. You can then use this a private (or public) template within Agree2 and have the best of both worlds.

However it doesn’t make any sense whatsoever to have pay $400ph for a lawyer to go over a contract worth $500 to you. If you are doing this repeatedly have him go over your template.

Many contracts that should be documented end up being agreed over a phone or in a brief email instead to avoid the hassle of form documents and lawyers. Agree2 gives you a much better option than either.

We are planning a feature in the future where you can give lawyers access to review your contracts and templates.

Government requirements

Most contracts can and should be simple. There are however a few types of contracts where complexity is mandated by law. In particular apartment leases and employment contracts, where just about every state/country have specific legal requirements.

More reading

I have written extensively on this before Contracts are relationships with strings attached, Pragmatic Contract Law for entrepreneurs and Understanding and Preparing for Jurisdictions

Wikipedia on Contracts is also a great resource. Finally talk to your lawyer. Also remember that I am not a lawyer myself.

The first talk of the day at SnapSummit was
Josh Porter, Founder, Bokardo Design.

These are just my fairly sparse notes and commentaries.

It is very different designing for multi way communication systems like Social Web sites than the traditional one way or two way communication approaches.

Josh highlights 5 key rules to getting it right:

1. The Del.icio.us Lesson

Everyone was talking about tags. But in reality the user’s weren’t using it for the the folksonomy, but about saving bookmarks.

“Personal value precedes network value.”

You have to provide a valuable service even if no one else uses it. This makes sure that people start creating content and come back. The social aspects build on top of that and not the other way around. YouTube and Flickr are also great examples of this.

2. Tie Behavior to Identity

Josh gives an example of 2 different Amazon reviews with one person using real name and other made up. The real name is more trusted. So make sure that the things your users do are tied back to them.

The Ebay Feedback Profile is a great example. The whole thing is tied to a users behavior, they manage this without users using a real name only screen names.

3. Give recognition

It’s important to recognize and award your top users, to give further encouragement for users to interact.

Classic example were Digg’s Top Diggers page. This was eventually removed as top diggers essentially kept digging each others stories. This was good for early growth, but not all that good when they had a large user base.

“Recognition seems to work better when it comes from the group and isn’t permanent.”

To avoid Digg’s situation it is important that your algorithm puts priority on new contributions.

Threadless is good at ensuring this by having set end dates.

4. Show Causation

Netflix are great at this. Show effect of what actions. Do this explicitly.

Basically spell out what your users need to do to get benefits of the site.

5. Leverage Reciprocity

Make the interaction itself rewarding.

“Why do people leave reviews?”

First response from many people in interviews are “I like to help people”, but dig down and you find that people are interested in other aspects such as “I like to see how many people read my reviews” etc.

They are not just giving, but receiving a lot in return. Some of this is the input of other users, but also

LinkedIn: Very high percentage of people who you review review you back.

Top Amazon reviewer Harriet Clausner has reviewed 14000 books. 7 books a day. While Amazon doesn’t expire reputation, it is putting more and more emphasis on high quality revies.

Josh has a new book coming out called “Designing for the social web”. I’m sure it will be a worthwhile read. He also twitters at bokardo

FireEagle is Yahoo’s great new location web service which was recently launched into beta.

This review will not cover the API. A great little intro for this can be found in Interfacing a Rails App to Fire Eagle by Kamal.

I have previously written tutorial on writing OAuth Clients in Ruby or Turning your Rails site into an OAuth Provider. So I won’t go over any code here.

This is strictly about the user interface of FireEagle OAuth implementation. The FireEagle team Tom, Seth and Rabble have done an excellent job thinking about the UI and how it affects the security and privacy.

Which is great as most of the rest of us involved in OAuth have been worrying more about standards and implementations than usability. In reality Usability is one of those very important things that the security world tends to forget. So let’s learn from FireEagle’s example.

Here is my second video about Bootstrapping AntiPatterns based on the post Solo techsupportitis I posted a couple of years ago.

Find the full series here: Bootstrap Anti Patterns roundup – the first 10

As everyone is talking about tips for startups at the moment, I thought I’d maybe start a video conversation about it on Seesmic. It’s based on a fairly popular series of blog posts I did a few years go called Bootstrapping Anti-Patterns

If you have a Seesmic account and are bootstrapping, please reply with your own experiences. Otherwise feel free to reply here.

The original article is here Bootstrapping a business vs playing a business. An overview of it can be found here Bootstrap Anti Patterns roundup – the first 10