Who owns your code? Probably not who you think.

Seven years as an engineer and eleven as an IP lawyer taught me that most start-ups don't own their product. Here is how to check, and how to fix it before an investor does.

In 2010 I watched a colleague leave the company where we both wrote software and take two years of our work to a competitor. Nothing could be done, because the paperwork that should have said the company owned that work did not exist. I went to law school the next year. Fifteen years on, the paperwork is still missing from roughly half the companies that walk into my office, and the founders are always surprised.

The default rule in the United States is simple and unforgiving: the person who writes the code owns the copyright in it. There are two exceptions. An employee's work, done within the scope of their job, belongs to the employer. And a contractor's work belongs to the company only if a written agreement assigns it. Not 'work for hire', which for software is narrow and unreliable, but an actual assignment: 'Contractor hereby assigns to Company all right, title and interest.' If that sentence is not in the agreement, the contractor owns your product.

So the first thing I do with a new client is ask three questions. Who wrote the code? Were they employees or contractors at the time? Where is the signed paper? The answers are often: a friend who helped at the start, a contractor, and nowhere. That is fixable, but only while the friend is still a friend.

The second thing I check is founders' own contributions. Many founders write the first version before the company exists. That code belongs to them personally, not to the company, until they assign it. Investors' lawyers will ask for the assignment in diligence; better that you find the gap now, when it costs a signature, than in a funding round, when it costs leverage.

The third thing is open source. Every modern product is built on it, and most of it is fine. But some licences, the GPL family in particular, attach conditions to the code that incorporates them, and a buyer or investor will run a scan. Run it first. Knowing what is in your product is not a philosophy question; it is a licensing one, and the answer is in your dependency file.

The fourth thing is the commit history. If someone ever walks out with your work, the version-control log is your evidence: who wrote what, when, from which machine. In 2017 that history got a two-person robotics company an injunction in eleven days. Protect it the way you would protect the books. Do not let anyone rewrite it, and keep backups the departed cannot reach.

Fixing all of this is unglamorous. Confirmatory assignments from every past contributor, a standard contractor agreement with the magic sentence, an invention-assignment clause in every employment contract, a dependency policy, a backed-up repository. A week of work for a small company. I have never seen a company regret doing it, and I have seen several regret not.

I was the engineer whose work was taken. The company I worked for was good, the people were good, and none of that mattered because the sentence was missing. Put the sentence in.

intellectual propertystartupssoftware
Written by Samuel Byrne

Former software engineer who protects the ideas of people who build things.

More from Inkwell

What a community bank should do when a customer's business is in trouble — Daniel Reyes

You should never have to guess what you're paying for — Hannah Weiss

How to read an annuity contract — James Whitfield