The only example contracts I've found (like the very popular Contract Killer [1]) talk about assigning design rights and nothing about the code.
Do you have your own code library you port between projects?
1. http://stuffandnonsense.co.uk/projects/contract-killer/
The question often comes up among my colleagues about the statement that says basically the client owns the code immediately. "What if they don't pay?!", they say. Well, ownership is 9/10 of the law... and if the client owns the code but doesn't pay it is much easier to legally pursue payment.
I think the developer should own the code but the client should also be given all rights to use, copy, distribute, resell, or both parties could be given exclusive rights.
And then there is the matter of by-products which are pieces of code you develop during your contract time but not necessarily used within that project because somewhere along the line you've discovered that it is something you can use elsewhere and does not make much use for that specific project.
Who owns those? From your contract's perspective, the client owns them and you are obliged to deliver them whether or not they end up in the final product.
I'm not trying to be dismissive of your lawyer's knowledge in the area, and neither am I a lawyer, but I think it is kind of hard to write down a standard contract that can be applicable to all projects. Contracts should be negotiable and license/IP is something as negotiable as the contract fee. And your contract sounds too protective of the client at your cost.
I DID charge my client to implement the library within their project. This implementation belongs to them immediately.
Now I, of course like many engineers, use similar ideas across clients. However, these are rewrites in one form or another. Frankly I have never read a line of code (my own included) that I did not hate and think I could do better. So I don't have any issue with rewriting code for a client that does something similar to another client I had previously. They own that code and I charge them (quite a bit) for it.
Negotiation can take a very long time and that time is unpaid. I would prefer to have a good solid pipeline of clients who use a standard contract and a shorter time from negotiation to signing then having to renegotiation every contract that I come into contact with. And yes my contract protects my clients quite well. Which is why I have a lot of repeat business and get paid regularly, without fights, and on time.
This is by far the most no-bullshit and the most mature point of view I've heard on this matter.
I can talk to a lawyer, but I'm not after the legal view. What I'm interested in is the pragmatic view - it's pointless to claim legal rights in the contract if no client will sign it.
- I keep the intellectual property for the code that I developed myself.
- If I use third party software or libraries, the owners of the libraries are keep all their rights.
- The client gets all rights to use, copy, and modify the software I provide. Basically, there are no restrictions on the use they can do of it within their company. I give them exclusive rights to that software and I cannot sell the same software to another client without consulting with them.
There are other clauses that are there, but those are the three I judge more important. It is important to keep the intellectual property because that way I can always reuse snippets of the software I developed in other projects.
"Client shall have a perpetual, irrevocable, nontransferable license to use and copy the materials and deliverables created, discovered, invented, developed or prepared in the course of this agreement (“Deliverables”) and prepare derivative works based on the Deliverables for its internal use. All other rights in the Deliverables remain in and/or are assigned to Consultant. Client acknowledges that the Deliverables may in whole or in part be created using Consultant’s prior acquired knowledge, skill and expertise, and may include Consultant’s proprietary information and prior developed intellectual property of Consultant, which Consultant shall continue to own and have an unrestricted right to use for other purposes. Consultant may retain archival copies of the Deliverables for Consultant's internal use, and nothing herein shall prevent Consultant from continuing to use Consultant's information, knowledge, skill and/or expertise for other purposes."
I don't charge my clients for the time spent on open source code that I write for their projects but realistically, I'm giving them free labor. It just seemed like more of a hassle to license it to them at the time.
For my current client, I wrote a library that I license to them for a fee. When you license a library it is a lot easier to charge by actual value delivered than by charging by the hour. We agree on an acceptance criteria, they test it to show it passes, the pay me and then they get the source.
The code I write for a client becomes the property of the client upon payment. This is an important thing to have in your contract.
I had a local lawyer draw up my contracts. I spent some time on the researching internets making a rough draft of what I wanted as this gives the lawyer a list of things that I wanted to capture in the agreement.
As an aside, I insist on a "10 day net". After 10 days out, the rate is increased by $50hr i.e. if I billed at $N per hour and they take more than 10 business days to pay, they pay me at $(N+50)/hr.
For the most part when you talk to a client openly about how software is assembled and crafted, and that their part of the product will be theirs, and that you will deliver a finished product while also respecting the larger development community in contributing back, it's usually a smooth process. These days we, as software developers, tend to use large amounts of mit/gpl/isc/apache and other openly licensed software/libraries, that when you explain that what's out there saves you time, and giving back saves everyone time, it's usually less friction.
I also expressly do not bid on entire solutions that are not well defined, or are too strictly defined. It tends to become a time sink if you do. And prefer to bill in blocks/day against a deposit against the estimated work/time. I also make clear that what I give is only an estimate, and actual billed blocks may vary depending on changes through the lifecycle of initial development.
----
As far as a day job... I tend to line-out anything that can be construed as assigning rights of work I do outside of the office on my own time, or Patent assignment. As a rule, I only interact with hardware through defined software interfaces. If I were building/designing custom hardware to accompany the software I might have a different stance.
----
If you are uncertain, or unsure of how to establish a written contract, as always you should contact a lawyer.
Person A: I’m using a standard contract I found on the Internet. I like it because it’s written in plain English.
Person B: You shouldn’t use any old contract you found on the Internet. How do you know that it is legally effective? My lawyer has produced a contract for me. I don’t understand it, but my lawyer has assured me it’s fine. Here’s what they told me…
Person C: Your lawyer has taken a simplistic approach. How are you sure that it meets your needs if you don’t understand it?
1. Don’t just rely on a standard form document
The principle “Garbage in, garbage out” applies to contracts too.
I always suggest that before looking at the document, work out what your objectives are.
In the context of 'IP', a typical objective of a software developer might be:
"I don't mind giving my client ownership of the specific code I write for them, and the graphics and other resources I create for them, but I want to keep ownership of my framework, libraries and snippets."
2. Get some help
When your livelihood is on the line, I’d always recommend engaging professional help.
A good technology lawyer will help you achieve your outcomes by drafting the right contractual terms and helping you work through edge cases.
For example, do you want to own any improvements that you make to your framework during the course of the engagement, which at this point are purely for this client but could be used for other clients later?
In my experience, the answer is probably "yes".
This is at odds with many standard form or precedent contracts, which say all the developed software belongs to client. Sometimes they include an exception that you can keep ownership of your 'pre-existing' software. Pre-existing software is usually defined as software that exists at the time you sign the contract. Under a contract like this, any code that you produce after signature will belong to the client, even that code is an improvement to your general framework.
3. Insist on understanding
Sometimes lawyers will use terms of art, such as 'Background, Foreground and Sideground IP'.
These phrases can be useful shortcuts. They are generally understood in the legal profession, not least by the courts.
However these terms do not have a fixed definition in law.
They are familiar tools – snippets if you like – but they are just words, and still need to be tailored to your particular contract.
For example, I usually dispense with ‘Sideground IP'. Who has ever heard of a ‘sideground’? I wrap up framework and library code into the definition of ‘Background IP’ instead.
In any case if you - as a developer - do not understand how these terms apply to your project, insist that your lawyer explains.
The law is a technical discipline but it should not be a black art. It’s critical that you are sure that these definitions work for your use case.
Alternatively, you could ask your lawyer to re-draft the provisions in plain English. After all, a written contract should merely be a record of what the parties are trying to achieve. For example, you could differentiate between:
(i) the "Client's Software", of which you would assign ownership to your client; and
(ii) the "Developer's Tools and Frameworks", which you own but grant your client a perpetual licence to use them with the Client's Software.
This is easy enough to draft, but takes a little more care than using an off-the-shelf precedent.
It is important to note that any deliverable can contain code that is "Client's Software" and other code that is "Developer's Tools and Frameworks", potentially even within the same file.
The contract will apply to each set of code as a matter of fact, but it is even better if you mark or comment the code so that it is clear.
NB. This post obviously doesn't deal with other issues of IP arising: patents, open source, and third party IP. A whole other ball game.
This post is not legal advice, of course.