How do I broach the idea of me owning the rights to software when a company is paying me to write it

I am working on a web application that is going into beta test next week for safety engineers, but the company that is paying for it is safety engineers. Ideally, if I had the ownership of the code then I would be responsible for bug fixes and new features. At the moment they have placed a restriction that I have to follow, where I have to use technologies that are commonly available, so that if I am not around someone else could fix the code.

This company wants to license the application to other companies, so my thought is that they would exclusively license it, and I would just get maintenance fees.

The other application is for a dental office in Canada. They are going to pay me to write a program to replace one that they are paying too much for, currently. If I can get the ownership of that then I would be free to sell it to other companies, in Canada and the US. The dental office is going to pay less to write the application than they pay in a year for licensing it, as I believe it will take me at most 3 wks to write the program. So paying me is just lowering their operating costs.

So, in both cases the companies have different goals and expectations, and I am not certain how to broach the idea. Do I wait until I am done with the application, then suggest it, or what?

My way to get around this delicate situation is to make my clients sign a contract before every project which states that their software will be built upon proprietary frameworks that I own. Indeed, their application will benefit from software components I have taken years to develop. Of course, I charge my clients accordingly and most of them don't mind giving up redistribution rights - all they want is great software priced reasonably.

I wouldn't completely discount the safety engineering application, but for sure it is always easier to deal with the intellectual property question up-front, so the dental app is more straightforward.

Firstly, don't assume because somebody is paying you to solve their problem that the IP automatically belongs to them. There are plenty of products in the marketplace that started off as custom developments to solve a specific customer's problem, but by careful IP management became real money-spinners for their developers. (Consider MS-DOS as the prime example, and Microsoft didn't even build the original).

Put yourself in the customer's shoes for one minute. In most cases they are interested in getting their problem solved, not in branching out into the software business. However, everyone wants to feel that they got a fair deal. So sometimes charging a high daily consulting rate to build an app, and then going off and marketing the app to others without giving anything back to the original customer maybe doesn't seem quite fair. There are plenty of ways to address this - you can develop the original software at a discounted rate (at cost, for example), you can give them reduced cost maintenance, you can allow them a certain amount of free hours of consulting for enhancements, etc, etc. - the key is to be able to leave the negotiating table with both sides feeling they have got a fair deal.

Of course, a side effect of getting your original customer on your side is that you can then potentially use them as a reference customer, often a really valuable commodity in the early days of any product business.

Coming back to the safety engineering application, I would see whether they would consider some sort of joint venture with you in offering the app to other firms. I am assuming that there is nothing explicit about IP in your current contract with them (obviously a mistake to avoid in the future) so things are a bit up in the air. If this is true, then they're in a sticky position due to the uncertainty, and you could use that fact to initiate a dialogue on the subject. They may be interested in having you as development partner for the software, providing bug fixes and enhancements in return for a revenue share. (If this works, obviously be careful that you don't ge sucked into doing tons of work speculatively). If you can't negotiate with these guys because they're not interested, personally I would walk away - it sounds like it could just turn into an almighty headache.

In short, be fair in your dealings with all your customers and you can't go too far wrong. Good luck in any case!

The way I see it there are 2 reasonable points in time to discuss ownership:

1. During negotiations before signing the first contract
2. A couple of months after development of version 1 is complete, if sales or lack thereof has created a new business situation.

Obviously something as important as copyright and license type should be clearly laid out in the contract.

As for who should have ownership; well, that is entirely a negotiation point.

• Who wants it the most...
• Who is most capable of driving the product forward from a software development / technology perspective...
• Who is most capable of driving the product forward from a market understanding and sales perspective...
• Who has money and time...

Especially for your 2nd case, the dentist, it seems that your negotiation partner ought to understand that he is not in a position (doesn't have the core competencies) to drive a software product forward. Thus he should give that right a low value if he holds it, and be happy to let you have it instead, in return for something else (lower maintenance costs, cheap access to new versions etc).

I would not bother negotiating once you already signed a contract. In a way it is unprofessional.

Now with any of the new deals you can try method we used: give the client a major cut in your fee and perpetual free license (with X years of maintenance) in exchange for them helping you develop the app and letting you keep the source code, IP, and license it to whoever you want without royalties. If you are really good and you really know how to solve their headache, charge them full rate.

You certainly can talk with them about what happens after the contact is done. That might be a good way to discuss a separate maintenance contract. Steve makes a good point about a joint venture. That might be a way to have you both be able to market the software without competing.

You can also approach them for how updates would work. I have to believe that once both software programs hit customers, they are going to want enhancements and bug fixes. That another discussion point as well.

In general, I would start the discussion about maintenance, future developments and joint marketings sales now since agreements like that take time to develop.