Paying for code doesn’t mean owning it
Kevin Partner tackles the thorny issues that surround code ownership
If there’s one problem (after lack of cash, of course) that blighted the first ten years of my company NlightN's existence it’s code ownership, which has become more problematic as most of our work is aimed at web deployment.
Ten years ago, we were creating e-learning courses that we’d deliver on a CD-ROM containing a compiled version of the software, which was usually based on Flash or Mediator. Our clients understood that if they wished to update the course, they’d do so through us. These days, however, many clients believe that by paying for the work to be done, they own it.
On the face of it this might seem reasonable: surely if you pay for something then you own it? Not if what you’re buying is an end product, rather than the work itself or the tools used to create it. If I buy a bible, I don’t own the original Lindisfarne Gospels; if I pay a plumber to fix my tap, I don’t ask him to leave his toolbox so I can fix it myself next time; if I buy Harry Potter and the Half Blood Prince on Blu-ray, I don’t own the movie but only a copy (whose usage is restricted by the terms of the licence); if I buy Microsoft Word, I own one copy of the compiled code, not the source.
Put simply, code is owned by its developer even once the client has paid, unless that developer is legally employed by the client or a contract exists that transfers full ownership (even then it’s far from clear-cut). The client has paid only for the results of the labour: for example, if a client commissions us to build an online quiz app, they pay for and own the working application, but have no rights over the code itself.
One problem is that if you’re working in an interpreted language such as PHP then your code isn’t compiled, so in practice your client does receive source code and can do what they like to it, even though they have no legal right to
One problem is that if you’re working in an interpreted language such as PHP then your code isn’t compiled, so in practice your client does receive source code and can do what they like to it, even though they have no legal right to.
It might seem that ownership remaining with the developer is unfair to the client, but then consider the alternative. Most developers will have created a library of custom code segments they use for every project: for web applications, such a library might include functions to handle database connection and interaction in a way that makes sense to them and so speeds up subsequent projects.
If you give away ownership of this library code you’re giving away your “tools of the trade”, just as much as that plumber would be by leaving his toolbox behind. Your libraries give you an advantage over other developers in terms of the speed with which you can complete work and, therefore, the price you can charge.
This is a commercial advantage you must protect if you’re to build up a viable business. A second problem with giving away ownership of that code is the way it would affect previous projects for other clients that use the same code – you could argue that client two would end up owning part of the code originally put in place for client one.
So that’s the legal position, the code belongs to you unless contracted otherwise, and it’s very important you bear this in mind when negotiating with clients. I’m not saying never hand over ownership to a client, I’m saying remember that ownership of the code has a value and you should expect the client to pay for that.