I understand that I/WANAL & YMMV etc. but it would be nice to see what people are using themselves.
I come from a field, AEC, which in the US uses a lot of standard contracts. The AIA contracts, though not the only option, are very common and have been developed over the course of 100 years.
The architecture series start with B. These are, in my opinion, a good model for a software consulting project because:
+ Neither party really knows the full scope of the work when the contract is let. As my mentor Ronn Ginn told me, two people sit down and sign onto something about which neither has much of a clue. This of course emphasizes that an agreement is really a matter of trust not which court to go to.
+ Client objectives change during the process. The contract reflects it.
+ Intellectual property rights are clear. The architect retains the copyright. The client is granted license to use it for the purpose of the project. The license is predicated on payment.
+ Terminating the contract for convenience is a distinct possibility. The contract acknowledges that.
+ One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.
+ Both parties are likely to contract with others during the course of the project [architect with consultants, owner with builders]. The contract acknowledges that and one of the reasons for using standard contracts is because they all fit together. But that's too much to hope for here. The idea of acknowledging the possibility of other contracts and taking them into account is what matters.
The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects.
Having written a lot of proposals and contracts over the years, I've learned that selecting clients matters more than what's in the contract. Red flags really are red flags.
Good luck.
Is that really common in your field? What's your field's price tag between doing full IP assignment vs. a license-only?
AEC = Architecture, Engineering, Construction
AIA = American Institute of Architects
Assigning copyright in the US AEC industry carries additional complexity since architects and many of their consultants are licensed professionals and therefore are professionally liable for their designs. Part of the responsibility that comes with licensure is maintaining professional control of the design. By assigning copyright the architect and their consultants might maintain liability for its execution in contexts of which they are unaware, e.g. where soil conditions or sesmic loads differ from those on the site for which the building was designed. Legally architects cannot reassign their professional responsibility...that's what makes it professional.
An analogy in software might be Software as Service in particular and licensing in general. The Software industry already has retention of copyright as the common mode of agreement.
Going further, full assignment of copyright to the client just turns the problem around. If I assign the copyright to the design to a client, I need to obtain a license back in order to use similar parts and pieces in other projects, e.g. a detail for a door jamb or the profile and reinforcing of a footing or more directly the "drawings" that show them. Likewise a software engineer needs to be able to reuse foreach foo in bar without consulting a lawyer.
While there are exceptions, it's simply easier to negotiate a useful set of licenses without transfer of copyright than to include that in the negotiation. Functionally, if the client can do anything with the work except reassign copyright the vast majority of cases are well served.
The price of full assignment? The question correlates to a Kremlin on May Day with Brezhnev in the reviewing stand parade of red flags. Screening clients is critical.
I usually take it to mean the process of building buildings and making sure they won't fall down, but that may be oversimplified from someone who actually works in that industry.
But for anything more advanced it would be wise to have the option of using the software in other projects to save time and money.
I love this one. Anyone have ideas on how to apply this to software development? I really hate it when clients say "I want X" and I have to take an inordinate amount of time telling them why X is a very bad idea both in terms of effort and value. Generally this is during scoping so I have no way of billing for the time.
But I think we can go too far emphasizing pleasing the client sometimes. I don't think it's so rare to see genuine conflicts of interest, like squeezing for unreasonable deadlines and scopes, where the problem can't really be solved by just charging more.
If a client makes overly aggressive demands and won't listen when you take the time to tell them politely what you can do, is it better to be exploited mercilessly and risk breach of contract, or to cut your losses, swallow your pride and find another way to pay the rent?
In some ways, software will always be harder because the artifact in a construction project is the building not "the blueprints". If the design is dragged out, the building doesn't get built.
On the other hand, the way an architect handles "I want X" is by showing them that it is a bad idea. Showing means providing a design that incorporates "X" and one without. The assumption that everything will be done multiple times before it is right, and indeed that doing it multiple times makes it better, is what separates architecture from engineering in AEC.
Understanding that doing things multiple times is just part of the job and that falling in love with one's own ideas is a bad habit can be learned. It ain't easy. But in the end, the architect walks away and the client lives in the building. Software is similar in that way.
Your ability to tease out what really needs to be done from a customer's hand-waving wishlist of vague features is a key component of what you are being hired for. That skill is worth more in general than straight coding, and should be compensated accordingly.
- the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out
- if the client has to read the detail of the contract, it's probably too late to save the relationship anyway
- maintaining the relationship is everything, being honest and open and striving to maintain a service that is genuinely useful to the client, even if you're not always perfect.
I do have a contract with one client but any questions about it have been about the 'spirit' of it, not the detail.
Pricing is everything: if you're too cheap, you'll struggle to deliver and will not meet expectations. Too much, and you'll lose out to your competitors.
Contracts are not just for 'the courts'. It is a standard business practice of having some clear terms for the both parties. Not only that, but any company who could sue and, 'wipe you out' already has their own contracts and NDAs, you not showing up with one just looks unprofessional. It should be also used as a place to outline your workflow and what the client should expect from you. Clients love this, trust me.
To tell new developers that, 'go ahead and put 5K-50K of your earnings on good faith' is just a dangerous thing to say.
A week later you get back from your totally offline trek through Nepal to find angry voicemails and emails from the organization now depending on your software, and you're now facing a $10M lawsuit from the new management for losses incurred due to your software breaking.
Long story short, your liability isn't limited to the relatively small amount you were paid for the work. And because you didn't have a contract, you could be held personally liable and risk losing your house, retirement savings, etc.
This should include the work to be performed, payment schedule and penalties for late payments (which are generally covered by usury laws, the workaround is often to offer a discount for early payment), what copyrights are transferred and when, responsibilities for providing assets, acceptance criteria, liability for defects, severability, and controlling law. Non exclusive list written from memory, IANALATINLA.
Relationships may be important, but that does not mean automatically getting screwed if the client decides to. A well-written contract protects both parties. We need contracts because this isn't a perfect world, things go wrong all the time, and it's very easy to burn relationships unless you both agree about what to do when things go wrong, before the lawyers start getting involved. And again, if it does get to the point where the legal letters start flying, without a contract you are going to be severely limited in terms of recourse.
Another way to look at it is that without a contract, you are both taking on risk; the risk of not being paid is probably the biggest factor. If you can avoid a $5k to $50k risk by spending a few hundred dollars, why wouldn't you?
If you need more than my words to convince you, I suggest either reading clientsfromhell.net, or watching "Fuck you, pay me." http://vimeo.com/22053820
Discussing contracts is also a good way to screen clients. It can provide a tell that allows separating people who don't sign contracts from those whose word is their bond. The latter have no trepidation entering a contract.
Everyone who releases open source code uses contracts, which all limit liability. Contracts are hardly something just for rich folk.
> "the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out"
Just like lines of code are not a measure of quality of software, hourly rates of attorneys are not a measure of the quality or effectiveness of their legal representation. The only time that you are on equal legal footing with a large corporation is when you're both entering the relationship. If you and a client sign an agreement defining and limiting the work and your liability, a more expensive attorney isn't magically able to rip that contract up.
> "if the client has to read the detail of the contract, it's probably too late to save the relationship anyway"
I couldn't possibly disagree more. If a client isn't willing to work with me on defining the scope of the work to be done for both of our benefits, then I have no faith that they're going to work well with me at all, on anything. For a software developer, a scope of work is also just another piece of documentation: here's what I'm building, and what it does and does not do. A client should be as eager to define that as you.
Case in point: a bank recently suffered a data breach and had to spend more than $150k to comply with its notification obligations, and the bank's insurance company sued the bank's web design firm for, as they allege, failing to do proper servicing, security updates, etc[1].
Web design firms doing ongoing security, monitoring, and maintenance is totally not the norm. Usually the design firm designs the site, either has a couple developers in-house or contracted to another company to build out the front-end and do any integration with the bank's back-end, and when it launches, all is over. But here, this small midwestern design firm with a few employees is on the hook for damages and their reputation will be destroyed.
There are many details lacking in the civil complaint in terms of what their actual responsibility was, or if there even was an agreement in place. But if the design firm had a master services agreement that (a) disclaimed responsibility for doing security monitoring, updates, malware fixes, backups, contingency planning, and any costs or lost business as a result; and (b) limited liability to the amount of money the bank paid the design firm (a common business practice); and (c) indemnified the design agency against any claims by third-parties; the complaint probably would have never been filed.
None of this is legal advice, but don't risk having your reputation destroyed and being personally bankrupted simply because you're desperate for work, lazy, or unrealistically optimistic about people having good faith in all situations.
[1] Article with linked PDF civil complaint: http://www.scmagazine.com/travelers-accuses-web-firm-of-shod...
We then share the recordings with them, along with a written summary of the agreement.
Fortunately we've never had to go to court, but I'm told by my lawyers that this will hold up just fine. It also seems to breed a more organic agreement than a sterile, boilerplate contract.
Typically, I'll still sign their boilerplate, but I ask that things like NDA, work-for-hire, and non-compete are either eliminated or toned down such as to still clearly permit unmitigated action in the open source space.
The last time I did a "recorded contract" was over a year ago, which makes me now feel sheepish about saying "these days." :-)
I don't think it will be the last though, and I do highly recommend it.
Someone might have an objection to a boilerplate contract and this is always too much of a coming/going between lawyers of both parts.
With a personal discussion you can get whatever interests each part and get to an agreement faster.
https://gist.github.com/malarkey/4031110
I like the plain language of it. For me, contracts are a necessity. The way I see it is that people who want to not pay, won't pay. You'd need an army of lawyers to craft a bulletproof general purpose contract. Instead, I go by a mutual understanding sealed by a simple contract.
From what I understand, the best tool/weapon you have is a clause that says that copyright assignment from you to them happens upon receipt of full payment. That way you hold their work until you get paid. YMMV and IANAL.
More information on Agile Contracts:
http://www.jeffryhouser.com/download.cfm/dir/software/file/c... . I do not know if the article is still available anywhere; it is from 2005. [Maybe I should update said documents; but primarily very little has changed]
Bigger clients will have their own contracts [and sometimes very little negotiation room]. I've drive some clients crazy w/ negotiations and about what rights I refuse to sign away.
Update: Here is the original article I wrote http://www.jeffryhouser.com/enclosures/DeconstructingConsult... [I guess it was 2007; not 2005]
I've seen IP ownership clauses that say the client owns everything I create, whether or not it was done for them. These clauses are written in such a way that the client could claim ownership of work I did for other clients, my blog posts, podcasts, books I've written, and even things that have nothing to do with tech, such as songs I've written and/or recorded.
I try to make such IP transfer clauses as specific to the work I do for the client as possible.
Caveat: I've only used it with one client, with whom I have a prior working relationship.
I negotiate the terms, make local commits, and include the commit hash on the print-out.
Been using this one for a few years, wrote it with some mates, never had any issues. Attached some design images as well as the text.
Fork and modify. I accept PRs too ;)
http://www.shakelaw.com/legal-info/freelancehire-agreements/