Who owns the code?
Contract developers save Kevin Partner from a digital lynching, but open source software could be the key to his long-term survival
My recent column “Paying for code doesn’t mean owning it” kicked off an interesting debate, which to begin with felt like a digital lynching with comment titles including “You wouldn’t work for me” and “This is a shady practice”.
Other people weighed in to restore some balance, though, and broadly speaking the developers sided with my point of view and the clients against it. Not surprisingly, given the complexity of the issue, there was misrepresentation and misunderstanding of what I’d said.
It isn’t fair is for the client to benefit from my library code via reduced costs, then also expect to own that code
To recap, I’ve created a set of standard libraries that are embedded in a number of my clients’ web applications, and I can’t sell exclusive ownership of that code to any one client since that would also confer ownership of, say, 25% of the code of other clients’ applications.
However, my toolkit code is object-oriented, so the fact that no client owns an unencrypted version of the source doesn’t prevent them amending or updating the custom parts of their application – they can simply replace a call to one of my objects with a new method. Most clients are happy to enjoy the benefits of this library without needing to own it.
In that column, I pointed out that the intellectual property rights to code I write for clients under contract remains with my company even after the client has paid, but in practice I’m happy to agree with the client to hand over the source so they can change developers if they wish: this might include a formal transfer of ownership of the unique parts of the code, or simple agreement to share ownership. What isn’t fair is for the client to benefit from my library code via reduced costs, then also expect to own that code.
I’d be the first to agree that contracts are a good thing, but if a client needs the job within, say, three weeks, it isn’t sensible to waste the first two in contract negotiation.
My standard practice was to draft a “letter of understanding” that states what’s been agreed, but sometimes there isn’t even time for that. In my experience, being reasonable, prepared to compromise and acting with integrity all influence the success of a project more than the most watertight contract, but even so I’ve decided that proceeding without one is no longer viable, having just been shafted by a client who refused to pay their final instalment (even though in this case a contract did exist). I shall be much tighter on this in future, even if it means losing the job.
So what’s the answer? I can think of several, the first being to replace my in-house library with a third-party open-source framework. For PHP projects this might be CodeIgniter, and I now use this in all new projects.