IAAL and I come across discussions like these from time to time:

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?

In my view, the answer is a combination of all three approaches:

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.