Ask HN: Who owns the code?
I never expected to do this but here we are 3 people creating a startup. Two of us are programmers, building separate parts of the system (frontend/backend) and the third guy is designer/investor.
We are trying to draw an agreement as part of the documents to establish the company legally. One of the issues we don't know what to do with is the question of intellectual property. Does source code belong to company or to programmers? Can programmers use the code (functions, libraries) in other of their projects?
I proposed that the code belongs to the company but the author is allowed to use the code in other projects that are not similar to our company project. The other programmer disagrees and thinks that the code should belong to its author.
What are the common practices regarding this?
Thanks.
12 comments
[ 3.4 ms ] story [ 31.1 ms ] threadAlso, everyone's being a just a little cautious here, AFAIAC. Make a killing with your business, don't haggle over code ownership.
What I would love to hear is some experience or consequences that could result from assigning code to the company and also from not doing it. I'm sure both ways have their minuses.
Furthermore as soon as programmers start touching each other's code, they no longer have the legal benefits of ownership. So they have the choice between licensing code to each other (winding up in the same bind as the company), or else refusing each other's changes for their personal benefit (which will be a nightmare for the company).
By contrast if you go the standard way and assign copyright to the company, the company has no such potential headaches. Programmers who wish to use company code have to get permission to do so, but they only have one party to negotiate with. And programmers have no copyright incentive to block each other's changes. This is better all around. Remember that the goal of a company is to reduce the necessary friction in getting work done. Do whatever reduces possible friction the most.
If programmers are bringing useful code from elsewhere to the company that they plan to use elsewhere, then I would recommend having them either license it to the company under very generous terms, sell it to the company and get it licensed back, or rewrite their software. (Rewriting will likely take much less time than they think it will.) But in the end the company really, really needs to wind up with code that it controls and has full freedom to modify in any way that it wants with a minimum of intellectual property encumbrances.
If you don't own copyright on your own software, you'll also find it hard to sell the business in the future. Potential acquirers are usually interested in purchasing the IP owned by a company, not just the company itself.
IP that a company owns can be counted as an asset when drawing up a balance sheet. It is often quite a substantial part of the assets of any major software company, making the net value of the company much higher.
In my experience, companies usually default to owning the intellectual property for everything an employee produces then provide a way to waive their interest on outside projects by employees. The IP waivers require the employee to specify the scope of their outside work and get approval from the company directors so that the company's IP rights are waived on that code.
Choose an appropriate free software license. I would suggest AGPL v3.0 (or later). Assign all code to the company but include an escape (consult a lawyer) so that each of you has enforcement rights should the company go away. Explicitly agree that all of that code is, by understanding, considered to have been distributed to each of you as individuals.
Such a choice does not obligate your company to share source however it gives any of the three of you the right to share source. It gives each of the three of you freedom to use the code.
Some investors, I would think, might have some trouble with this. For example, a founder could quit, fork all of the code, and start something else. For reasons like that I think the suggestion might inflame some. I suggest that if you presumably all trust one another enough to get to a point where that threat is no longer particularly significant. And that threat ought also to be weighed against the degree of difficulty of someone else doing a clean-room substitute for the code, anyway.
But if you're not, then whatever makes you comfortable works. Just make sure (and it's important) to have in in writing and reasonably solid.
The company should own the code. I would recommend not granting rights beyond that. You can always package parts up and open source them.
Don't labor under the illusion that your code is a beautiful, unique snowflake...