You did it! You finally bit the bullet and contracted a custom software developer to build a custom application for your business. It has automated your workflow, increased process efficiency, and is saving you time and money. But now you see that if it just had an extra ‘bell’ here and a ‘whistle’ there, you could be saving even more.
You decide to contact your developer, but he’s working on a big project and doesn’t have time. So you say, “that’s OK, I’ll just get the code and be on my way to another developer.” But then he says, “no you won’t because you don’t own the code.” Hopefully, you’re reading this article before that happens to you.
Whether you realize it or not, when you deal with anything creative, you have to think about copyright and intellectual property (IP) on that work. And that includes the creation of software code.
The Main Factors to Consider with Code Ownership
When we talk about code ownership, we’re talking about who gets to use the software after the application is coded, and more importantly how they get to use it. Legally, we (the developer) have copyright and ownership the instant we write the code. If we held onto it in the true sense, then no one would ever be able to use it, we’d never make any money, and there really wouldn’t be any point to writing it in the first place. So the rights associated with use MUST be spelled out to allow the code to have any value–for both parties involved.
Code ownership can be broken into 3 distinct types of use.
- Using the code for its intended purpose: This is usually the reason the code was written in the first place. The definition of this use discusses how we have relinquished some rights to you (the client) in the form of a license or ownership to use the software in its intended manner. Often this is the part that is just “assumed” by both parties, but it really needs to be spelled out distinctly before the project starts.
- Maintaining the code for its intended purpose: This is often one of the first areas of conflict. The client wants there to be a change in the function–either an update to keep it fresh, or a new enhancement. Therefore, the code must be altered or changed. Who has the ‘rights’ to make that change? Does it have to be the original developer? Or can the client take it to someone else? In this case, it’s best for you to have some ownership, otherwise, you’d have to go back to the developer for every fix.
- Reusing the code for another purpose: If you wanted to resell the code or even use it for another project, you’d have to have proper ownership rights. For developers, it’s a great way to be efficient and save other clients some money in the process. For the client, it’s a way to keep potential competition from having a shortcut toward duplicating what you have done or to recoup some cost on their investment.
So what’s the best solution for the client AND the developer? Well, there are many schools of thought on that. Here are some of the arguments often used.
Argument #1: The Client Should Own It
The most obvious reason; after all, you paid for the work! Large chunks of the code were written just for you. So obviously you should have ownership.
And what if you want to leave the relationship? You have your own company and your own life. You shouldn’t have to be tethered to a developer just because they built it for you. It’s like a car. Yes, you’ve bought a specific make and model, and you enjoy driving it, but that doesn’t mean that you should be stuck with the dealer you bought it from as your only mechanic. By owning rights to the code, you have the freedom to alter the code as you see fit, or to have someone else alter it if you so choose.
Argument #2: The Custom Software Developer Should Own It
As developers, we don’t magically spin software out of thin air, even if it might seem that way. All custom web application development starts with our kernel; the core set of code that we’ve spent years refining and improving. If we just give that away to clients, then we run the risk of one overly protective client blocking us from ever using it again.
And there’s more than just the core code. Our over-caffeinated minds will churn out any number of creative ideas during the course of a project that isn’t specific to one client, things like better security models or automated code generation methods. Holding onto ownership lets us hold onto these innovations.
Truth is, this also helps our clients. Our code is stronger, so they get better software. We don’t have to spend as much time coding, so they don’t have to pay as much. What client doesn’t want a better product for less?
And don’t forget about the sanity of our developers. If we can’t reuse code, then we have to start from scratch every three-five months. As you can imagine, that’d be a little rough.
With all that, why wouldn’t the developer want to own it?
Which is Right?
Can you see the problem? Without talking it through, you may have one side really disappointed.
At AxiaTP, we realize this challenge and work to put the most common solution into our contracts by default.
What Really Needs to Happen
In the end, the way this works is with clear communication between the developer and the client. Both sides need to be upfront and as clear as possible about what they want and need from the project. This will help the developer tweak their agreement accordingly.
Are you afraid of losing a competitive advantage? Then add a clause so the developer can’t use industry-specific code on projects with competitors. Is either party going to use the project as the foundation for an industry platform they plan to sell? Then this should be discussed right from the start. In addition to rights, the software will have to be built for scalability, security, and to easily grant rights to others.
The more honesty and discussions upfront, the better it will be, both for the product and the parties involved.
It’s how to ‘crack the code’ for a successful custom software experience.
Quick disclaimer: We’re not lawyers, and this isn’t legal advice. We’re just giving you some industry insight from a software specialist.
But, if you’d like to know more about custom software development from a software specialist, then contact us. We’re happy to answer any questions!
