When you are working with a software developer, it’s vital that you come to a clear arrangement in the beginning. You want to know how data will be handled, and most importantly, who owns the actual data.
There are countless ways that agreements are designed between clients and developers, so it’s crucial never to assume that you own what you pay for. Watch our video to better understand what is involved in clarifying boundaries, protection and defences involved in the creation of your valuable software project.
Video Transcript:
Intellectual Property and Software Development
What is intellectual property?
Intellectual property is property that relates to creations of the mind. I need to preface this by saying, I am not a lawyer. The following is not legal advice and you should not take it as such.
Having said that, I have spoken with an IP solicitor as recently as this week and I have been working in this industry for a while. So there are a few things that we’ve come across. The general understanding as I am led to believe is that intellectual property exists in an artifact. So an idea is not intellectual property. If you speak that idea into an audio file on your phone, you have created intellectual property because you now have an artifact. If I write code that someone can copy I now have intellectual property. I have an artifact that is copiable.
I want to give you some perspectives that different people take in the development space around IP.
Negotiating IP for your IT
As the business owner, the standard approach is, I paid for it, I own it. I paid you, I paid you a reasonable hourly rate, I own the intellectual property for what I bought. That is the standard approach people would take.
A reasonable developer, and I would like to think Alliance Software is a reasonable developer, would often take a slightly more nuanced approach. Developers would say to themselves, we work with lots of clients. What we’re going to do is, we have a base foundation of code that we roll from project to project. The reason we can be competitive versus someone who hasn’t been doing it as long as us, is we’ve been building up this background of IP that we’re going to roll into every project.
It’s things that you don’t care about. It’s things like I want to quickly access my database. I want to pull databases and quickly display them on screens. I want to be able to work well on mobile phones. These things are equally true if I’m doing a timber manufacturing business or an HR business. It’s those background pieces. So as a developer, we want the right to be able to roll that through.
There are also less reasonable developers. I know these people. I refer to them as angry men in dark rooms. They won’t say this out loud, but this is actually what they think. I’m a genius, it is your blessing and privilege to be in my presence. I am going to build something amazing and creative and it is my right to own this thing. They won’t say this because they actually want to win some work, but it’s actually what they think.
I’ve seen developers, there is a small subsection of these people who don’t work out in corporate worlds but they’ll often be developers doing single jobs for single people. They think they should own everything they do. The fact that you paid for it doesn’t actually matter. These people exist. You want to get a sense of where people are at on that.
The issue with intellectual property is that if you don’t have an agreement, you don’t own it. The last conversation I had was that if you don’t have an agreement, typically what takes place is that intellectual property reverts back to copyright law. If I write something, I as the creator of that, regardless of whether I’ve been paid, I own the copyright in it. The person receiving it may have an implied license, but you are not the owner. So unless you own it on paper, you don’t own it. So if you just get it on paper, that makes a big difference.
Outright ownership vs licensing vs custom arrangements
We spoke about this a moment ago to some degree. You can own the rights to something, as in you can own it outright, or you can own a license. This is often a really good middle ground. A license can in many cases give you almost the same amount of ownership as rights. Take my car – either I own it or if I sell it to David, David owns it. Unless we’ve got something really strange going on, we don’t both own the car, one of us owns it.
With intellectual property, I can own it but I can give David the rights. I can give him a license and that license I can make worldwide, he can use it anywhere. I can make it irrevocable, I can never take it back from him even if we have a disagreement. I can make it royalty free, which means I can never charge him for it. If we have, say, background IP, would it be reasonable that we might own our background IP and give David a license to the background IP and that the project IP he might own.
That’s an arrangement that we have with most of our customers. From a client’s perspective, in my opinion, you’re pretty safe there.
There is another scenario that can work quite well and we’ve got this with a couple of clients at the moment. What they’re building has generic use. They only care about their industry. The kind of deals we’ve done with some people says we won’t play in your space. We define what that space is. We’re going to throw some extra effort, we’re going to throw some extra work into this and make it something a bit special and we have the right then to sell it in ways that is no skin off your nose.
That can be a deal that we’ve got in a couple of places and that is a reasonable arrangement. One of the deals we’re doing at the moment is we have that deal in place but they happen to know all the other people who are going to buy it and so they’re actually helping us sell it. Everybody wins out of those arrangements.
So you want to own the project IP and you typically are going to license the background IP when you are dealing with custom software development houses.
This is not my core area but I have heard horror stores where the same issues can happen around ownership of design and creative works. People say, I built a logo, so you’ve got your logo but you don’t actually own it. If you’re dealing in a creative space, and it’s something you’re going to use with your business on a regular basis, I’d make sure I had ownership of that.
Confidentiality
Just a couple of tips in here, you want to ensure confidentiality. A lot of what you actually want in the room is the developer not to tell other people things they shouldn’t talk about.
So addressing confidentiality can be an important thing. Now as developers, it’s reasonable that we move from job to job. It’s reasonable we get to brag. But I take the approach with my staff, I say, you can tell anything that the client, if they put it on a public website, you can absolutely tell the world. That is generally the rule. If the client is happy to say it’s on a public website, you can say, I built this thing because that is pride in workmanship. But beyond that, if they weren’t willing to put it on a public website; algorithms, how things work, you’ve got to make sure that is kept confidential.
Legal vs Pragmatic Control
How many people know, it’s one thing to have legal control, but we’d also like pragmatic control. If I own a car and it is locked up in my garage, I have far less of a problem than if I own a car, I know where it is, but it’s in someone else’s garage and it is locked and they’ve got a big dog and they’re hard to deal with. Now I’ve got a problem. We don’t want to find ourselves in that situation.
The first thing I want to suggest to you is always have your hosting accounts in your name. You never want to be in the situation where the developer owns the hosting account. That is pragmatic control that they have. The situation you should have is the hosting account is in your name and the developer is the nominated technical contact. They must be that, otherwise they can’t act on your behalf. When things go bad at two in the morning, they need the authority to make things, they need to be the nominated contact. But if they own it and it gets ugly, you’ve got a pragmatic issue at hand.
Now there are some people who want to own it. The reason they want to own it is they make big commissions. It’s crazy that is not a reason for your developer to own material.
Code repositories
For most of the applications that we build, the source code, the code that actually goes to build the application, is what we call uncompiled. That means any other developer could look at the server and they could just read the code, it is uncompiled. Compiled code, by comparison, has been squashed together so that no one can read it anymore. It is a single object.
When you’re dealing with uncompiled code, which is very common now, you can get to the hosting if you’ve got hosting control, a new developer can go and take that over and they can see the code in full. What good development firms will do is use what is called version control. They will keep your software and keep all the incremental changes they have ever made. So as I look around the room, Tania and Amanda, we could go back to the version of your software thirteen months ago to the day if we needed to. We can roll back and we can roll forward at any point in time.
Imagine a new developer picking up a project, it’s good to see the current code, and that is eighty percent of the game. But twenty percent of the game, it’s nice to see the background as well. You can see where things have gone. The reason we have that version control, is it gives us the ability to roll back. If there is a problem we can actually go back to it. So if you’re feeling nervous about your developer relationship, there are ways that you can get access not just to the current version but actually to the system that holds the full history.
There are some issues around that. We like to have that on our local server because it allows us to run automative testing. And I’ll talk about that in a moment. There are reasons you can do that but to have that replicated, there is value in that.
Transparency
No obfuscation. If I was to show you the code behind most of the systems here, it’s like English. You’d read it and you’d go there and say there is a variable there called ‘person name’, ‘person email’. You’d say, this form I get ‘person name’ and ‘person email’ and away I go. It makes a bit of sense.
It is possible to run that human readable code through an obfuscation process. It happens really quickly and it runs identically. The code doesn’t change any functionality but to anyone looking at it, it’s completely incomprehensible. You cannot read it at all and a great developer cannot pull it apart. It takes ‘person dot name’ and it turns it into ‘x1’. It takes all the spaces out and it turns it into a blob of text that you cannot get your mind into. We don’t do it, it’s evil.
But if you are talking to people and you’re a little bit nervous about it, you want to just get a line that says, ‘no obfuscation techniques will be used at any point’. The only good reason for obfuscation is if you are taking your software and you’re selling it to other people and they’re installing it locally, obfuscation works because then they can’t modify it, it still runs. So that’s a good reason for obfuscation.
The ‘get away’ plan
Make sure you can leave. We have a hard time leaving Google for our email provider. I’m not too worried about that. I am comfortable with them but our world is pretty integrated into Google’s world. There are some developers who set up a server and they set up a code base and they share it around and they do all that kind of thing. Unless they’re giving you a really good joint offering with other clients, I’ve seen people get stuck and they can never leave because the developer says, it’s going to be great. We’re going to share this material with you and all these other people and whatever else.
But you get locked into an infrastructure that they own and you can never get out of. They are the times when people ring up and I say, I’m very sorry. You don’t own it, it’s in their infrastructure, we can’t do anything about it and you just have to negotiate at that point.
Document the what ifs
Vendors change focus, vendors have business problems. We’re negotiating a key business transaction at the moment and one of the things we put in as a clause is the buyer looks incredibly liquid. They look like a great company. There should be no problems, but I’ve got a clause in there that says if you go out of business, I get to get it back. So just deal with those situations of ‘hey, what happens’. Talk about the breakdown of relationships.
I’m really happy to talk about this because it’s something we’re really passionate about. We have a policy that says we are easy to leave. I never want to be in a relationship with a client who doesn’t want to work with me. Can you imagine that situation? That would be horrible but there are lots of developers who take a very hard nosed approach, I’m going to make more money and whatever else.
You want to have a scenario that says, if we need to leave, what is it going to look like? So from Alliance Software’s perspective, our leaving policy is this. If you’ve paid your bills, you can leave at any time you like. The only thing we’d say to you is, we’ll charge you the standard hourly rate to work with your new developers. We’ll teach them everything they want to know for as much or as little time as you want.
You want be in a position where the relationship is based on trust, not on a technical catch. That’s the end of IP.
You can see how important it is to get to know your software developer. Get to know how they work, what kind of code they consider their own base code, and what they are willing to negotiate as ownership of the actual software. Ironing out these types of details up front will help you avoid some of the most costly mistakes in technology relationships.
We’d love to help you with your software development project. If you need assistance or just have questions, feel free to contact us today.