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.
I help clients negotiate SAAS deals, and I like this as a template. It's better than 95% of the contracts I see. But since this is the internet, I will use the rest of this post to complain about things:
1. Formatting: One column of text is better than 2. It's digital, we don't need to cram words in to save paper.
2. Information Architecture. Contracts longer than 2 pages should have a table of contents. In most use cases, people are only looking for 1 or 2 specific terms in the contract. ToC helps.
3. Naming is Hard. Names should suggest some unique aspect of the thing they represent. In this contract, the parties are defined as "Company" and "Client." But both parties are companies. Using "Company" to refer to only one of the two companies invites confusion. Yes, it's defined. Yes, it's standard practice. But a better defined term might be "ASP" or "Host" or "Provider", etc.
4. "Herein." I don't like herein.
4.1 Herein is stuffy. No one talks like that.
4.2 Herein is ambiguous. http://www.adamsdrafting.com/herein/
4.3 Instead, use "in this agreement" or "in this paragraph."
5. Arbitration? Going to court is a hugely expensive distraction. Arbitration is slightly less expensive and distracting. Any reason not too ask for arbitration?
I have a personal rule never to throw MCSD at opposing's draft, but this is a form, so I'm down. Ken Adams has a posse. We should make t-shirts.
On the other hand, from a practical point of view, all the nits you pick add up to a certain kind of camouflage over the agreement. If the point is not what the contract says, but that YC said it, now it's "standard", and you can not think about it, then enlightened style is at odds with (facilitated indifference to) substance. For a first sale in particular, the immediate benefit of the fact of a sale probably outweighs probability times cost of any conceivable drafting flaw that doesn't produce uncapped liability, a cloud on IP, or some other existential threat.
When I look for a ray of hope, it's the number of blanks. If this thing has to go back and forth, and nobody is going to sign it as presented, then by all means make it as modern as possible. If it's going to be read and handled, it ought to read and handle well.
" For a first sale in particular, the immediate benefit of the fact of a sale probably outweighs probability times cost of any conceivable drafting flaw that doesn't produce uncapped liability, a cloud on IP, or some other existential threat."
I had to parse this sentence about 10 times and still don't entirely get what you're saying
Touche. Thanks for making such an effort to understand the sentence.
What I tried to convey is that the ability to say you've made a sale is worth a lot. It's a milestone, and it comes in the vulnerable make-or-break days of a company.
A flawed contract provision only hurts when circumstances force you to live by or enforce that provision. The chance of that happening for any provision of any particular contract is usually low. On the other hand, if the flaw in the language can shut your business down, even a small chance of that bad outcome is worth worrying about.
I assume that a very orthodox proposal will draw less attention, prompt less negotiation, and get more deals signed quickly. My conclusion is that, because the first sale is worth so much when you need it, you might be better off with a traditional, error-prone form that's easier to get signed than a modern, technically superior form that protects you in edge cases and after long negotiations. Your business might fail because you never sold, long before anyone has any reason to sue you.
In my defense, I don't choose to express myself personally in the style of my contracts. You'd probably have understood me better if I did, but no one should have to live that way.
At the risk of getting down-voted for self-promotion...
I see a lot of comments around Word being not the right format for "distributing, sharing, commenting".
My startup Documize [1] is just a week old and is currently being tried out by a handful of legal professionals and the like for handling what happens around structured documents.
The premise is that MS Word is where structured documents are born in the enterprise world. It's what happens after they come into being that is the problem: network drives, file sync folders, email tennis, Word-track-changes, manual consolidation, etc.
A real pain.
Documize aims to help people distribute documents, collate feedback, provide version control and even allow for private notes. From a browser.
Working towards that vision at the moment -- just thought I'd throw this out there.
We are solving many of the same problems at Contractually [0]. Word import, contract generation, private editing, version control, redlining, commenting, e-signatures, and more.
James Riley works at Goodwin Procter (sp)[1] and kudos to him -- this is a big contribution to the startup ecosystem.
Also, many thanks for not including an arbitration clause and class action waiver as a default term. Not only is it incredibly sleazy (in my opinion) but also many companies will have significant push-back on such a term. Usually requires their own in-house counsel to look at it, and that's the last thing you want.
Thanks for all the comments everyone. We're currently looking into getting these documents on git. Because Word Docs are not ideal for versioning, we'll probably convert them to markdown and use Pandoc to offer Word and RTF versions.
We'll probably also attach an explicit license as well. We've similarly described the Series AA and Safe as open sourced documents and honestly didn't really think too much about it after that. Mostly, it's to efficiently tell you that the documents are free to use and change as you see fit.
Obviously, we're not trying to trick anyone. Suing founders is not part of our business model.
I don't think anybody assumed you're out to trick people, however "open source" has a very clear definition [1] which implies that the work in question must be accompanied with a license respecting that definition, in order to modify the work and further distribute it. We as software developers have learned to search for and take note of permissive licenses and are very cautious of fake open source, like for example Microsoft's infamous "shared source" initiative.
My disappointment is when people are diluting this term, because it doesn't mean just free as in beer and it doesn't mean just having access to the source code. It's much more than that and the definition couldn't be clearer. Many companies have tried capitalizing on this term without delivering and this has left a sour taste amongst many of us. And YCombinator amongst all organizations should be aware of this, let alone the lawyer that drafted this document.
This is great, but would be much more helpful as an annotated doc that explained why the various phrasings were chosen, as well as what was left out and why.
What's the best platform for that? It can't be Word comments...
not to be flippant, but this is exactly why lawyers go to law school and then work on such docs for years to develop expertise. The value of a lawyer is precisely in what to leave out and what to put in -- and how to phrase it.
The annotations just for California law would be 10x the size of the document.
If any non-lawyers are interested in what a well-executed agreement with commentary looks like, I highly recommend The LSTA's Complete Credit Agreement Guide, which covers an industry-group standard loan securitization agreement. It's 600 pages. There are others, like commentaries to the ISDA Master agreements, but they're niche and very, very expensive.
For lawyers interested in what a masterfully annotated computer program looks like, have a look at Donald Knuth's "literate programs". If you've a uni library nearby, have a peek at his Computers & Typesetting. It's gorgeous stuff. Great pictures, too!
This is, almost word for word, our sales agreement from Gunderson Dettmer. We've added a number of company-specific (to us) provisions, but the /vast/ majority of it is all entirely the same. Furthermore, there are a few clauses in here I plan on stealing for our own contract.
This is incredible for YC to do. We spent almost $3000 getting our first draft contract. Lawyers are expensive. :(
Hey, at least you can sue GD if they have been negligent in their drafting and you suffer loss as a result. Although of course the likelihood of this happening in the context of a basic sales contract is negligible to non-existent!
Oh, don't get me wrong - I /love/ our counsel. He has saved us, fought for us, taught us and walked us through negotiating with investors, customers, partners, etc.
I'm incredibly glad we have him on our side, and I would recommend him to anyone - startup or otherwise.
I just wish, sometimes, that he weren't $500/hr. :)
Re: the lawsuit, for this type of contract you're right that it's pretty safe to say there isn't much to be negligent about, especially as they're a reputable firm. The fact that YC's docs were almost word-for-word our docs makes me much more comfortable too. Granted, we had it 3.5 years ago, and YC's docs came out today, so not like we had any other choice. :)
Really nice contribution. Especially for companies who are starting from nothing. Note that if you have big customers, they will probably want to negotiate every last thing. Smaller companies may or may not care about the details, as long as the software works as promised and support is good.
This is a contract, without any of the "this is why you should use this awesome sauce", which I generally like to include before going into the nitty gritty, but just for fun, I created a sample proposal in my app (Mimiran Online Proposals) from the doc, incorporating @teachingaway's feedback that 1 column with decent sized text is more readable, especially online (you can always generate the PDF version).
This is a great move. Unfortunately it's still in Microsoft Word format and there's no license associated with it. Would love to see this somewhere like GitHub, where it could be forked and changed by others.
I'm guessing it's in Word format because most procurement departments use (and expect a Word document) for terms. But I very much agree, that it'd be great to have it on GitHub for collaboration. I'd even suggest this tool (http://ben.balter.com/2015/02/06/word-diff/) my colleague (@benbalter) made to collaborate on Word docs using GitHub.
Only caveat: I've sold SaaS to large enterprises (like AT&T, Coke, etc.) for ten years, and unfortunately most of them insisted that we use THEIR template, which was a huge pain point for us.
I've had to spend money at various points getting documents drafted which, like this, are pretty much cut & paste anyway. I would just like to see MORE of this. Recently came across lawbite https://www.lawbite.co.uk/ which looks useful at least for UK based companies. Haven't used the service so cannot endorse. Basic employment contracts, vesting schedules, t&cs, keep them coming!
As with programmers, it's often hard to tell the lazy from the great, because economy of motion runs with competence. Sometimes copy-and-paste gives you the wrong agreement for your deal, but it's cheap and easy for the lawyer. A different lawyer may glance dozens of alternative precedents in their mind's eye before choosing which form (or pieces of forms) to compose into an agreement for you.
When you dress for an occasion, you start by picking items out of your closet. If you don't have what you need, you may go to the store and buy off the rack. If the occasion or your needs are very special, you may have ready-made items tailored, or may even have something made for you. Good lawyers work similarly.
Firstly: The idea of open sourcing docs like this is great.
Secondly: 4 columns of approx 25 characters - that has to be the most annoying layout ever applied to any legal document.
Thirdly: The document could be significantly improved. If enough people are interested in a markup + comments from a customer and vendor perspective based on 15+ years experience drafting, reviewing and negotiating docs like this, I am happy to provide such within a few days. Please indicate your interest below.
When selling to larger enterprises, particularly high-value company-wide licenses, it's also often worth having a section in there defining who the customer is for the purposes of the agreement. (Do wholly or partially owned subsidiaries generally [or by express permission] get access? What about their subcontractors/joint-ventures/acquisitions?)
I'd be surprised if many larger enterprises agreed to 30 day payment terms and a late payment penalty clause - particularly one with interest compounding monthly - since they regularly take more than 30 days to pay invoices
(the standard hack is to offer a reduction for payment within a certain time frame instead)
If I were the customer I'd also be extremely reticent about signing a contract which gives the vendor the right to increase the renewal rate thirty days ahead and also obliges me to automatically renew for the next period if I don't give thirty days notice. That could be an expensive decision to make in the space of an afternoon...
But, as a small company/start-up you should absolutely stand firm on 30 day payment, 45 at the most. It's completely ludicrous that large companies cannot pay in reasonable time-frames - it's just bullying, and is only done so that the large company can conserve cash. Most small businesses fail because of cash, and failure to pay by large customers is a big reason they get overstretched.
Businesses do annual budgets. Try to push a 30-day notice of price changes at my employer, and we would kick you out or get painful concessions immediately. Ditto with auto-renewal.
These are consumer gym membership-like terms, I'm really surprised anyone gets good results with this doc as it stands.
The penalty is rather low though, and in my experience no one particularly ever cares to exercise credits unless it's something egregious, so provided you're not consistently below 99.9% every single month (which is pretty bad even for a startup), it's generally pretty safe to assume a little bit of a risk if you only miss it occasionally.
Bigger customers will absolutely look for 99.9%, and anything less will be a huge red flag during procurement.
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.