Software Contracting and Legal Matters
sealedabstract.com
sealedabstract.com
* 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.)
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.
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."
Ha. If you were a lawyer you would know that saying "this is not legal advice" doesn't actually turn legal advice into non-legal advice.
The whole post is legal advice.
EDIT: I think that is funny that I get downvoted for this. The writer very early on in the post demonstrates that he doesn't have legal knowledge, yet he advocates people using his language in their own contracts.
Some of the clauses don't protect how the writer thinks they do, if at all. Parts of the analysis/summary are flat out wrong.
For example, the legal costs clause is one of the scariest in the post. You really want to allow the other side to recover their legal costs if he sues you? These things work both ways.
Just look at the balance of potential damages. Your potential damages are for the unpaid contract price. That is it. The client's damages if your software fails could be millions of dollars in tort liability. And you are going to pay their legal fees when they hire the best contingency lawyers around and win?
By the way, defense attorney's can't take cases on contingency basis. If you are being sued you will have to pay your own way with the hope of collecting afterward. The legal costs clause created a nice incentive to go to trial for the opposing plaintiff.
Be careful out there.
1. Hopefully you incorporated in your state and actually have the protection, not as a Delaware LLC, which might not help you. Hopefully you paid the yearly fees and did the registration requirements, too.
2. Declaring bankruptcy doesn't just let you walk away. The opponent will get your assets. Did you claim your computer as a deduction? Other side could get that. They can get any corporate assets up to the judgement amount. If you have regular income from licensing agreements they can also get that. And so on.
3. Declaring bankruptcy isn't without its consequences. Senior officers of companies that declare bankruptcy can be prohibited from serving as a senior officer or founder of other/new companies. In some instances it will show up on your personal credit report.
4. Hopefully you don't have a business line of credit that you made a personal guarantee on. Or friends and family loans.
And so on.
If a work is a "work for hire", the employer IS THE AUTHOR as far as copyright law is concerned. As soon as the work is fixed in a tangible medium of expression (i.e., as soon as the programmer types the code in his editor) the copyright springs into existence, and the owner of that copyright is the employer. See 17 USC 201(b).
The clause in the article talks about the copyright being transferred to the employer after the contractor is paid, and says that before that the copyright is owned by the contractor. In other words, it is NOT a work for hire.
From the discussion in the article, the purpose for this clause is so that if the employer does not pay, the contractor can use copyright law against them. Thus it is clear that the contractor in fact does not wish to create a work for hire situation.
So why use the "work for hire" language? You are just asking for trouble--in a dispute the employer will argue that you intended to create a work for hire situation and that the other language about transferring rights should be tossed out (contract ambiguities generally are interpreted against the drafter).
I don't think they would succeed in this, but why the heck would you want to even give them it as an issue?
Whether you want a severability clause or not depends on a bunch of factors. Sometimes people insist on clauses that are not enforceable -- that can be used to your advantage.
After getting burned once or twice, the skill you will really develop is your "BS detector." This tool will enable you to detect the bad clients and walk away from them in advance.
The other thing to add is a "attorneys fees clause" so if you do have to sue you can collect your attorneys fees as well.
I believe that's the "Legal Costs" clause which is mentioned in the article.
If your client puts this term in the contract, walk away.
Most clients understand this. What they really need is a license to the software, which can come with things like the code, a license to modify the code, a license to sell or transfer the code license, etc, but none which deprives the contractor of his cumulative work. Clueless and overreaching lawyers though will often give advice like "only a complete sale of copyright is acceptable", which basically means you're going to be employing clueless inexperienced contractors, dishonest ones who will "sell" you open source stuff they've found on the net, or will be weighed down by the enormous time and money cost of reimplementing everything from scratch. Clauses such as "including but not limited to [work done] during the duration of the Project", we see a contract written not by a lawyer who is simply clueless about development realities, we instead see a bad faith contract that specifically intends to grab ownership of preexisting frameworks and libraries.