Ask HN: Programmers, how do you handle Copyright and IP in your contracts?

IANAL however my lawyer wrote up a very nice standard contract for me, and you should have your lawyer do the same. Mine basically states that I use open source libraries and code and that those libraries and code are licensed under the appropriate licenses and are governed under the appropriate laws for the countries and jurisdictions in which the software is being held or used. All code specific to the client, that does not fall under an open source license as provided previously, is owned by the client in full including the right to resell, modify, change, or destroy. As soon as the code is written, it belongs to the client. There are a number of other statements, but again you should get a lawyer to draft you a standard one real quick.

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.

programmers don't

I recently started freelancing so I bought a standard contract for the Swiss market where I'm based. There is a clause for the copyright and licence that basically says:

- 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.

Through some rough lessons I no longer take on many projects that I am personally developing outside of a day job. In general, I bill $x per person:block:day (being each day that I work on something 0-4 hours, and each additional block capped at 4 hours)... Anything that is not a core part of the product (business logic, or specific design elements) may be abstracted away, reused and/or released as open-source. I will also use, as appropriate already written open-source code that won't elevate the risk of said project (no agpl, only gpl if it's a server-side solution). Once a solution is finished and paid in full, any copyright over the solution will be signed over, and will not include outside libraries, even those written to help with said project. I emphatically do not believe in Patents on software, so will not apply for or assign any such rights on what I develop.

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.

I create computer vision solutions. I wrote a camera abstraction class which I use for multiple clients which I open sourced [using "WTFPL" (1)].

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.

(1) http://en.wikipedia.org/wiki/WTFPL

You should probably have your own lawyer draft something for me, but here's some of my own standard language. Basically, it grants the client an unlimited license while maintaining all intellectual property rights. It also acknowledges that I bring intellectual property to the table when I start and that in no way belongs to the client.

"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."

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...