Note that .DOC is the industry standard for contract negotiation, whether you like it or not (I don't!). A template sales contract that is going to be redlined is going to be a DOC file, because it more or less has to be.
People suggesting that this instead be released on Genius or Github should also remember that there are corner cases in contracts where formatting actually matters. Not only is .DOC the most pragmatic choice for a high-profile template contract, but it's also the safest.
I concur. In private practice I have negotiated, drafted, and revised hundreds of industry agreements and a redllined MSWord .doc is what I create and expect from other attorneys. There is still a percentage (I personally find as much as 20%) of more seasoned attorneys that use WordPerfect. I can only describe their unreasonableness about it as being brainwashed to believe using anything but WordPerfect would somehow be a negative reflection on the firm/lawyer and that Perfect has some functions Word does not that are specific to the legal field and yet can never actually be named. Long story short, the formatting between the two programs is the worst.
I cringe every time I get a WP red-line back, too.
In case you're interested, there are actually some legal use cases for WP that make sense. If I'm not mistaken, the Office of the Reporter at the Supreme Court uses WP due to its superior hyphenation, kerning, and other publication-quality print readiness features. The clerks, justices, Reporter, and print staff can all work in the same program from draft to distribution to GPO.
Historically, at least, WP HTML export was also much cleaner, lighter, and more machine-readable than Word's. The Supreme Court of Texas has opinions online, for instance. Last I heard (a couple years ago) that HTML was exported from WP.
Word's HTML export still is pretty much the same, even in Word 2013. Yes, you can use Word 2013 to generate HTML that won't render properly in MS's own IE10 by default!
Another WP feature that existed before Microsoft Word itself existed (indeed, before the IBM PC existed) was the ability to create a "Table of Authorities". Word Perfect was very responsive to the needs of legal word processing. Some of you might recall that Word Perfect was created by Satellite Software of Orem, UT circa 1980, and ran on Data General minicomputers.
Also Open Sourcing something without a license is very pragmatic too :). When did "open source" became a term for "we're nice giving you stuff for free".
I think the word you're looking for is "convenient" it's easier to just upload the .doc they're using and write a blog post than create a Github repository with a readme, and review pull requests of people correcting spelling / grammar mistakes and such and such.
Props to YC to give this away for free, I read it, looks good, but don't try to excuse them for their laziness by calling it "pragmatism" just because it's YC and we're writing on their forums, great content but they shoulda been more professional before using the words "open source".
This is a LEGAL agreement, that says in the announcement is OPEN SOURCE and doesn't have a license attached to it... Think about it.
What would be licensed? Who would license it? How could they ever sue for infringement with a public notice on the Internet making the work available for unrestricted use without a reservation of rights?
While there isn't any clear reason form contracts can't be copyrighted, it isn't at all clear who would hold the copyright or whether it could ever be effectively enforced.
Ken Adams has a nice write-up of associated issues:
> Also Open Sourcing something without a license is very pragmatic too :). When did "open source" became a term for "we're nice giving you stuff for free".
First the industry standard for contract negotiation is to determine if you even need a contract like this that has to be "signed" and/or negotiated.
Missing is the dollar amount of a transaction or type of transaction that using an agreement like this relates to. It's overkill for many transactions and will kill deals. Companies don't sue over small amounts of money however deals do get killed if you give customers to much to think about.
Specifically:
"We've just open-sourced a sales agreement any company can use. Though obviously you should use this at your own risk, we've had a lot of experience with what makes good and bad sales agreements."
If you leave it up to the lawyers they are going to try and wrap up every single detail without considering any of the downside risk to having a customer have to review an agreement. Many of these agreements came to being by corner cases of liability that are few and far between.
Bottom line: Make sure to consider if this is necessary in this form at all (for your company) and if there is another easier friction (edit "free") way to provide some protection. This is not a case of "it can't hurt" it can hurt getting a sale.
This contract is about half as big as the standard professional services agreement we executed with all our clients, and smaller still than the paper our clients would get us to work from.
If your lawyers are "going to try and wrap up every single detail without considering any of the downside risk," you should get better lawyers. In particular, I find transactional lawyers have a much better "deal sense" than litigators moonlighting at it. Once you've found a lawyer you can trust, you're more likely to trust his or her judgment more on what the legal risks really are.
If it's the other side's lawyers who are overlawyering the agreement, why not politely suggest to your counterpart that they, not their lawyers, should be driving the deal?
>Why not suggest that your counterparty, not their lawyers, should drive the deal?
Because here we're talking about sales, in which asking your counterparty to do things they don't already intend to do injects friction into the process, thus reducing your chance of closing the sale.
Good point and one of the reasons for using standard "forms" in many businesses. They telegraph "this is the way it's done" even to the extent by having fill in the blank sections. (Rental lease is an example of this). Once again not always appropriate but in many (not all) cases gives a customer less to think about.
What a cool project. Though as a recommendation, I would make it easier to find out more information from those videos. Github, etc. I wanted to learn more and had to find the github repo from the npm package you gave on your first video.
Thanks for your comment. I am definitely aware of the need for more materials, but haven't had time since posting to npm earlier this week.
If you'd like to chat more about the project, or would like me to walk you through the main ideas or any part of it, please feel free to e-mail me. I'm looking for feedback and dog-fooding the system at present, trying to ferret out flaws in the data model before building out the web interface.
I am definitely not the person to be giving you feedback on this, I'm not a lawyer or anything myself. Just consider me a pair of outside eyes looking in that loves when hackers tackle problems in other industries.
I use Contractually for this. I upload my .DOC files and invite others to view them. Plus I have a repo of contracts that I have signed.
http://www.contractual.ly/features/
A draft agreement often goes through internal revisions and edits before it's packaged up as a single "redline" (akin to a diff) that's presented as a package to the other side. The order and scope not only of edits presented, but other alternatives drafted and dropped, or drafted and tweaked, is potentially revealing, as is the timing of edits and the fact of who made them. A live editing environment doesn't let you hide these details when necessary. It also fails to prevent the other side mucking about in the draft as you're reading, reviewing, or editing it. Sometimes everyone will play nice and wait their turns to use the pen, but often they won't.
Similar concerns make it difficult to adapt Git for use with opposing parties, since many of Git's features flow from the way it addresses its tamper-evidence design goal. The only notion of a commit with two ancestors in Git is a merge commit, which nonetheless preserves the complete history of both parents. So one side can't manage internal revisions with in-house commits (bearing author name, timing, exact content, etc.) and then issue a PR, while keeping the history of internal revisions secret. They have to edit history and make a squashed commit available for pull. At that point the incremental benefit of Git is just SSH or HTTP instead of e-mail. It's just managed patchfiles.
Squash commits it does, but I don't think we really want squashed commits.
Squashing works to hide edit history from the opposing side, but it also pulls history out of your own history. You can create a branch at your local head before squashing to save those commits, but when you get an edit back, its new commit will reference your squashed commit. If you rebase onto the branch with your local changes, you can reconstruct "your history", but you'll have to be careful not to push commits from that branch to opposing next round, since it now contains your private edit history again.
I wonder how often this is abused. Are people relying on change tracking, or actually using the diff functionality? I've seen at least one where people just used change tracking. It would have been easy to change something and accept changes and could have slipped by or changed negotiations.
Great question. This actually rises to the level of a professional responsibility rules issue in many jurisdictions. Take, for example, this recent-ish opinion from the California Bar's ethics committee:
The best practice is clearly to run the diff from your own last revision, but that may not be available to the attorney. Sometimes clients forward opposing markups of drafts that were prepared without an attorney, perhaps based on a form. Business people may tweak a draft between attorney revisions, as they closed on deal points. It might be worthwhile to go over and attribute each unrecognized change, but not always. Clients may vouch that all changes needing review are in Track Changes. Sometimes speed matters more. Between repeat-player attorneys, or when reputations for ethics and rigor otherwise precede each side, the risk of this kind of thing approaches zero, and everybody saves money.
I have seen things "slipped in", often inadvertently (turned Track Changes off, diffed the wrong files), but sometimes maliciously. I have also done very long days of nothing but verifying execution copies of documents as they were closed out in the run up to big-dollar closings and low-dollar slug-fests. When the transaction is large or important enough, attorneys will handle exchanging drafts across sides and enforce more rigorous change control.
People suggesting that this instead be released on Genius or Github should also remember that there are corner cases in contracts where formatting actually matters. Not only is .DOC the most pragmatic choice for a high-profile template contract, but it's also the safest.