A poster to Y-Combinator’s Hacker News forum asked an innocent question:
“When working directly with a client or as a freelancer, what do you include in your contract about Intellectual Property and Copyright?”
The conversation that followed reminded me an an all-too-familiar discussion. To paraphrase:
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?
The answer is ,of course, a combination of all three approaches:
1. Don’t just rely on a standard form document
You’ve heard of the principle “Garbage in, garbage out”? It applies to contracts too.
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
I am a hobbiest developer. I understand enough to have fun. Sometimes I use complex frameworks, such as RestKit for iOS. I could not hope to understand them in detail without more education. I wouldn’t be able to support them as part of a commercial development. So, I only use them when the risk is very low… i.e. only for my own prototypes of personal projects.
I’d recommend the same approach for contracts. By all means use standard form contracts to help understand how contracts work.
Yet when your livelihood is on the line, engage 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, like many developers, you probably keep your own toolkit or framework. You might add to this as you work on specific client engagements, but you want to be free to re-use those additions for other clients. That's the point of a toolkit.
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 merely an improvement to your general toolkit.
3. Insist on understanding
Sometimes lawyers will use terms of art, such as 'Background, Foreground and Sideground IP'.
Contract negotiations are often time-pressured. Such phrases can be useful shortcuts. They are generally understood in the legal profession, not least by the courts.
However, as the IPKat blog points out, 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 it.
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 you.
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:
the "Client's Software", of which you would assign ownership to your client; and
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. So, the answer is better commenting. Who'd have thought?
NB. This post obviously doesn't deal with other issues of IP arising: patents, open source, and third party IP. Again, getting expert help is essential.