Hacker News new | past | comments | ask | show | jobs | submit login

Not a lawyer either. Not even the person in my company most exposed to contract drama. But, I've been exposed enough. And:

* The "Work for hire" clause is indeed standard and you should have it (it will be in almost any contractor agreement you download from the Internet).

* No company with a lawyer is going to accept a forum clause. You'll be lucky to avoid a fight over what state's law governs the contract.

* Similarly, legal costs.

* My issue with the "testing" and "deadlines" clauses in this article is that you don't need to dick with contract language to get these features; what experienced companies do is ink a master agreement and then attach "statements of work" as exhibits to the end of the contract. A SOW usually includes acceptance criteria and deadlines, and you can write them in plain English.

* Even without a lawyer, a savvy client will chuck "severability"† (I know I would), for the same reason you wouldn't pay a cab driver who only took you halfway to your destination. It is quite likely that, in the event you fail to complete the gig, the code you've delivered me so far is going to be worthless.†† I'd be irritated just seeing this clause in a contract...

* ... no, wait, I wouldn't, because I'm not signing your contract, because in all likelihood your company is smaller than mine, and the larger company usually owns the paper. Try giving any contract to a company with a ticker symbol and you'll quickly find out that deals are done on their paper or not at all. Some of the same logic in this article applies; it just applies in the context of concerns you bring up with your lawyer when she reviews their contract.

(Severability also means something different from what this author thinks it does; I'm not a lawyer either but I think it's the feature where one broken clause in a contract doesn't invalidate the whole thing).

†† (If you want some form of payment early in the engagement to mitigate the risk that the client is a deadbeat or unserious about the project, ask for an up-front payment. That's standard. It's a negotiating point and you might not always get it, but at least you're up front about it.)




Hi tptacek :-)

I think you raise some good points. I'm new to the legal side of things so it's helpful to get some additional perspectives.

I do think, for whatever reason, somehow we seem to be in a position to dictate terms. I'm not sure if it's a function of our niche specifically (iOS) or if it's just the adage that good hackers have enough leverage to ask for things, if it's the fact that we're small and our costs are low and we don't have to take on that many projects, or exactly what it is.

I'm thinking of three examples specifically, where we've dealt with midsize companies (20-50), and they said "We won't do these terms" and we said "OK, good luck with your project." All three ended up signing. And in retrospect it's a really good thing they did end up signing those kinds of terms, and if we had given on some things we would be up a creek right now.

Now obviously sample size fail and such, anecdotes are not data, etc. Maybe having a looser contract would open us up to a better quality client, or a better paying client. But IMHO the chief advantage of contracting vs going to work for somebody else is the ability to choose who you work for. And if a strict contract self-selects some of those people out I actually view it as a success.


Those all seem like really good points, but how many of them apply only to dealing with larger companies, which can afford legal advice, or with very savvy clients?

If you're a freelancer getting started doing Rails development for clients you've met at networking events, for example, I would imagine that most of your clients will accept those clauses in your standard contract?

I'd argue that the best course of action is to stick those points in, and be prepared to drop them if the client insists. At the very least, it provides you with a cheap negotiation token.. "we gave in on this point, so you should give in on that point."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: